Method and system for realizing MCU OTA comprising HSM module

Abstract

The invention discloses an implementation method and system for MCU OTA containing an HSM module, and relates to the technical field of vehicle-mounted electronic control. The method comprises the steps that firstly, a unified executable file for embedding HSM firmware into main core software in a preset address offset mode is constructed, the main core software running in a current running partition receives the file and updates the file to a backup partition for integrity verification, and then the file is stored in the backup partition; after verification is passed, an HSM self-updating module is triggered to update firmware to an HSM storage position, before partition switching and resetting are executed, the HSM carries out safety pre-verification on main core software of a backup partition through a preset backup partition key, it is judged that OTA succeeds only when HSM self-updating and main core software pre-verification are both passed, resetting is executed, starting is carried out from the backup partition, and therefore the safety of the OTA is guaranteed. And otherwise, keeping running in the current partition, thereby realizing the unification of the upgrade interface and effectively eliminating the controller locking risk caused by the failure of safety starting verification.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control technology, and in particular to a method and system for implementing MCU OTA including an HSM module. Background Technology

[0002] With the rapid development of the intelligent vehicle industry, the information security requirements of vehicle controllers are becoming increasingly stringent. This has prompted more and more microcontrollers (MCUs) to integrate Hardware Security Modules (HSMs) to provide core security functions such as key management, secure boot, and encryption / decryption. However, HSMs typically operate as independent subsystems with lagging development processes. Existing OTA upgrade solutions often only add HSM support after the MCU's functionality has matured. This not only leads to difficulties in matching the MCU's main core software with the HSM software version and complex and inconsistent external upgrade interfaces, but more seriously, if the upgraded software does not match the key or secure boot configuration, it can easily cause the MCU to lock up, resulting in irreversible damage to the controller. Therefore, there is an urgent need for an MCU OTA implementation method that includes an HSM module, which can unify the interface, ensure synchronous matching of software and keys, and effectively prevent upgrades from bricking the device. Summary of the Invention

[0003] The purpose of this invention is to provide an MCU OTA implementation method and system including an HSM module, which at least solves one of the technical problems in existing OTA solutions, namely, the difficulty in matching the main core and HSM software versions, the complexity and inconsistency of upgrade interfaces, and the high risk of MCU lock-up and damage due to software and key mismatch after upgrade.

[0004] This invention provides the following solution:

[0005] According to one aspect of the present invention, a method for implementing MCU OTA including an HSM module is provided, comprising the following steps:

[0006] S1. Construct a unified executable file in which the HSM software is embedded as firmware at a predetermined address offset of the main core software.

[0007] S2. The main kernel software running in the current running partition receives the unified executable file, updates it to the main kernel software storage area of ​​the backup partition, and performs integrity verification on the updated backup partition main kernel software.

[0008] S3. If the integrity verification passes, the main core software triggers the self-update module inside the HSM. The self-update module updates the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location of the backup partition.

[0009] S4. Before performing the running partition switch and reset, the HSM self-update module uses the pre-configured backup partition key to pre-verify the main core software of the backup partition;

[0010] S5. Only when the self-update of the HSM software and the pre-verification of the main core software both pass, is the OTA determined to be successful and a reset is performed to start from the backup partition; otherwise, it remains running on the current running partition.

[0011] Furthermore, S1 specifically includes the following steps:

[0012] Deploy a self-updating module within the HSM software;

[0013] The address of the HSM software is offset to a predetermined location in the main core software and used as the HSM firmware;

[0014] The HSM firmware and the main core software are merged to generate the unified executable file.

[0015] Furthermore, the process of merging the HSM firmware with the main core software to generate the unified executable file specifically includes the following steps:

[0016] In the storage space planning of the main core software, a predetermined address area for storing the HSM firmware is determined;

[0017] The address of the HSM software is offset to the predetermined address region to form the HSM firmware;

[0018] The data of the HSM firmware is embedded into the predetermined address area of ​​the main core software to generate a unified executable file containing the main core software and the HSM firmware.

[0019] Furthermore, S2 specifically includes the following steps:

[0020] The OTA module of the main core software responds to the instructions issued by the OTA server and erases the main core software storage area of ​​the backup partition, which includes the area used to store the HSM firmware;

[0021] Update the main core software and the HSM firmware contained therein in the backup partition storage according to the unified executable file content;

[0022] The main core software performs an integrity check on the updated backup partition main core software and HSM firmware.

