Secure encrypted ota upgrade device

Abstract

This application discloses a secure encrypted OTA upgrade device for use in the field of automotive electronic control technology. The device includes: an upgrade package receiving unit, an encryption / decryption unit, an integrity verification unit, an upgrade execution unit, a rollback mechanism unit, and a progress monitoring unit. This application prevents upgrade package tampering and malicious attacks. Through encryption / decryption, integrity verification, a rollback mechanism, and an intelligent retry strategy, it ensures the security and stability of the upgrade process. Progress monitoring and fault alarms shorten the troubleshooting time for upgrade faults. By implementing a precise backup and rollback mechanism, it ensures that if problems are encountered during the OTA upgrade process, the system can be restored to a normal state using the backed-up original version. By monitoring the upgrade operation in real time and generating rollback signals, it can automatically restore the original version when an anomaly is detected, ensuring stable operation.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control technology, and more particularly to a secure encrypted OTA upgrade device. Background Technology

[0002] OTA (Over-The-Air) upgrade devices are devices that remotely update the software or firmware of a vehicle's electronic control unit (ECU) via wireless communication networks (such as 4G / 5G and Wi-Fi), fix vulnerabilities, or add new functions. This allows automakers to upgrade the controller software without requiring car owners to visit a repair shop, significantly improving maintenance efficiency and user experience, while ensuring the reliability of the upgrade process and the safety of vehicle functions.

[0003] The underlying software of the hydraulic fully active suspension controller needs to be upgraded to optimize functionality and fix faults. Existing OTA upgrade devices have significant defects, as follows: 1. The upgrade process lacks encryption protection, making it vulnerable to malicious attacks and code tampering; there is no integrity verification mechanism, and damage or tampering of the upgrade package during transmission may cause the controller to malfunction. 2. The lack of an upgrade rollback mechanism means that after an upgrade fails, it is impossible to restore to a stable version. Furthermore, the upgrade progress is not monitored, making troubleshooting difficult. This makes it hard to meet automotive-grade functional safety and cybersecurity requirements, thus hindering the functional iteration and maintenance efficiency of the controller throughout its entire lifecycle.

[0004] 3. No effective solutions have yet been proposed for the problems in the relevant technologies. Summary of the Invention

[0005] To overcome the above problems, this application aims to propose a secure encrypted OTA upgrade device, which aims to solve the technical problems of lacking an upgrade rollback mechanism, being unable to restore to a stable version after an upgrade failure, having no monitoring of upgrade progress, being difficult to troubleshoot, failing to meet automotive-grade functional safety and network security requirements, and restricting the functional iteration and maintenance efficiency of the controller throughout its entire life cycle.

[0006] Therefore, the specific technical solution adopted in this application is as follows: A secure encrypted OTA upgrade device, the device comprising: The upgrade package receiving unit is used to receive encrypted upgrade packages issued by the vehicle OTA platform through the communication link; The encryption / decryption unit is used to decrypt the received encryption upgrade package; The integrity verification unit is used to perform hash verification on the decrypted upgrade package to determine its integrity. If the verification fails, it will trigger an upgrade rejection and issue a fault alarm. The upgrade execution unit is used to receive the upgrade package that has passed integrity verification and perform the partition upgrade operation of the underlying software; The rollback mechanism unit is used to back up the current version before upgrading and restore the original version if the partition upgrade operation fails; The progress monitoring unit is used to collect and provide feedback on the progress status during the upgrade process in real time, and to record fault information when a fault occurs.

[0007] Optionally, the upgrade package receiving unit includes: The communication initialization module is used to initialize the communication interface of the controller local area network or flexible data rate controller local area network, configure the receive filter, and enter the waiting state for receiving. The frame receiving and buffering module is used to receive encrypted upgrade packet data frame by frame under normal receiving conditions, store the payload in the receiving buffer, and record the number of bytes received and the frame sequence number. The breakpoint resume processing module is used to save the current receiving position as a breakpoint if a communication interruption is detected during the receiving process; after the communication link is restored, it sends a resume request to the vehicle OTA platform and continues to receive subsequent data frames from the breakpoint position.

