A secure boot method and system based on MCU and electronic equipment

Abstract

The application relates to the technical field of microcontrollers, and discloses a safe starting method and system based on an MCU, an electronic device, a storage medium and a power utilization device. The code and data to be run are pre-divided into a first partition and a second partition. The method comprises the following steps: a main core calculates the hash value of the second partition, meanwhile, an HSM performs anti-tampering verification on the first partition based on a first key to obtain a first verification value, and the first verification value is compared with a first reference value; after the first partition verification passes, the HSM determines a second verification value according to the hash value of the second partition and a second key; the second verification value is compared with a second reference value, and whether to allow starting is determined based on the comparison result. Through the technical scheme, the problem that high safety performance and short starting time cannot be achieved simultaneously in the related art is solved, and the safety starting time of the MCU is effectively shortened under the premise of ensuring safety.

Description

Technical Field

[0001] This application relates to the field of microcontroller technology, specifically to a secure boot method, system, and electronic device based on an MCU. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, Electronic Control Units (ECUs) face serious security threats such as malicious firmware tampering and the injection of illegal code. Meanwhile, according to the national standard GB / T44495, gateway devices must possess a boot protection mechanism based on a hardware root of trust. To ensure the reliability of the system's operating environment, the industry commonly employs Secure Boot technology, relying on the chip's built-in Hardware Security Module (HSM) as the root of trust to build a trust chain during system power-on, verifying the boot code at each level step by step.

[0003] In secure boot technologies, the HSM core is responsible for verifying all code that the main core is about to execute. Since the performance of the HSM core is typically weak, verifying all running code, while ensuring security, significantly increases boot time, raises development risks, or necessitates the use of a higher-performance microcontroller unit (MCU), increasing hardware costs. Conversely, if only a portion of the code is verified to ensure boot time, the unverified code will still execute, introducing security risks. Furthermore, these technologies often use a single verification method throughout the entire verification process, lacking diversity in verification methods, further increasing security risks.

[0004] Therefore, it is evident that in related technologies, it is difficult to achieve both high security performance and short startup time in MCUs. In other words, it is difficult to effectively shorten the safe startup time of MCUs while ensuring security. Summary of the Invention

[0005] This application provides a secure boot method, system, and electronic device based on an MCU to solve the problem of effectively shortening the secure boot time of an MCU while ensuring security.

[0006] In a first aspect, this application provides a secure boot method based on an MCU, wherein the MCU includes a main core and an HSM, and the MCU stores code and data to be executed, which belong to the execution area. The code and data to be executed are pre-divided into a first partition and a second partition. The method includes: The hash value of the second partition is calculated by the main core, and the first partition is verified by HSM based on the first key to obtain the first verification value. The first verification value is then compared with the first reference value. After the first partition verification passes, the second verification value is determined by HSM based on the hash value of the second partition and the second key; The second check value is compared with the second reference value, and the decision on whether to allow startup is based on the comparison result.

[0007] In one optional implementation, the first partition is tamper-proof verified using an HSM based on a first key to obtain a first verification value, and the first verification value is compared with a first reference value, including: Using HSM, a first checksum is calculated based on the first key pair and the data in the first partition using the CMAC algorithm; the first checksum is then compared with a first reference value.

[0008] In one optional implementation, calculating the hash value of the second partition via the main core includes: Based on the characteristics of the chip, a hash algorithm is selected from a preset set of algorithms; The selected hash algorithm is used to perform a hash operation on the data in the second partition to obtain the hash value of the second partition.

[0009] In one optional implementation, determining the second checksum via the HSM based on the hash value of the second partition and the second key includes: Using HSM, the second checksum is calculated using the CMAC algorithm based on the hash value of the second partition of the second key pair.

[0010] In one optional implementation, comparing the second check value with the second reference value and determining whether to allow startup based on the comparison result includes: If the second check value matches the second reference value, then jump to the application code is allowed; if the second check value does not match the second reference value, then startup is prevented.

[0011] In one alternative implementation, before comparing the verification result with the first reference value, the method further includes: Using HSM, a first reference value is calculated based on the data in the first partition using the CMAC algorithm, and the first reference value is stored in the storage area of ​​HSM; The main core calculates the hash value of the data in the second partition, and the HSM calculates the second reference value based on the hash value of the data in the second partition using the CMAC algorithm, and stores the second reference value in the storage area of ​​the HSM.