[0023] Furthermore, the integrity verification of the updated backup partition main core software and HSM firmware by the main core software specifically includes the following steps:

[0024] Respond to the integrity verification trigger command issued by the OTA server;

[0025] The data in the backup partition's main core software storage area is read, including the main core software code and the HSM firmware embedded therein;

[0026] The read data is verified and compared to confirm the integrity of the backup partition's main core software and HSM firmware.

[0027] Furthermore, S3 specifically includes the following steps:

[0028] After the integrity verification passes, the main core software checks whether the unified executable file contains HSM firmware;

[0029] If present, the main core software triggers the self-update module within the HSM software;

[0030] The self-update module reads the HSM firmware from the storage location of the main core software in the backup partition and writes it to the HSM software storage location in the backup partition.

[0031] Furthermore, S4 specifically includes the following steps:

[0032] The HSM self-update module first verifies the integrity of the updated backup partition HSM software;

[0033] After the HSM software integrity verification passes, the main core software of the backup partition is verified using the backup partition key that has been pre-loaded into the secure storage area by the currently running partition program.

[0034] Furthermore, after the HSM software integrity verification passes, the process of verifying the main core software of the backup partition using the backup partition key pre-loaded into the secure storage area by the currently running partition program specifically includes the following steps:

[0035] HSM receives the key jarming command from the main core software running on the currently running partition and stores the key that matches the software to be upgraded into the key slot of the secure storage area of ​​the corresponding backup partition;

[0036] The HSM self-update module reads the key of the corresponding backup partition from the secure storage area;

[0037] The read key is used to sign and verify the data in the backup partition's main core software storage area to confirm that the backup partition's main core software matches the key.

[0038] Furthermore, S5 specifically includes the following steps:

[0039] If the integrity verification of the HSM software and the pre-verification of the main core software are both successful, the HSM self-update module returns a self-update success status to the main core, the main core reports OTA success to the OTA server, and responds to the aspect and reset requests issued by the OTA server, performs a reset, and starts from the backup partition.

[0040] If any verification fails, the HSM self-update module returns a failure status, the OTA server does not send an aspect request, and the MCU continues to run in the current running partition until the next OTA startup.

[0041] According to two aspects of the present invention, an MCU OTA implementation system including an HSM module is provided, the system comprising:

[0042] The MCU main core is configured to receive a unified executable file, which is generated by the HSM firmware and embedded in the main core software with a predetermined address offset. The MCU main core is also configured to write the unified executable file to the main core software storage area of ​​the backup partition and perform integrity verification on the updated backup partition main core software.

[0043] The HSM module has an internally deployed self-updating module.

[0044] The MCU main core triggers the self-update module after the integrity verification is passed.

[0045] The self-update module is configured to update the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location of the backup partition, and to pre-verify the main core software of the backup partition using a pre-configured backup partition key before performing the running partition switch and reset.

[0046] The system is configured to determine OTA success and perform a reset to boot from the backup partition only when both the self-update of the HSM software and the pre-verification of the main core software pass.

[0047] The above solution achieves the following beneficial technical effects:

[0048] This application introduces an HSM self-update module to pre-verify the backup master core software using the backup partition key before A / B side switching and reset. This effectively reduces the risk of microcontroller lockup due to security boot verification failure and ensures that partition switching is only performed if verification is successful. This allows the controller to maintain normal operation in the current partition when an upgrade anomaly occurs.

[0049] This application achieves a unified OTA system design scheme in scenarios with and without an HSM module by embedding the HSM software as firmware into a predetermined address area of ​​the main core software and constructing it as a unified executable file. This simplifies the file management and distribution process of the external server, while enhancing the compatibility between the main core software and the HSM software versions and the portability of the system solution.

[0050] This application adopts a management strategy that triggers the backup partition key to be loaded into a secure storage area by the current running partition. This strategy enables the coordinated execution of key updates and software upgrades, providing a necessary verification basis for security pre-verification before reset, while avoiding interference with current business operations caused by key upgrades. This improves the flexibility and reliability of information security configuration updates for vehicle controllers. Attached Figure Description

[0051] Figure 1 This is a flowchart of an MCU OTA implementation method including an HSM module provided by one or more embodiments of the present invention.

[0052] Figure 2 This is a schematic diagram of the architecture provided in a specific embodiment of the present invention.

[0053] Figure 3 This is a schematic diagram of MCU software memory distribution provided in a specific embodiment of the present invention.

[0054] Figure 4 This is a schematic diagram of an upgraded architecture provided by a specific embodiment of the present invention.