[0008] Optionally, perform a partition upgrade operation on the underlying software, including: Receive upgrade package data transmitted by the integrity verification unit, parse out the target partition address, data length and firmware content to be written, and temporarily store the parsed information in the working buffer. Read the target partition address from the working buffer, send an erase command to the memory, erase the original data in the specified area, and wait for confirmation of completion of the erase; After erasure is complete, the firmware content to be written is read from the working buffer and written to the erased target partition in blocks according to storage units. At the same time, the number of bytes written or the cumulative check value is recorded. Read the firmware data from the target partition, recalculate the hash value, and compare it with the original hash value stored in the working buffer; if the comparison matches, update the boot flag so that the controller loads the new version of the software the next time it starts.

[0009] Optionally, if the comparison matches, the startup flag is updated so that the controller loads the new version of the software upon the next startup. After confirming that the hash values ​​match, an erase command is sent to the startup flag storage area to clear the original flag data; Write the new version flag value to the erased storage area and wait for the writing to complete; Read the startup flag value from the written storage address and compare it with the preset standard flag value; If the comparison matches, it confirms that the start-up flag has been correctly fixed; If the comparison is inconsistent, and the cumulative number of retries reaches the preset limit and still fails, an exception will be reported and the upgrade process will be terminated. After the controller restarts, the bootloader reads the boot flag value and loads the new version of the software from the target partition based on the flag value, thus completing the version switch.

[0010] Alternatively, the method to restore the original version when the partition upgrade operation fails is as follows: Check the status of the primary backup area and the redundant backup area, and select the target backup area; Copy the currently running version to the target backup area and record the hash value and version number of the currently running version; Monitor the erase, write, and verification status of partition upgrade operations. If an anomaly is detected, generate a rollback trigger signal. Based on the rollback trigger signal, the original version is read from the target backup area and written back to the main partition. The hash value is calculated and compared with the record value. If they match, the rollback is completed.

[0011] Optionally, record the hash value and version number of the currently running version, including: Read firmware data from the currently running partition in fixed lengths and store the data into a temporary buffer block by block. The data blocks in the temporary buffer are written sequentially to the corresponding offset addresses in the target backup area, and the length and writing position of the data already written are tracked. Read firmware data from the running partition sequentially and write the data block by block to the target backup area until all data is copied. Calculate the hash value of the firmware data stored in the target backup area, combine it with the current software version number and backup timestamp to generate a version descriptor data packet, and write the descriptor data packet into the header area of ​​the target backup area.

[0012] Optionally, the descriptor data packet is written to the header area of ​​the target backup area, including: Read the fully copied firmware data from the target backup area, calculate the hash value of each block of fixed length, and finally merge them into a complete firmware hash value; The calculated firmware hash value, current software version number, and backup timestamp are combined according to a predefined data structure to generate a version descriptor data package; Erase the original data in the specified area of ​​the header of the target backup area, write the generated version descriptor data packet to the specified area, and wait for confirmation of completion of writing; Read the newly written version descriptor data packet from the header area of ​​the target backup area and compare it byte by byte with the version descriptor data packet; If the comparison matches, the backup is marked as successful; If the comparison is inconsistent, the maximum number of retries is calculated based on the current power supply stability, bus load and historical failure rate, and then retries are executed step by step according to the exponential backoff strategy.

[0013] Optionally, the formula for calculating the maximum number of retries is:

[0014] Optionally, a hash value is calculated and compared with the record value. If they match, the rollback is completed, including: Read the complete original version data from the target backup area and store it in a temporary buffer; The data in the buffer is written to the corresponding location in the primary partition in sequence, and the hash value of the data is calculated during the writing process. The calculated hash value is compared with the hash value recorded during backup. If the comparison results match, the rollback is successful and the upgrade flag is cleared. If the comparison results are inconsistent, exception handling will be triggered.

[0015] Compared with the prior art, this application has the following beneficial effects: 1. This application prevents upgrade package tampering and malicious attacks. Through encryption and decryption, integrity verification, rollback mechanism and intelligent retry strategy, it ensures the security and stability of the upgrade process. Progress monitoring and fault alarm shorten the troubleshooting time for upgrade faults. At the same time, it supports CAN / CANFD link transmission and can adapt to the OTA upgrade needs of different vehicle models.