[0012] In an optional implementation, when the MCU adopts a dual-partition storage strategy, it also includes a non-running area, in which code and data are pre-divided into corresponding first and second partitions, and the method is executed independently on the non-running area.

[0013] Secondly, this application provides an MCU secure boot system, comprising: a main core; an HSM, the HSM including a dedicated storage area storing a first key and a second key, as well as a pre-generated first reference value and a second reference value; a storage area storing code and data to be run, the code and data belonging to the running area and pre-divided into a first partition and a second partition; during the secure boot verification phase, the main core is used to calculate the hash value of the second partition, while the HSM is used to calculate a first verification value based on the first key and the data in the first partition using the CMAC algorithm, and compare the first verification value with the first reference value; the HSM is also used to calculate a second verification value based on the hash value of the second partition and the second key after the first partition verification is passed, using the CMAC algorithm; the main core is used to compare the second verification value with the second reference value, and determine whether boot is allowed based on the comparison result.

[0014] Thirdly, this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the MCU-based secure boot method described in the first aspect or any corresponding embodiment thereof.

[0015] Fourthly, this application provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the MCU-based secure boot method described in the first aspect or any corresponding embodiment thereof.

[0016] Fifthly, this application provides an electrical device including the MCU secure boot system as described in the second aspect above.

[0017] According to the MCU-based secure boot method provided in this application, the code and data to be run are pre-divided into a first partition and a second partition. This allows the main core and HSM to perform parallel verification operations on different partitions during the verification phase, fully utilizing the computing power of the main core and shortening the overall verification time. By having the main core calculate the hash value of the second partition while the HSM performs anti-tampering verification on the first partition, parallel execution of two different verification methods is achieved. This ensures the security of the verification and avoids the risk of a single verification method failing due to an attack through a differentiated verification strategy. After the first partition passes verification, the HSM determines the second checksum only based on the hash value of the second partition, rather than performing byte-by-byte verification on all data in the second partition, further shortening the verification time. Finally, the comparison between the second checksum and the second reference value determines whether boot is allowed, ensuring the reliability of the verification result. Therefore, this application effectively shortens the MCU secure boot time while ensuring security, achieving a balance between high security performance and short boot time. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a secure boot method based on an MCU according to an embodiment of this application; Figure 2 This is a flowchart of another MCU-based secure boot method according to an embodiment of this application; Figure 3 This is a schematic diagram of a process for updating code verification information according to an embodiment of this application; Figure 4 This is a flowchart illustrating a verification code information according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0022] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] In related technologies, MCU secure boot schemes present a trade-off between security performance and boot time. This application provides a secure boot method based on an MCU, which pre-divides the code and data to be run into a first partition and a second partition. During the verification phase, the main core and HSM perform differentiated verifications on different partitions in parallel. After the first partition passes verification, the HSM only re-verifies the hash value of the second partition, thereby effectively shortening the boot time while ensuring security.

[0024] According to an embodiment of this application, a secure boot method based on an MCU is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] This embodiment provides a secure boot method based on an MCU. The MCU includes a main core and an HSM (Hardware Module). The MCU stores code and data to be executed, which belong to the execution area. The code and data to be executed are pre-divided into a first partition and a second partition. This method can be used in embedded devices such as vehicle ECUs that use MCUs to implement secure boot. Figure 1 This is a flowchart of a secure boot method based on an MCU according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Calculate the hash value of the second partition through the main core, and at the same time perform anti-tampering verification on the first partition based on the first key through HSM to obtain the first verification value, and compare the first verification value with the first reference value.

[0026] Specifically, MCU refers to a microcontroller unit that integrates a processor core, memory, and peripherals. The main core refers to the general-purpose processor core in the MCU that runs application code. HSM refers to the hardware security module built into the MCU chip, which has its own central processing unit, memory, and Flash storage space, serving as the system's root of trust. The code and data to be executed refers to the firmware that the MCU will execute upon power-up, such as the bootloader and application firmware. The running area refers to the currently active partition in the dual-partition storage strategy from which the MCU will load code and data. The first partition refers to the portion of the code and data to be executed that is demarcated and verified by the HSM for tamper-proofing. The second partition refers to the portion of the code and data to be executed that is demarcated and hashed by the main core. The first key refers to the symmetric key stored in a dedicated storage area of ​​the HSM, used for performing Cipher-based Message Authentication Code (CMAC) operations on the data in the first partition. Tamper-proofing verification refers to the verification operation that verifies whether data has been illegally modified using the CMAC algorithm. The first checksum is the value calculated by HSM using the CMAC algorithm on the current data in the first partition based on the first key during the verification phase. This value is compared with the first reference value pre-stored during the write phase to determine whether the data in the first partition has been tampered with. The first reference value is the CMAC value of the first partition data pre-generated and stored in the HSM storage area during the write phase, serving as the comparison benchmark for the verification phase.