[0055] Figure 5 This is a simplified flowchart of an MCU OTA process provided in a specific embodiment of the present invention.

[0056] Figure 6 This is a specific embodiment of the HSM self-update logic diagram provided by the present invention. Detailed Implementation

[0057] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] Figure 1 This is a flowchart of a method for implementing MCU OTA including an HSM module, provided by one or more embodiments of the present invention.

[0059] like Figure 1 As shown, an MCU OTA implementation method including an HSM module includes the following steps:

[0060] S1. Construct a unified executable file in which the HSM software is embedded as firmware at a predetermined address offset of the main core software.

[0061] Furthermore, S1 specifically includes the following steps:

[0062] Deploy a self-updating module within the HSM software;

[0063] The address of the HSM software is offset to a predetermined location in the main core software and used as the HSM firmware;

[0064] The HSM firmware and the main core software are merged to generate a unified executable file.

[0065] Furthermore, merging the HSM firmware with the main core software to generate a unified executable file specifically includes the following steps:

[0066] In the storage space planning of the main core software, a predetermined address area for storing the HSM firmware is determined;

[0067] The address of the HSM software is offset to a predetermined address region to form the HSM firmware;

[0068] The HSM firmware data is embedded into a predetermined address area of ​​the main core software to generate a unified executable file containing both the main core software and the HSM firmware.

[0069] Specifically, combined Figure 3 as well as Figure 4 In the software construction process of microcontrollers, in order to achieve the unification of external interfaces in scenarios with and without hardware security modules, and to ensure strong version consistency between the main core software and the hardware security module software, the system executes step S1 and its sub-steps during the compilation and linking stage.

[0070] First, such as Figure 2 Developers need to deploy a self-updating module in the hardware security module's software code project. This self-updating module is a piece of independent functional code embedded within the hardware security module's application software. It is configured to cross the core boundary and access the storage space managed by the microcontroller's main core, combined with... Figure 3 The main responsibility of this self-update module is to move new firmware data from the backup partition storage area where the main core software is located to the hardware security module's own running storage area when the subsequent upgrade process is triggered, thereby realizing its own update.

[0071] Next, please refer to Figure 3Regarding the layout of the A-side and B-side memory areas, in the engineering configuration of the main core software, a predetermined address region needs to be planned in the layout of its non-volatile memory. This predetermined address region is located inside the main core software code image and is represented as a continuous reserved space or blank data segment. Its physical location is predetermined, and the size of this region is set to be sufficient to accommodate the entire software image of the hardware security module. This is usually accomplished by modifying the linker script file of the main core software. The starting address and length of this reserved segment are explicitly defined in the linker script to ensure that the binary file generated by the main core software compilation includes this fixed reserved space.

[0072] Subsequently, address offsetting and firmware processing are performed on the hardware security module software, mapping the storage address of the hardware security module software to... Figure 3 In the main core software reserved area shown, it is assumed that the physical starting address of the main core software in the microcontroller backup partition is defined as... This parameter corresponds to Figure 3 The starting position of the backup partition, the offset of the reserved address region in the main core software for the hardware security module firmware relative to the starting address of the main core software is defined as follows: This parameter corresponds to Figure 3 The distance between the starting address of the main core software and the starting address of the embedded HSM firmware is the target link address of the hardware security module software when it is built as firmware. The following formula should be satisfied:

[0073] ;

[0074] in, It is the starting address of the backup partition in the microcontroller's flash memory. These are fixed constants defined in the linker script. This refers to the starting logical address set by the hardware security module firmware before merging. After calculating and setting the link address using this formula, the compiled hardware security module software is transformed into hardware security module firmware. The address information in its data structure no longer points to its final internal storage area, but instead points to... Figure 3 The predefined address range within the main core software.

[0075] Finally, a merging operation is performed to generate a unified executable file. Using binary file processing tools or programming scripts, the compiled main core software image file and the hardware security module firmware image file, which has undergone the address offset processing mentioned above, are merged. Since the address range of the hardware security module firmware falls precisely within the blank area reserved by the main core software, the data of the two files are complementary and do not overlap in logical address space. Therefore, they can be directly superimposed or filled to generate a single unified executable file. The external over-the-air download service deploys this unified executable file, which physically appears as a complete main core upgrade package, but carries a matching version of the hardware security module firmware in binary data form at a specific location within it.