[0016] 2. This application verifies the validity of the firmware by comparing hash values ​​and updates the startup flag upon success to ensure that the controller loads the new version upon the next startup. If the comparison is inconsistent, the stability and reliability of the upgrade process will be ensured through retry and exception handling mechanisms, thereby effectively avoiding the risks caused by upgrade failure.

[0017] 3. This application implements a precise backup and rollback mechanism to ensure that when problems are encountered during the OTA upgrade process, the original version can be restored to a normal state. By monitoring the upgrade operation in real time and generating a rollback signal, the original version can be automatically restored when an anomaly is detected, ensuring stable operation. Attached Figure Description

[0018] The above-mentioned features, characteristics, and advantages of this application, as well as their implementation methods, will become clearer and more understandable in conjunction with the following description of the embodiments, which are illustrated in detail with reference to the accompanying drawings. Schematic diagrams are shown here: Figure 1 This is a schematic diagram of a secure encrypted OTA upgrade device according to an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0020] According to embodiments of this application, a secure encrypted OTA upgrade device is provided to prevent upgrade package tampering and malicious attacks. Through encryption / decryption, integrity verification, rollback mechanisms, and intelligent retry strategies, the security and stability of the upgrade process are ensured. Progress monitoring and fault alarms shorten the troubleshooting time for upgrade faults. Figure 1 As shown, a secure encrypted OTA upgrade device according to an embodiment of this application includes: The upgrade package receiving unit is used to receive encrypted upgrade packages issued by the vehicle OTA platform through the communication link.

[0021] Preferably, the upgrade package receiving unit includes: The communication initialization module is used to initialize the communication interface of the controller local area network or flexible data rate controller local area network, configure the receive filter, and enter the waiting state for receiving. The frame receiving and buffering module is used to receive encrypted upgrade packet data frame by frame under normal receiving conditions, store the payload in the receiving buffer, and record the number of bytes received and the frame sequence number. The breakpoint resume processing module is used to save the current receiving position as a breakpoint if a communication interruption is detected during the receiving process; after the communication link is restored, it sends a resume request to the vehicle OTA platform and continues to receive subsequent data frames from the breakpoint position.

[0022] The encryption / decryption unit is used to decrypt the received encryption upgrade package.

[0023] The integrity verification unit is used to perform hash verification on the decrypted upgrade package to determine its integrity. If the verification fails, it will trigger an upgrade rejection and issue a fault alarm.

[0024] The upgrade execution unit is used to receive the upgrade package that has passed integrity verification and perform the partition upgrade operation of the underlying software.

[0025] The rollback mechanism unit is used to back up the current version before upgrading and restore the original version if the partition upgrade operation fails.

[0026] It should be noted that the upgrade package receiving unit, encryption / decryption unit, integrity verification unit, upgrade execution unit, rollback mechanism unit, and progress monitoring unit are integrated into the fully active suspension controller ECU (electronic control unit), and are connected to the vehicle's OTA (over-the-air) platform via a CAN (controller area network) / CANFD (flexible data rate controller area network) communication link.

[0027] Preferably, performing a partition upgrade operation on the underlying software includes: Receive upgrade package data transmitted by the integrity verification unit, parse out the target partition address, data length and firmware content to be written, and temporarily store the parsed information in the working buffer. Read the target partition address from the working buffer, send an erase command to the memory, erase the original data in the specified area, and wait for confirmation of completion of the erase; After erasure is complete, the firmware content to be written is read from the working buffer and written to the erased target partition in blocks according to storage units. At the same time, the number of bytes written or the cumulative check value is recorded. Read the firmware data from the target partition, recalculate the hash value, and compare it with the original hash value stored in the working buffer; if the comparison matches, update the boot flag so that the controller loads the new version of the software the next time it starts.