[0027] In this step, the main core and HSM execute their respective verification operations in parallel: On the main core side, a hash operation is performed on the data in the second partition to obtain the hash value of the second partition; on the HSM side, a first checksum is calculated using the CMAC algorithm on the data in the first partition based on the first key, and the first checksum is compared with the first reference value. By executing the main core and HSM in parallel, the idle computing power of the main core is used for the hash operation of the second partition, so that the HSM only needs to verify the data in the first partition, rather than the entire code, thereby shortening the overall verification time while ensuring security.

[0028] In one possible implementation, the first partition stores the bootloader's startup code, and the second partition stores the application code. The main core uses a Secure Hash Algorithm (SHA), such as SHA-256, to hash the application code in the second partition. Simultaneously, the HSM performs a CMAC operation on the startup code in the first partition based on a first key stored in its Flash area to obtain a first checksum. This first checksum is then compared with a first reference value pre-stored during the flashing phase. If they match, the first partition verification passes.

[0029] Step S102: After the first partition verification passes, the second verification value is determined by the HSM based on the hash value of the second partition and the second key.

[0030] Specifically, the second key refers to a symmetric key stored in a dedicated storage area of ​​the HSM, used for performing CMAC operations on the hash value of the second partition, and is independent of the first key. The second checksum is the CMAC value calculated by the HSM based on the hash value of the second partition and the second key, used for comparison with the second reference value pre-stored during the write phase.

[0031] In this step, after the first partition verification passes, the HSM uses the second key to calculate the second verification value based on the hash value of the second partition obtained by the main core in step S101 using the CMAC algorithm. Since the HSM only needs to perform CMAC operations on the hash value of the second partition, rather than performing byte-by-byte CMAC operations on the entire data of the second partition, the length of the hash value is much smaller than the total length of the data in the second partition. Therefore, the computation time of this step is significantly reduced. Through the cooperation of this step and step S101, the HSM directly verifies only the entire data of the first partition in the entire verification process, and only verifies the hash value of the second partition, thereby significantly shortening the overall startup time while ensuring security.

[0032] In one possible implementation, after the main core completes the SHA-256 hash operation on the second partition in step S101, it obtains a 32-byte hash value for the second partition. The HSM reads the second key from its own Flash area and performs a CMAC operation on the 32-byte hash value based on the second key to obtain the second checksum. At this point, the amount of data for the HSM's CMAC operation is only 32 bytes, while if the CMAC operation were performed directly on the entire data of the second partition, the amount of data could reach hundreds of kilobytes. Therefore, this step, by performing CMAC operation only on the hash value, significantly reduces the computational burden and time consumption of the HSM, and is a key step in shortening the overall startup time.

[0033] Step S103: Compare the second check value with the second reference value, and determine whether to allow startup based on the comparison result.

[0034] The second reference value refers to the value obtained by performing CMAC operation on the hash value of the second partition data in the dedicated storage area of ​​the HSM, which is pre-generated and stored in the writing phase, and serves as the comparison benchmark for the second verification value in the verification phase.

[0035] In this step, the main core compares the second checksum calculated by the HSM in step S102 with the pre-stored second reference value. If they match, it indicates that the data in the second partition has not been tampered with since it was flashed. Combined with the fact that the first partition has passed the checksum in step S101, all the code and data to be run have passed the checksum, allowing the MCU to jump to the application code and start normally. If they do not match, it indicates that the data in the second partition has been illegally modified. The main core prevents the startup, and the MCU remains in the bootloader area or enters a security penalty state. This step, as the final decision-making link in the entire secure startup checksum process, ensures the credibility of the startup process based on the complete link of dual checksums (first partition CMAC checksum and second partition hash value CMAC checksum).