[0076] The external over-the-air download server only needs to manage and distribute this single unified executable file. It does not need to be aware of the existence of the hardware security module, nor does it need to coordinate the download order of the two independent files. This simplifies the system solution process and improves the portability of the solution across different vehicle models or controllers. By physically merging the two software sets during the construction phase, the atomic binding between the main core software version and the hardware security module software version is forcibly guaranteed, reducing the risk of microcontroller malfunction or lockup due to version mismatch from the source.

[0077] S2. The main kernel software running in the current running partition receives a unified executable file, updates it to the main kernel software storage area of ​​the backup partition, and performs integrity verification on the updated backup partition main kernel software.

[0078] Furthermore, S2 specifically includes the following steps:

[0079] The OTA module of the main core software responds to the instructions issued by the OTA server and erases the main core software storage area of ​​the backup partition. The storage area covers the area used to store the HSM firmware.

[0080] Update the main core software and the HSM firmware contained therein in the backup partition storage according to the unified executable file content;

[0081] The main core software performs an integrity check on the updated backup partition main core software and HSM firmware.

[0082] Furthermore, the main core software performs integrity verification on the updated backup partition main core software and HSM firmware, specifically including the following steps:

[0083] Respond to the integrity verification trigger command issued by the OTA server;

[0084] The data in the backup partition's main core software storage area is read, including the main core software code and the HSM firmware embedded therein;

[0085] The read data is verified and compared to confirm the integrity of the backup partition's main core software and HSM firmware.

[0086] Specifically, combined Figure 5 , Figure 3 as well as Figure 4 When the over-the-air (OTA) download server triggers an upgrade task, the main core software running on the currently running partition, such as partition A, receives instructions through its internally integrated OTA download module and enters the second stage of the upgrade process.

[0087] First, the over-the-air (OTA) download module of the main core software responds to the erase command issued by the OTA download server. Please refer to... Figure 3 At this time, the microcontroller is in normal operation, and the main core software is running in the current partition. Upon receiving the update request, the over-the-air download module locks. Figure 3 The backup partition shown, such as the kernel software storage area on side B, was erased not only for the kernel code area but also across the entire backup partition, explicitly covering it. Figure 3 The designated address area shown for storing the hardware security module firmware ensures that the old version of the main core data and the old version of the hardware security module firmware remaining in the backup partition are completely cleared, thus making physical preparation for the writing of new data.

[0088] Next, the unified executable file writing operation is performed. The main core software receives the unified executable file data stream sent by the over-the-air download server and writes it. Figure 3 In the backup partition, since the hardware security module firmware has been embedded into the predetermined address offset of the main core software in step S1, the main core software does not need to identify which part of the data stream belongs to the main core code and which part belongs to the hardware security module firmware when performing a write operation. The main core software only needs to write the received data packets sequentially from the start address to the end address of the backup partition according to the continuous memory address order. The data stream flows directly from the external over-the-air download service to the main core storage area of ​​the backup partition via the main core over-the-air download module. At this time, the new hardware security module firmware is physically stored in the specific offset position of the backup partition, realizing the physical update at the data level.

[0089] Subsequently, the main core software performs an integrity verification step. After the data writing is completed, the over-the-air download server sends an integrity verification trigger command. The main core software responds to this command to perform a comprehensive verification of the data just written to the backup partition. To accurately describe this verification process, the following hash verification algorithm formula is used:

[0090] ;

[0091] The symbols in the formula are defined as follows: represent Figure 3 The physical starting address of the backup partition is a specific address parameter of non-volatile memory in the technical field. This represents the total length of the unified executable file, a value that includes the sum of the main core software code segment length and the embedded hardware security module firmware length. Represents the physical storage space of the microcontroller. Indicates from address One byte of binary data is read from the location. This represents a preset hash digest algorithm or cyclic redundancy check algorithm function. This is a verification result value calculated based on the actual storage content of the backup partition. The main core software will calculate the result. The value is compared with the expected verification value sent by the over-the-air download server. If the two are consistent, it is confirmed that the backup partition's main core software and the firmware of the hardware security module embedded in it are complete and error-free.

[0092] By uniformly erasing, writing, and verifying the hardware security module firmware as part of the main core software, the complexity of managing separate address ranges for the hardware security module firmware by the main core is avoided. The mechanism for verifying the overall data containing the hardware security module firmware can ensure that the firmware data in the backup partition is absolutely trustworthy and complete on the physical medium before triggering the subsequent hardware security module self-update process.