[0028] Preferably, if the comparison matches, the startup flag is updated so that the controller loads the new version of the software upon the next startup, as follows: After confirming that the hash values ​​match, an erase command is sent to the startup flag storage area to clear the original flag data; Write the new version flag value to the erased storage area and wait for the writing to complete; Read the startup flag value from the written storage address and compare it with the preset standard flag value; If the comparison matches, it confirms that the start-up flag has been correctly fixed; If the comparison is inconsistent, and the cumulative number of retries reaches the preset limit and still fails, an exception will be reported and the upgrade process will be terminated. After the controller restarts, the bootloader reads the boot flag value and loads the new version of the software from the target partition based on the flag value, thus completing the version switch.

[0029] Preferably, the method for restoring the original version when the partition upgrade operation fails is as follows: Check the status of the primary backup area and the redundant backup area, and select the target backup area; Copy the currently running version to the target backup area and record the hash value and version number of the currently running version; Monitor the erase, write, and verification status of partition upgrade operations. If an anomaly is detected, generate a rollback trigger signal. Based on the rollback trigger signal, the original version is read from the target backup area and written back to the main partition. The hash value is calculated and compared with the record value. If they match, the rollback is completed.

[0030] Preferably, the hash value and version number of the currently running version are recorded, including: Read firmware data from the currently running partition in fixed lengths and store the data into a temporary buffer block by block. The data blocks in the temporary buffer are written sequentially to the corresponding offset addresses in the target backup area, and the length and writing position of the data already written are tracked. Read firmware data from the running partition sequentially and write the data block by block to the target backup area until all data is copied. Calculate the hash value of the firmware data stored in the target backup area, combine it with the current software version number and backup timestamp to generate a version descriptor data packet, and write the descriptor data packet into the header area of ​​the target backup area.

[0031] Preferably, writing the descriptor data packet to the header area of ​​the target backup area includes: Read the fully copied firmware data from the target backup area, calculate the hash value of each block of fixed length, and finally merge them into a complete firmware hash value; The calculated firmware hash value, current software version number, and backup timestamp are combined according to a predefined data structure to generate a version descriptor data package; Erase the original data in the specified area of ​​the header of the target backup area, write the generated version descriptor data packet to the specified area, and wait for confirmation of completion of writing; Read the newly written version descriptor data packet from the header area of ​​the target backup area and compare it byte by byte with the version descriptor data packet; If the comparison matches, the backup is marked as successful; If the comparison is inconsistent, the maximum number of retries is calculated based on the current power supply stability, bus load and historical failure rate, and then retries are executed step by step according to the exponential backoff strategy.

[0032] Preferably, the formula for calculating the maximum number of retries is:

[0033] Preferably, the hash value is calculated and compared with the record value; if they match, the rollback is completed, including: Read the complete original version data from the target backup area and store it in a temporary buffer; The data in the buffer is written to the corresponding location in the primary partition in sequence, and the hash value of the data is calculated during the writing process. The calculated hash value is compared with the hash value recorded during backup. If the comparison results match, the rollback is successful and the upgrade flag is cleared. If the comparison results are inconsistent, exception handling will be triggered.

[0034] The progress monitoring unit is used to collect and provide feedback on the progress status during the upgrade process in real time, and to record fault information when a fault occurs.