[0036] In one possible implementation, the second reference value pre-stored during the flashing stage is 0x8A3F…, and the second check value calculated by the HSM in step S102 is also 0x8A3F…. The main core compares the two and confirms they are consistent, determining that all code and data to be executed have passed verification, allowing the MCU to jump from the bootloader to the application code and complete the startup process normally. If the second check value is 0x6B2D…, which is inconsistent with the second reference value, the main core prevents the jump, and the MCU remains in the bootloader area. Simultaneously, it can report a safety event to the vehicle domain controller via the Controller Area Network (CAN) bus.

[0037] The MCU-based secure boot method provided in this embodiment pre-divides the code and data to be run into a first partition and a second partition. This allows the main core and HSM to perform parallel verification operations on different partitions during the verification phase, fully utilizing the main core's computing power and shortening the overall verification time. By having the main core calculate the hash value of the second partition while the HSM performs anti-tampering verification on the first partition, parallel execution of two different verification methods is achieved. This ensures verification security and avoids the risk of a single verification method failing due to an attack through a differentiated verification strategy. After the first partition passes verification, the HSM determines the second checksum only based on the hash value of the second partition, rather than performing byte-by-byte verification on all data in the second partition, further shortening the verification time. Finally, the comparison between the second checksum and the second reference value determines whether boot is allowed, ensuring the reliability of the verification result. Therefore, this embodiment effectively shortens the MCU secure boot time while ensuring security, breaking the contradiction between security performance and boot time.

[0038] This embodiment provides a secure boot method based on an MCU. The MCU includes a main core and an HSM (Hardware Management System). The MCU stores code and data to be executed, which belong to the execution area. The code and data to be executed are pre-divided into a first partition and a second partition. This method can be used in the aforementioned embedded devices. Figure 2 This is a flowchart of another MCU-based secure boot method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps: Step S201: Calculate the hash value of the second partition through the main core, and at the same time perform anti-tampering verification on the first partition based on the first key through HSM to obtain the first verification value, and compare the first verification value with the first reference value.

[0039] Specifically, step S201 above, which verifies the first partition using the HSM, includes the following steps: Step S2011a: Using the HSM, calculate the first checksum based on the data in the first partition using the CMAC algorithm.

[0040] Specifically, the HSM reads the first key from its dedicated storage area, and calculates the message authentication code using the CMAC algorithm on the current data in the first partition based on the first key to obtain the first verification value. Since the CMAC operation is performed in the hardware acceleration engine of the HSM, and the main core, which runs in parallel with the HSM, simultaneously performs hash operations on the second partition, this step ensures the security of the tamper-proof verification without adding extra time to the overall verification process.

[0041] In one possible implementation, the first partition stores the bootloader's startup code. The HSM reads the first key from its own Flash area, performs an AES-CMAC algorithm on all the bytes of the startup code, and outputs a first checksum of 16 bytes.

[0042] Step S2012a: Compare the first check value with the first reference value.

[0043] Specifically, the HSM compares the first checksum calculated in step S2011a with the first reference value pre-stored in the HSM's dedicated storage area during the flashing phase. If they match, it indicates that the data in the first partition has not been tampered with since the flashing, and the first partition verification passes; if they do not match, it indicates that the data in the first partition has been illegally modified, and the MCU enters a security penalty state.

[0044] In one possible implementation, the first reference value pre-stored during the flashing stage is 0x7B2D…, and the first check value calculated in step S2011a is 0x7B2D…. The HSM compares the two and if they match, the first partition check is deemed successful, and the subsequent check process continues. If the first check value is 0x3F8A…, which is inconsistent with the first reference value, the MCU stops the startup process and remains in the bootloader area.

[0045] The step S201 above, which calculates the hash value of the second partition using the main core, includes the following steps: Step S2011b: Based on the chip characteristics, select a hash algorithm from the preset algorithm set.

[0046] Specifically, chip characteristics refer to the hardware capabilities inherent in the MCU chip itself, such as whether it has an SHA-256 hardware acceleration engine or supports instruction set extensions for specific hash algorithms. The preset algorithm set refers to a pre-configured list of candidate hash algorithms available for use by the main core, including integrity verification algorithms such as SHA-256, SHA-1, and MD5.

[0047] In this step, the main core selects the most suitable hash algorithm for the MCU chip from a preset algorithm set based on the chip's hardware characteristics. By selecting a hash algorithm based on chip characteristics, the chip's hardware acceleration capabilities can be fully utilized, further reducing computation time when the main core performs hash operations.