[0093] S3. If the integrity verification passes, the main core software triggers the self-update module inside the HSM. The self-update module updates the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location in the backup partition.

[0094] Furthermore, S3 specifically includes the following steps:

[0095] After the integrity check passes, the main core software checks whether the HSM firmware exists in the unified executable file;

[0096] If present, the main core software triggers the self-update module within the HSM software;

[0097] The self-update module reads the HSM firmware from the storage location of the main core software in the backup partition and writes it to the HSM software storage location in the backup partition.

[0098] Specifically, combined Figure 5 , Figure 6 as well as Figure 3 Once the main core software confirms that the data in the backup partition is complete and error-free, the system process proceeds to step S3, which enables the data migration from the main core storage space to the dedicated storage space of the hardware security module.

[0099] First, the main core software executes detection logic for the hardware security module firmware, referring to... Figure 5 In the decision branch, the main core software does not blindly trigger the self-update instruction. Instead, it first checks whether the unified executable file actually contains valid hardware security module firmware. This mechanism is to ensure compatibility with pure main core software upgrade scenarios that do not include hardware security module firmware. In practice, the main core software reads the data header or flag bit located at a predetermined address offset in the main core software storage area of ​​the backup partition. Assuming the predetermined address offset defined in the aforementioned steps is... The starting address of the backup partition is Main core software read address The content at that location, if the value read is... Equal to the preset valid identifier code For example, if a specific hexadecimal magic number is detected, the firmware is determined to exist. Otherwise, if the identifier is not detected, the main core software will skip the subsequent triggering steps and directly terminate the process for the hardware security module. This design ensures that the same over-the-air download service protocol can be flexibly adapted to controllers with different configurations.

[0100] Next, after confirming the existence of the firmware, the main core software triggers the self-update module within the hardware security module, such as... Figure 2 The main core and the hardware security module establish a communication channel through a bridge register or shared memory mechanism. The main core software writes a command word to start the update to a specific interactive register. The application software of the hardware security module polls or responds to this command through an interrupt, thereby activating the self-update module deployed inside it. Once the self-update module is started, it takes over the processing rights of the hardware security module firmware in the backup partition.

[0101] Subsequently, cross-regional data transfer and writing operations are performed, combined with Figure 6 and Figure 3 The self-update module needs to copy data temporarily stored in the main core area to the dedicated backup partition of the hardware security module. To clearly describe this data transfer process, the source address is defined. The starting physical address of the hardware security module firmware stored in the primary kernel backup partition satisfies... Define target address The firmware size is defined as the starting physical address of the backup partition in the internal memory of the hardware security module. The self-update module performs the write operation according to the following data transmission logic:

[0102] ;

[0103] Among them, variables Traverse from 0 to , This represents the non-volatile memory space managed by the main core. The self-update module accesses this space via the bus to read data. This represents the internal secure storage space managed by the hardware security module. The self-updating module programs the data it reads into this space. This represents the data assignment and burning operations. Through this cyclic process, the hardware security module firmware, which was originally in the main core software image, is completely stripped and transferred to the actual running location of the hardware security module, thus completing the physical layer firmware distribution.

[0104] By introducing a logic to detect the existence of the data, backward compatibility of the over-the-air download process is achieved. The actual write operation is performed by the self-update module inside the hardware security module, rather than by the main core directly writing to the storage area of ​​the hardware security module. This strictly adheres to the security isolation principle of the hardware security module and prevents the main core program from illegally tampering with or misoperating the secure storage area.

[0105] S4. Before performing the running partition switch and reset, the HSM self-update module uses the pre-configured backup partition key to pre-verify the main core software of the backup partition.

[0106] Furthermore, S4 specifically includes the following steps:

[0107] The HSM self-update module first verifies the integrity of the updated backup partition HSM software;

[0108] After the HSM software integrity verification passes, the main core software of the backup partition is verified using the backup partition key that has been pre-loaded into the secure storage area by the currently running partition program.

[0109] Furthermore, after the HSM software integrity verification passes, the main kernel software of the backup partition is verified using the backup partition key pre-packaged into the secure storage area by the currently running partition program. This verification specifically includes the following steps:

[0110] HSM receives the key jarming command from the main core software running on the currently running partition and stores the key that matches the software to be upgraded into the key slot of the secure storage area of ​​the corresponding backup partition;

[0111] The HSM self-update module reads the key of the corresponding backup partition from the secure storage area;

[0112] The read key is used to sign and verify the data in the backup partition's main core software storage area to confirm that the backup partition's main core software matches the key.