[0035] It should be noted that the current version of the fully active suspension controller ECU for a certain model is V1.2, and it needs to be upgraded to V1.3 via OTA to optimize the damping adjustment logic on bumpy roads. The upgrade package size is 8MB, and the upgrade package is received by the vehicle through the 4G+CANFD link while it is in motion. The communication initialization module initializes the CANFD interface, configures the filtering rules, and then enters a waiting state. The frame receiving and buffering module receives the V1.3 encrypted upgrade package frame by frame, stores the payload in the receiving buffer, and records the number of bytes received (e.g., a cumulative 5MB) and the frame sequence number. During the journey, communication is temporarily interrupted in the tunnel. The breakpoint resume processing module saves the current receiving position as the breakpoint. After the vehicle exits the tunnel and the link is restored, it sends a resume request to the OTA platform to continue receiving the remaining 3MB of data frames from the breakpoint position and completes the upgrade package reception. The encryption / decryption unit uses a preset symmetric key to decrypt the received 8MB encrypted packet to obtain the plaintext upgrade packet; The integrity verification unit calculates the SHA-256 hash value of the plaintext upgrade packet and compares it with the baseline hash value issued by the OTA platform: If they match, proceed to the upgrade execution phase; If there is a discrepancy, an upgrade will be rejected and an integrity verification failure fault code will be reported to the vehicle's T-BOX. Parse the upgrade package data to obtain the target partition address, data length of 8MB, and V1.3 firmware content, and temporarily store them in the working buffer; Send an erase command to the memory to erase the 8MB region starting at the target partition address, and wait for confirmation of completion of the erase; Write the V1.3 firmware to the erased partition in 256KB blocks and record the number of bytes written (e.g., add 256KB after each block is written). Read the target partition firmware data, recalculate the SHA-256 hash value, compare it with the original hash value, and update the boot flag after confirming they match. Erase the original data in the boot flag storage area; Write the V1.3 version flag value 0x03; Read the flag value and compare it with the preset 0x03 to confirm successful hardening; After the ECU is powered off and restarted, the bootloader reads the boot flag 0x03, loads the V1.3 firmware from the target partition, and completes the version switch; Before the upgrade, the rollback mechanism unit copies the current V1.2 version to the redundant backup area, calculates its SHA-256 hash value (such as abc123...), and generates a version descriptor data packet containing the version number V1.2, hash value, and backup timestamp, and writes it to the header of the backup area; If power supply fluctuations cause the write to V1.3 to fail during the upgrade, a rollback trigger signal will be generated. Read the complete V1.2 data from the backup area, write it back to the main partition, calculate the hash value and compare it with the abc123... value from the backup, complete the rollback, and restore the V1.2 version to operation; The progress monitoring unit collects the progress of each stage in real time: reception completion (100%), decryption progress (100%), partition erasure progress (100%), and firmware writing progress (0%~100%). If a rollback is triggered, record the fault type as "partition write error" and synchronize it to the vehicle OTA platform; This addresses the scenario where version descriptor writing fails during rollback backup;

[0036] If the version descriptor write comparison is inconsistent, a maximum of 4 retries will be made; The retry uses an exponential backoff strategy: 100ms for the first retry, 200ms for the second, 400ms for the third, and 800ms for the fourth. If the upgrade fails after four retries, an exception is reported and the upgrade process is terminated.

[0037] It should be noted that the calculation formulas and all parameters involved in the calculations in this application have been dimensionless beforehand. The process of dimensionless processing is well known in the industry and will not be described here.

[0038] Although the present application has disclosed the preferred embodiments above, the embodiments are merely examples for the purpose of illustration and are not intended to limit the present application. Those skilled in the art can make some modifications and refinements without departing from the spirit and scope of the present application. The scope of protection claimed by the present application should be determined by the claims.

Claims

1. A secure encrypted OTA upgrade device, characterized in that, The device includes: The upgrade package receiving unit is used to receive encrypted upgrade packages issued by the vehicle OTA platform through the communication link; The encryption / decryption unit is used to decrypt the received encryption upgrade package; The integrity verification unit is used to perform hash verification on the decrypted upgrade package to determine its integrity. If the verification fails, it will trigger an upgrade rejection and issue a fault alarm. The upgrade execution unit is used to receive the upgrade package that has passed integrity verification and perform the partition upgrade operation of the underlying software; The rollback mechanism unit is used to back up the current version before upgrading and restore the original version if the partition upgrade operation fails; The progress monitoring unit is used to collect and provide feedback on the progress status during the upgrade process in real time, and to record fault information when a fault occurs.

2. The secure encrypted OTA upgrade device according to claim 1, characterized in that, The upgrade package receiving unit includes: The communication initialization module is used to initialize the communication interface of the controller local area network or flexible data rate controller local area network, configure the receive filter, and enter the waiting state for receiving. The frame receiving and buffering module is used to receive encrypted upgrade packet data frame by frame under normal receiving conditions, store the payload in the receiving buffer, and record the number of bytes received and the frame sequence number. The breakpoint resume processing module is used to save the current receiving position as a breakpoint if a communication interruption is detected during the receiving process; after the communication link is restored, it sends a resume request to the vehicle OTA platform and continues to receive subsequent data frames from the breakpoint position.