[0048] In one possible implementation, the MCU chip has a built-in SHA-256 hardware acceleration engine. The main core selects the SHA-256 algorithm from a preset algorithm set, and the subsequent hash operation on the second partition is completed by the hardware acceleration engine. Compared with pure software implementation, the calculation speed is increased by several times.

[0049] Step S2012b: Using the selected hash algorithm, perform a hash operation on the data in the second partition to obtain the hash value of the second partition.

[0050] Specifically, the main core uses the hash algorithm selected in step S2011b to perform hash operations on all data in the second partition, mapping data of arbitrary length in the second partition to hash values ​​of fixed length. In this step, the hash operation of the main core and the CMAC verification of the first partition by the HSM are executed in parallel. The hash calculation of the second partition is completed synchronously using the time window of the HSM verification of the first partition, so that the computing power of the main core is fully utilized in the verification process.

[0051] In one possible implementation, the main core uses the SHA-256 algorithm to hash the application code in the second partition, mapping hundreds of kilobytes of application code into a hash value of 32 bytes. This hash value will be used as the input for the CMAC operation of the HSM in step S202 below, thereby avoiding the HSM's byte-by-byte verification of the entire data in the second partition.

[0052] Step S202: After the first partition verification passes, the second verification value is determined by the HSM based on the hash value of the second partition and the second key.

[0053] Specifically, step S202 above includes the following steps: Step S2021: Using HSM, calculate the second check value based on the hash value of the second partition of the second key pair using the CMAC algorithm.

[0054] Specifically, the HSM reads the second key from its dedicated storage area, and uses the CMAC algorithm to calculate the hash value of the second partition obtained by the main core in step S201 based on the second key, thus obtaining the second verification value. Since the HSM's operation object is only the hash value of the second partition, and the length of the hash value is much smaller than the total length of the data in the second partition, the time consumption of the CMAC operation in this step is greatly reduced.

[0055] In one possible implementation, after the main core performs a SHA-256 hash operation on the second partition in step S201, it obtains a hash value of 32 bytes. The HSM reads the second key from its own Flash area and performs an AES-CMAC operation on the 32-byte hash value, outputting a second checksum of 16 bytes. If the CMAC operation were performed directly on the entire data of the second partition, hundreds of kilobytes of data would need to be processed, while this step only processes 32 bytes, reducing the computational burden of the HSM by several orders of magnitude.

[0056] Step S203: Compare the second check value with the second reference value, and determine whether to allow startup based on the comparison result.

[0057] Specifically, step S203 above includes the following steps: Step S2031: If the second verification value matches the second reference value, then jump to the application code is allowed.

[0058] Specifically, application code refers to the main firmware that the MCU will execute after completing the secure boot verification, such as the application image in the vehicle ECU that implements vehicle control functions.

[0059] In this step, when the second check value matches the second reference value, it indicates that the data in the second partition has not been tampered with since it was flashed. Combined with the fact that the first partition has passed the check, all the code and data to be run have passed the secure boot check. The main core allows the MCU to jump from the bootloader to the application code and complete the boot process normally.

[0060] In one possible implementation, the second check value and the second reference value are both 0x8A3F… The main core compares the two and finds them to be consistent, determining that all code and data to be run have passed the verification. The MCU then jumps from the bootloader to the application code, and the application begins to run normally.

[0061] Step S2032: If the second check value is inconsistent with the second reference value, then prevent startup.

[0062] In this step, if the second checksum does not match the second reference value, it indicates that the data in the second partition has been illegally modified, posing a security risk of firmware tampering. The main core prevents the MCU from jumping to the application code, and the MCU remains in the bootloader area, not executing the tampered code. By preventing boot, it ensures that only verified code and data can be executed, guaranteeing the reliability of the system's operating environment.

[0063] In one possible implementation, the second check value is 0x6B2D…, which is inconsistent with the second reference value 0x8A3F… stored during the flashing stage. The main core determines that the application code in the second partition has been tampered with, prevents the jump, and the MCU stays in the bootloader area. At the same time, it reports a safe boot failure event to the vehicle domain controller via the CAN bus.

[0064] In some optional implementations, the following steps are included before step S201: Step a1: Using the HSM, the first reference value is calculated based on the data in the first partition using the CMAC algorithm and stored in the storage area of ​​the HSM.

[0065] Step a2: Calculate the hash value of the data in the second partition using the main core, and use the CMAC algorithm based on the hash value of the data in the second partition using the second key in the HSM to calculate the second reference value, and store the second reference value in the storage area of ​​the HSM.