[0113] Specifically, combined Figure 6 , Figure 3 as well as Figure 5This step utilizes the independence of side A and side B to verify the security of the future operating environment in advance in the current operating environment.

[0114] First, the hardware security module's self-update module performs its own integrity check, as shown in the figure. Figure 6 After the self-update module writes the firmware to the backup partition of the hardware security module, in order to prevent the firmware from being corrupted due to bit flips or hardware failures during the writing process, the newly written data must be verified immediately. The self-update module reads the code data in the backup partition of the internal memory of the hardware security module, calculates its cyclic redundancy check value or hash digest, and compares it with the standard value carried in the firmware. Only when this step passes the verification and confirms that the software of the hardware security module itself is intact and operable will the process proceed to the next step. Otherwise, the update will be directly stopped and an error will be reported, thereby avoiding the hardware security module from failing due to loading corrupted software.

[0115] Next, key presetting and management operations are performed, which is a prerequisite for cross-validation. (Refer to...) Figure 3 Regarding the division of the key storage area, the microcontroller's secure storage area has key slots corresponding to the currently running partition and key slots corresponding to the backup partition. During the preparation or execution phase of the over-the-air download process, the main core software running on the currently running partition sends a key loading instruction to the hardware security module through the bridge register. This instruction carries key data that matches the new version of the main core software that will soon take effect. After receiving the instruction, the hardware security module does not distinguish whether the currently running partition is A or B, but writes the key data into the key slot of the secure storage area of ​​the backup partition according to the instruction target. This process achieves the early update of the root of trust of the backup partition without changing the key security of the currently running partition.

[0116] Subsequently, a pre-verification of the main kernel software based on the backup partition key is performed. This is the most critical step in this embodiment, corresponding to... Figure 6 In the main core software pre-verification stage, the hardware security module's self-update module reads the newly packaged key from the backup partition key slot in the secure storage area and uses this key to perform cryptographic verification on the main core software located in the main core backup partition. To clearly describe this verification algorithm, input parameters are defined. Define input parameters for the backup partition key data read from the secure storage area. Define a function to read the main kernel software binary code stream from the starting address of the main kernel backup partition. Define the output results for the secure boot verification algorithm embedded within the hardware security module, such as the CMAC algorithm or the RSA signature verification algorithm. For the Boolean validation result, the validation process satisfies the following logical relationship:

[0117] ;

[0118] In this formula, the hardware security module utilizes a key. Data Perform the calculation, if The result is true, which means that the new software physically stored in the main kernel backup partition is mathematically matched with the new key physically stored in the backup key slot in the secure storage area.

[0119] By introducing step S4 before the reset, the self-update module simulates the secure boot verification process after the reset in advance. Only when... Only when confirmed as true will the system be able to confidently assume that the reset backup partition can be successfully booted. This mechanism moves the risk interception point of secure boot forward, eliminating the risk of the microcontroller becoming unusable after downloading an upgrade over the air due to key mismatch or software tampering, thus improving the reliability and security of vehicle controller software updates.

[0120] S5. Only if the self-update of the HSM software and the pre-verification of the main core software both pass, is the OTA considered successful and a reset is performed to boot from the backup partition; otherwise, it remains running on the current running partition.

[0121] Furthermore, S5 specifically includes the following steps:

[0122] If the integrity verification of the HSM software and the pre-verification of the main core software are both successful, the HSM self-update module returns a self-update success status to the main core, the main core reports OTA success to the OTA server, and responds to the aspect and reset requests issued by the OTA server, performs a reset, and starts from the backup partition.

[0123] If any verification fails, the HSM self-update module returns a failure status, the OTA server does not send an aspect request, and the MCU continues to run in the current running partition until the next OTA startup.

[0124] Specifically, for successful paths where all verifications pass, when the hardware security module's self-update module confirms that the software integrity verification of its own backup partition has passed, and the pre-verification result of the main core software based on the backup partition key is also true, it generates a success status code, as shown below. Figure 6The hardware security module, through internal communication mechanisms such as bridge registers or shared memory flags, feeds back the successful self-update status to the main core software of the currently running partition. Upon receiving this signal, the main core software confirms that the entire upgrade package is physically and logically secure, and then sends an upgrade success message to the external over-the-air (OTA) download server via the vehicle network. After receiving confirmation, the OTA server issues an activation command. The main core software responds to this command, modifies the microcontroller's boot configuration word, points the boot pointer to the backup partition, and performs a system reset operation. Figure 5 After a successful branch and reset, the microcontroller directly loads the new main core software and hardware security module software from the backup partition. Since it had already passed the pre-verification, the boot process was completed smoothly, achieving a seamless switchover.