3. The secure encrypted OTA upgrade device according to claim 1, characterized in that, The partition upgrade operation performed on the underlying software includes: Receive upgrade package data transmitted by the integrity verification unit, parse out the target partition address, data length and firmware content to be written, and temporarily store the parsed information in the working buffer. Read the target partition address from the working buffer, send an erase command to the memory, erase the original data in the specified area, and wait for confirmation of completion of the erase; After erasure is complete, the firmware content to be written is read from the working buffer and written to the erased target partition in blocks according to storage units. At the same time, the number of bytes written or the cumulative check value is recorded. Read the firmware data from the target partition, recalculate the hash value, and compare it with the original hash value stored in the working buffer; if the comparison matches, update the boot flag so that the controller loads the new version of the software the next time it starts.

4. The secure encrypted OTA upgrade device according to claim 3, characterized in that, The method for updating the startup flag if the comparison matches, so that the controller loads the new version of the software the next time it starts, is as follows: After confirming that the hash values ​​match, an erase command is sent to the startup flag storage area to clear the original flag data; Write the new version flag value to the erased storage area and wait for the writing to complete; Read the startup flag value from the written storage address and compare it with the preset standard flag value; If the comparison matches, it confirms that the start-up flag has been correctly fixed; If the comparison is inconsistent, and the cumulative number of retries reaches the preset limit and still fails, an exception will be reported and the upgrade process will be terminated. After the controller restarts, the bootloader reads the boot flag value and loads the new version of the software from the target partition based on the flag value, thus completing the version switch.

5. The secure encrypted OTA upgrade device according to claim 1, characterized in that, The method for restoring the original version when the partition upgrade operation fails is as follows: Check the status of the primary backup area and the redundant backup area, and select the target backup area; Copy the currently running version to the target backup area and record the hash value and version number of the currently running version; Monitor the erase, write, and verification status of partition upgrade operations. If an anomaly is detected, generate a rollback trigger signal. Based on the rollback trigger signal, the original version is read from the target backup area and written back to the main partition. The hash value is calculated and compared with the record value. If they match, the rollback is completed.

6. The secure encrypted OTA upgrade device according to claim 5, characterized in that, The record includes the hash value and version number of the currently running version, including: Read firmware data from the currently running partition in fixed lengths and store the data into a temporary buffer block by block. The data blocks in the temporary buffer are written sequentially to the corresponding offset addresses in the target backup area, and the length and writing position of the data already written are tracked. Read firmware data from the running partition sequentially and write the data block by block to the target backup area until all data is copied. Calculate the hash value of the firmware data stored in the target backup area, combine it with the current software version number and backup timestamp to generate a version descriptor data packet, and write the descriptor data packet into the header area of ​​the target backup area.

7. The secure encrypted OTA upgrade device according to claim 6, characterized in that, The step of writing the descriptor data packet to the header area of ​​the target backup area includes: Read the fully copied firmware data from the target backup area, calculate the hash value of each block of fixed length, and finally merge them into a complete firmware hash value; The calculated firmware hash value, the current software version number, and the backup timestamp are combined according to a predefined data structure to generate a version descriptor data package; Erase the original data in the specified area of ​​the header of the target backup area, write the generated version descriptor data packet to the specified area, and wait for confirmation of completion of writing; Read the newly written version descriptor data packet from the header area of ​​the target backup area and compare it byte by byte with the version descriptor data packet; If the comparison matches, the backup is marked as successful; If the comparison is inconsistent, the maximum number of retries is calculated based on the current power supply stability, bus load and historical failure rate, and then retries are executed step by step according to the exponential backoff strategy.

8. The secure encrypted OTA upgrade device according to claim 7, characterized in that, The formula for calculating the maximum number of retries is:

9. The secure encrypted OTA upgrade device according to claim 8, characterized in that, The calculation of the hash value and comparison with the record value, if they match, completes the rollback, including: Read the complete original version data from the target backup area and store it in a temporary buffer; The data in the buffer is written to the corresponding location in the primary partition in sequence, and the hash value of the data is calculated during the writing process. The calculated hash value is compared with the hash value recorded during backup. If the comparison results match, the rollback is successful and the upgrade flag is cleared. If the comparison results are inconsistent, exception handling will be triggered.

Images