[0066] Specifically, this implementation pre-calculates the reference value during the flashing phase. After the code and data to be executed are flashed to the MCU's storage area, the HSM performs CMAC operations on the data in the first partition based on the first key to obtain the first reference value, which is then stored in the HSM's dedicated storage area. Simultaneously, the main core calculates the hash value of the data in the second partition, and the HSM then performs CMAC operations on this hash value based on the second key to obtain the second reference value, which is then stored. By concentrating the calculation and storage of the reference value into a single flashing phase, the pre-stored reference value can be directly read for comparison during each subsequent secure boot verification, eliminating the need for repeated calculations. This reduces the computational overhead of the boot verification phase while ensuring security.

[0067] In one possible implementation, after the flashing process is complete, the HSM reads the first key from its own Flash area, performs an AES-CMAC operation on the bootloader code in the first partition to obtain a first reference value, and stores it in the HSM's Data Flash. The main core uses the SHA-256 algorithm to hash the application code in the second partition to obtain a 32-byte hash value. The HSM then reads the second key from its own Flash area, performs an AES-CMAC operation on this hash value to obtain a second reference value, and stores it in the HSM's Data Flash. Subsequently, each time the MCU powers on, it can directly read the pre-stored first and second reference values ​​from the HSM's Data Flash for comparison during the verification phase.

[0068] In this implementation, a first reference value and a second reference value are pre-generated during the writing phase and stored in the dedicated storage area of ​​the HSM. This provides a reliable comparison benchmark for the parallel verification and final comparison during the verification phase, forming the basic link of the secure startup trust chain.

[0069] In some alternative implementations, when the MCU adopts a dual-partition storage strategy, a non-running area is also included, in which code and data are pre-divided into corresponding first and second partitions, and methods are executed independently in the non-running area.

[0070] Specifically, the dual-partition storage strategy refers to a storage architecture where the MCU's storage area is divided into two independent partitions: a running partition and a non-running partition. The running partition stores the currently active firmware, while the non-running partition stores the new firmware or backup firmware after an over-the-air (OTA) upgrade. After the MCU powers on, it loads code and data from the running partition for execution. Once the OTA upgrade is complete, the non-running partition can be switched to the new running partition, and the MCU can boot from it.

[0071] In this embodiment, the MCU's storage area comprises two partitions: a running area and a non-running area. The running area stores currently active code and data to be executed, while the non-running area stores new code and data after OTA upgrades or backup code and data. The code and data in the non-running area are also pre-divided into a first partition and a second partition, and the aforementioned verification process is independently executed on the non-running area when the MCU needs to boot from it. By including both partitions in the secure boot verification scope, it is ensured that regardless of whether the MCU boots from the running area or the non-running area, all code and data to be executed undergo parallel differentiated verification, avoiding the problem of security blind spots in the non-running area caused by only verifying the running area.

[0072] In one possible implementation, the MCU employs an A / B dual-partition OTA strategy. The runtime area stores the currently executing V1.0 firmware, while the non-runtime area stores the downloaded V2.0 firmware. The runtime and non-runtime areas are each divided into a first partition and a second partition, with corresponding first and second reference values ​​pre-stored in the HSM's dedicated storage area. After the OTA upgrade is complete, the MCU restarts. If the V2.0 firmware needs to be loaded from the non-runtime area, the aforementioned verification process is independently executed on the first and second partitions of the non-runtime area. Upon successful verification, the system jumps to the V2.0 application code.

[0073] Figure 3 This is a schematic flowchart illustrating an update of code verification information according to an embodiment of this application. The flowchart describes the process of pre-calculating a first reference value and a second reference value and storing them in the HSM dedicated storage area during the flashing phase. Figure 3 As shown, the process mainly includes three stages: data preparation, verification value calculation, and secure storage.

[0074] First, the system initiates the update process to determine the code and data to be run in the current running area. This code and data have been pre-divided into the first partition (equivalent to area A in this diagram) and the second partition (equivalent to area B in this diagram).

[0075] During the data preparation and verification value calculation phase, the system employs a differentiated algorithm strategy for the first and second partitions: For the first partition, the HSM performs a CMAC operation on the complete code data in the first partition based on the first key stored in its own dedicated storage area to obtain a first reference value. The CMAC operation has both message authentication and integrity verification functions, and can effectively detect whether the data has been tampered with.