[0125] Next, any failed verification path is handled. If, in step S4, either the integrity verification of the hardware security module itself fails or the key matching pre-verification of the main core software fails, the hardware security module's self-update module will immediately terminate the process and generate an error code indicating failure. The hardware security module feeds back this self-update failure status to the main core software. After capturing the error, the main core software reports the upgrade failure and its specific error reason to the over-the-air download server. At this time, the critical logical protection mechanism takes effect: the over-the-air download server is designed to strictly prohibit the issuance of aspect activation commands and reset requests after receiving a failure report. Therefore, the microcontroller's boot configuration word remains unchanged and continues to point to the currently running partition, such as... Figure 5 In the event of a failed branch, the system does not perform a reset but continues to run stably in the current version, waiting for the next over-the-air download task to be initiated.

[0126] By employing strict logic that allows a reset only when all steps pass, system unavailability caused by blind restarts is avoided. This is especially important for the vehicle controller, where maintaining vehicle availability under all circumstances is the highest priority. Utilizing the redundancy of the A / B side partitions ensures that even if the new software has issues, the vehicle will only experience an upgrade failure without losing functionality. The user experience simply receives a failure message instead of facing a serious malfunction that prevents the vehicle from starting. At the same time, the detailed status feedback mechanism helps developers quickly pinpoint whether the upgrade failure is due to file corruption, key errors, or hardware failure, thus improving system maintainability.

[0127] This application also provides an MCU OTA implementation system including an HSM module, the system comprising:

[0128] The MCU main core is configured to receive a unified executable file, which is generated by the HSM firmware and embedded in the main core software with a predetermined address offset. The MCU main core is also used to write the unified executable file to the main core software storage area of ​​the backup partition and to perform integrity verification on the updated backup partition main core software. The HSM module has a self-updating module deployed inside.

[0129] The MCU main core triggers the self-update module after the integrity verification is passed.

[0130] The self-update module is configured to update the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location of the backup partition, and to pre-verify the main core software of the backup partition using the pre-configured backup partition key before performing the running partition switch and reset.

[0131] The system is configured to determine OTA success and perform a reset to boot from the backup partition only if both the HSM software self-update and the main core software pre-verification pass.

[0132] Specifically, the system's hardware architecture consists of a microcontroller main core and a hardware security module. The microcontroller main core is configured as the system's external communication and control hub. It receives a unified executable file from an external server via the vehicle network interface. During the build process, the hardware security module firmware is physically embedded into the main core software image using a predetermined address offset. The main core then writes the unified file as a whole into the backup partition storage area of ​​the microcontroller's flash memory via the internal bus. It then uses hash or cyclic redundancy check algorithms to verify the integrity of the backup partition data containing the embedded firmware after writing. The hardware security module has a built-in independent self-updating module. Once the main core confirms the data is complete, it triggers the module via the bridging interface. The self-update module then starts and moves the firmware from the main core storage area of ​​the backup partition to the backup storage area dedicated to the hardware security module. Immediately before the system is reset and the partition is switched, the self-update module calls the backup partition key pre-stored in the secure area to perform digital signature pre-verification on the software of the main core backup partition. The entire system follows strict security logic, that is, only when the firmware update verification of the hardware security module itself passes and the pre-verification of the main core software also passes at the same time, does the main core report success to the outside and modify the boot pointer to perform a reset, thereby guiding the system to boot securely from the backup partition.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for implementing OTA (Over-The-Air) testing of an MCU (Microcontroller System) including an HSM (Hardware Module), characterized in that, Includes the following steps: S1. Construct a unified executable file in which the HSM software is embedded as firmware at a predetermined address offset of the main core software. S2. The main kernel software running in the current running partition receives the unified executable file, updates it to the main kernel software storage area of ​​the backup partition, and performs integrity verification on the updated backup partition main kernel software. S3. If the integrity verification passes, the main core software triggers the self-update module inside the HSM. The self-update module updates the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location of the backup partition. S4. Before performing the running partition switch and reset, the HSM self-update module uses the pre-configured backup partition key to pre-verify the main core software of the backup partition; S5. Only when the self-update of the HSM software and the pre-verification of the main core software both pass, is the OTA determined to be successful and a reset is performed to start from the backup partition; otherwise, it remains running on the current running partition.

2. The MCU OTA implementation method including an HSM module according to claim 1, characterized in that, S1 specifically includes the following steps: Deploy a self-updating module within the HSM software; The address of the HSM software is offset to a predetermined location in the main core software and used as the HSM firmware; The HSM firmware and the main core software are merged to generate the unified executable file.

3. The MCU OTA implementation method including an HSM module according to claim 2, characterized in that, The process of merging the HSM firmware with the main core software to generate the unified executable file specifically includes the following steps: In the storage space planning of the main core software, a predetermined address area for storing the HSM firmware is determined; The address of the HSM software is offset to the predetermined address region to form the HSM firmware; The data of the HSM firmware is embedded into the predetermined address area of ​​the main core software to generate a unified executable file containing the main core software and the HSM firmware.

4. The MCU OTA implementation method including an HSM module according to claim 1, characterized in that, S2 specifically includes the following steps: The OTA module of the main core software responds to the instructions issued by the OTA server and erases the main core software storage area of ​​the backup partition, which includes the area used to store the HSM firmware; Update the main core software and the HSM firmware contained therein in the backup partition storage according to the unified executable file content; The main core software performs an integrity check on the updated backup partition main core software and HSM firmware.

5. The MCU OTA implementation method including an HSM module according to claim 4, characterized in that, The integrity verification of the updated backup partition main core software and HSM firmware by the main core software includes the following steps: Respond to the integrity verification trigger command issued by the OTA server; The data in the backup partition's main core software storage area is read, including the main core software code and the HSM firmware embedded therein; The read data is verified and compared to confirm the integrity of the backup partition's main core software and HSM firmware.

6. The MCU OTA implementation method including an HSM module according to claim 1, characterized in that, S3 specifically includes the following steps: After the integrity verification passes, the main core software checks whether the unified executable file contains HSM firmware; If present, the main core software triggers the self-update module within the HSM software; The self-update module reads the HSM firmware from the storage location of the main core software in the backup partition and writes it to the HSM software storage location in the backup partition.

7. The MCU OTA implementation method including an HSM module according to claim 1, characterized in that, S4 specifically includes the following steps: The HSM self-update module first verifies the integrity of the updated backup partition HSM software; After the HSM software integrity verification passes, the main core software of the backup partition is verified using the backup partition key that has been pre-loaded into the secure storage area by the currently running partition program.

8. The MCU OTA implementation method including an HSM module according to claim 7, characterized in that, After the HSM software integrity verification passes, the process of verifying the main kernel software of the backup partition using the backup partition key pre-loaded into the secure storage area by the currently running partition program includes the following steps: HSM receives the key jarming command from the main core software running on the currently running partition and stores the key that matches the software to be upgraded into the key slot of the secure storage area of ​​the corresponding backup partition; The HSM self-update module reads the key of the corresponding backup partition from the secure storage area; The read key is used to sign and verify the data in the backup partition's main core software storage area to confirm that the backup partition's main core software matches the key.

9. A method for implementing MCU OTA including an HSM module according to claim 1, characterized in that, S5 specifically includes the following steps: If the integrity verification of the HSM software and the pre-verification of the main core software are both successful, the HSM self-update module returns a self-update success status to the main core, the main core reports OTA success to the OTA server, and responds to the aspect and reset requests issued by the OTA server, performs a reset, and starts from the backup partition. If any verification fails, the HSM self-update module returns a failure status, the OTA server does not send an aspect request, and the MCU continues to run in the current running partition until the next OTA startup.

10. An MCU OTA implementation system including an HSM module, characterized in that, A method for implementing MCU OTA including an HSM module as described in any one of claims 1-9, the system comprising: The MCU main core is configured to receive a unified executable file, which is generated by the HSM firmware and embedded in the main core software with a predetermined address offset. The MCU main core is also configured to write the unified executable file to the main core software storage area of ​​the backup partition and perform integrity verification on the updated backup partition main core software. The HSM module has an internally deployed self-updating module. The MCU main core triggers the self-update module after the integrity verification is passed. The self-update module is configured to update the HSM firmware located in the main core software storage area of ​​the backup partition to the HSM software storage location of the backup partition, and to pre-verify the main core software of the backup partition using a pre-configured backup partition key before performing the running partition switch and reset. The system is configured to determine OTA success and perform a reset to boot from the backup partition only when both the self-update of the HSM software and the pre-verification of the main core software pass.

Images