[0076] For the second partition, the main core first performs a hash operation on the code data in the second partition to obtain the hash value of the second partition data; then, the HSM performs a CMAC operation on the hash value based on the second key to obtain the second reference value. By calculating the hash value first and then performing a CMAC operation on the hash value, the performance overhead caused by the HSM directly performing a CMAC operation on the entire data of the second partition is avoided while maintaining the authentication strength.

[0077] During the secure storage phase, the system pairs and stores the calculated critical verification information into a dedicated storage area of ​​the HSM: the address information of the first partition is stored corresponding to the first reference value, and the address information of the second partition is stored corresponding to the second reference value. By embedding the verification reference information in a physically isolated dedicated storage area of ​​the HSM, it ensures that during subsequent secure boot verification, the main core cannot bypass the HSM to directly modify the reference base value, providing hardware-level root of trust protection for reliable MCU boot and firmware upgrades. After storage is complete, the flashing phase ends, and the MCU can enter the boot-ready state.

[0078] In one possible implementation, area A stores the bootloader's startup code. The HSM reads a first key from its own Flash area, performs an AES-CMAC operation on the startup code to obtain a first reference value M, and stores the start and end addresses of area A and M together in the HSM's Data Flash. The main core uses the SHA-256 algorithm to hash the application code in area B to obtain a hash value C. The HSM reads a second key from its own Flash area, performs an AES-CMAC operation on C to obtain a second reference value D, and stores the start and end addresses of area B and D together in the HSM's Data Flash. Each subsequent power-on boot can directly read the pre-stored first and second reference values ​​from the HSM's Data Flash for verification and comparison. Through the update code verification information process provided in this embodiment, the calculation and secure storage of reference values ​​are completed in one go during the flashing stage, providing a reliable comparison benchmark for subsequent secure boot verification.

[0079] Figure 4 This is a flowchart illustrating a verification code information method according to an embodiment of this application. The flowchart describes the detailed interactive logic of real-time online verification performed by the system during the startup guidance phase before redirecting to the APP (application). Figure 3 Corresponding to the "brush pre-computation stage", this stage is the "runtime verification stage", which is completed by the Host (main core) and HSM (hardware security module) in collaboration, aiming to ensure the integrity and authenticity of the code to be executed.

[0080] According to the flowchart, the verification logic uses different verification paths for partitions A and B, but both use HSM as the root of trust: 1. Region A (CMAC Validation) This path is completed entirely within a closed loop inside the HSM, without exposing any sensitive raw data to the Host: HSM directly calls the key Z stored in its own Flash to calculate the CMAC value N of the code data in region A of the current MCU in real time.

[0081] The HSM automatically reads the reference base value M that was previously stored in the secure Flash.

[0082] HSM internally compares the calculated value N with the baseline value M. If they match (OK in the diagram), the subsequent process continues; if they do not match (NOK in the diagram), the internal penalty mechanism is triggered directly (such as logging a security event or preventing startup).

[0083] 2. Region B (Hash operation and CMAC hybrid verification) This path is initiated by the Host for computation, but core authentication is still controlled by the HSM, balancing efficiency and security for large-scale data processing. The Host first calculates the hash value G of the code data in region B of the current MCU and passes it to the HSM.

[0084] After receiving G, the HSM uses the internally stored key Y to perform CMAC operation on the hash value to generate a dynamic check value H.

[0085] At the same time, the HSM reads the previously stored reference CMAC value D from its dedicated Flash memory.

[0086] The HSM internally compares the dynamic value H with the baseline value D and returns the final comparison result (OK / NOK in the figure) to the Host.

[0087] 3. Initiation Decision and Security Response If any check result in area A or area B is NOK (failed), the system will immediately execute a penalty policy (such as triggering a system reset, prohibiting the APP from jumping, or entering a security error handling loop) to prevent unauthorized or corrupted code from running.

[0088] The system will only allow the program to continue execution and jump to the APP to run normally when both area A and area B return OK.

[0089] By combining the "closed-loop verification within hardware in Zone A" with the "auxiliary verification in hardware in Zone B" in this dual-path design, the process ensures a high level of security (Zone A) while also optimizing the verification speed of large firmware (Zone B), fully demonstrating the core role of HSM as a "trusted anchor point" in real-time secure boot.

[0090] This embodiment also provides a secure boot system based on an MCU, the system including: a main core; HSM, HSM includes a dedicated storage area, in which a first key and a second key are stored, as well as a pre-generated first reference value and a second reference value; The storage area stores code and data to be run. The code and data to be run belong to the running area and are pre-divided into the first partition and the second partition. During the secure boot verification phase, the main core is used to calculate the hash value of the second partition, while the HSM is used to calculate the first check value based on the data in the first partition using the CMAC algorithm, and compare the first check value with the first reference value. HSM is also used to calculate the second check value based on the hash value of the second partition and the second key after the first partition verification passes, using the CMAC algorithm. The main core is used to compare the second check value with the second reference value and determine whether to allow startup based on the comparison result.

[0091] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0092] The following is a detailed reference. Figure 5 This diagram illustrates a suitable structural schematic for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0093] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0094] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 509, or installed from memory 508, or installed from ROM 502. When the computer program is executed by processor 501, it performs the functions defined in the MCU-based secure boot method of embodiments of this application.

[0095] Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0096] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the MCU-based secure boot method shown in the above embodiments is implemented.

[0097] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0098] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A secure boot method based on an MCU, characterized in that, The MCU includes a main core and an HSM (Hard Streaming Management System). The MCU stores code and data to be executed, which belong to the execution area. The code and data to be executed are pre-divided into a first partition and a second partition. The method includes: The hash value of the second partition is calculated by the main core, and the first partition is verified by the HSM based on the first key to obtain the first verification value. The first verification value is then compared with the first reference value. After the first partition verification passes, the HSM determines the second verification value based on the hash value of the second partition and the second key. The second check value is compared with the second reference value, and the decision on whether to allow startup is based on the comparison result.

2. The method according to claim 1, characterized in that, The step of performing tamper-proof verification on the first partition based on the first key using the HSM to obtain a first verification value, and comparing the first verification value with a first reference value, includes: Using the HSM, the first checksum is calculated based on the first key and the CMAC algorithm is applied to the data in the first partition; The first check value is compared with the first reference value.

3. The method according to claim 1, characterized in that, The step of calculating the hash value of the second partition through the main core includes: Based on the characteristics of the chip, a hash algorithm is selected from a preset set of algorithms; The selected hash algorithm is used to perform a hash operation on the data in the second partition to obtain the hash value of the second partition.

4. The method according to claim 1, characterized in that, The step of determining the second verification value through the HSM based on the hash value of the second partition and the second key includes: Using the HSM, the second checksum is calculated using the CMAC algorithm based on the hash value of the second partition against the second key.

5. The method according to claim 1, characterized in that, The step of comparing the second verification value with the second reference value and determining whether to allow startup based on the comparison result includes: If the second verification value matches the second reference value, then a jump to the application code is allowed; If the second check value is inconsistent with the second reference value, then startup will be prevented.

6. The method according to claim 1, characterized in that, Before comparing the verification result with the first reference value, the method further includes: Using the HSM, the first reference value is calculated based on the first key using the CMAC algorithm on the data in the first partition, and the first reference value is stored in the storage area of ​​the HSM; The main core calculates the hash value of the data in the second partition, and the HSM calculates the second reference value based on the hash value of the data in the second partition using the CMAC algorithm based on the second key, and stores the second reference value in the storage area of ​​the HSM.

7. The method according to claim 1, characterized in that, When the MCU adopts a dual-partition storage strategy, it also includes a non-running area. The code and data in the non-running area are pre-divided into corresponding first and second partitions, and the method is executed independently in the non-running area.

8. A secure boot system based on an MCU, characterized in that, include: Main core; HSM, the HSM includes a dedicated storage area, the dedicated storage area storing a first key and a second key, as well as a pre-generated first reference value and a second reference value; The storage area stores code and data to be run, which belong to the running area and are pre-divided into a first partition and a second partition. During the secure boot verification phase, the main core is used to calculate the hash value of the second partition, while the HSM is used to calculate the first check value based on the first key using the CMAC algorithm, and compare the first check value with the first reference value. The HSM is also used to calculate a second verification value based on the hash value of the second partition and the second key after the first partition verification passes; The main core is used to compare the second check value with the second reference value, and determine whether to allow startup based on the comparison result.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the MCU-based secure boot method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the MCU-based secure boot method as described in any one of claims 1 to 7.

11. An electrical appliance, characterized in that, Including the MCU-based secure boot system as described in claim 8.

Images