A secure starting method of MCU with fusion function safety

Abstract

The application belongs to the chip security technical field, and particularly relates to a kind of MCU safety starting method of fusion function safety, by burning and verifying the security boot program and firmware program of main and redundant starting surface in factory environment, the safety and reliability of starting process are ensured.The security and reliability of starting process are ensured by burning and verifying the security boot program and firmware program of main and redundant starting surface in factory environment, and memory protection and privilege / user mode protection mechanism, reset counter fault detection mechanism and starting surface switching fault recovery logic are particularly emphasized, which effectively improves the security of system.The method solves the problem that CMAC check code cannot be dynamically updated in the prior art, while supporting clearing the corresponding hash value during firmware update, and realizing dynamic updating of trust chain.The application realizes the collaborative enhancement of functional safety and information security, and adapts to the ASIL-B and above grade functional safety requirements of vehicle-mounted MCU.

Description

Technical Field

[0001] This invention belongs to the field of chip security technology, specifically relating to a secure boot method for an MCU that integrates functional safety. Background Technology

[0002] During the secure boot process of a microcontroller unit (MCU), ensuring the information security and functional safety of the firmware program to be booted is crucial. Existing technologies primarily use shared-key-based message verification code algorithms (such as CMAC) to verify firmware integrity and source authentication. However, this approach has several significant problems: First, the generation, management, and deployment of the shared key require additional steps, increasing costs and security risks. Second, while the CMAC algorithm used in existing technologies can provide dual protection for integrity and source authentication, its computational overhead is high, and there is no clear mechanism for updating or dynamically managing the checksum, making integrity verification after firmware upgrades a challenge. Finally, existing technologies lack effective measures to address occasional hardware failures and software errors, failing to ensure the system can continue to operate securely after a failure. Summary of the Invention

[0003] The purpose of this invention is to provide a secure boot method for MCUs that integrates functional safety, which not only improves the security and reliability of the system boot process, but also pays special attention to the synergistic enhancement of functional safety and information security, providing a solid foundation for achieving higher levels of security standards, thereby solving the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: a secure boot method for an MCU integrating functional safety, comprising the following steps:

[0005] In a secure and trusted factory environment, a secure boot program and firmware program are programmed for the primary boot surface and redundant boot surface respectively, and the MCU is powered on and reset. After the MCU is reset, it starts from the reset address and executes the secure boot program of the active boot surface. The secure boot program enables the functional safety and information security protection measures of the MCU. The secure boot program checks and verifies the integrity of the first memory area storing the secure boot program in the active boot surface. The secure boot program checks and verifies the integrity of the second memory area storing the firmware program in the active boot surface. The secure boot program clears the reset counter, and then jumps to complete the firmware program startup.

[0006] Preferably, the primary boot surface and the redundant boot surface are used to logically divide the MCU's Flash memory into two storage areas with the same capacity and contiguous addresses, and the primary boot surface and the redundant boot surface are redundant backups of each other.

[0007] Preferably, the secure boot program is an unchanging program that runs in privileged mode and can read and write memory protection units, debug disable flag registers, and reset counters.

[0008] Preferably, the firmware program is used to implement the MCU business function logic and runs in user mode.

[0009] Preferably, the secure bootloader is used to prevent tampering with the boot surface by configuring a memory protection unit.

[0010] Preferably, the integrity of the first storage area storing the secure bootloader in the active boot plane is checked and verified by the secure bootloader, including:

[0011] The secure bootloader checks if a first hash value exists in the one-time programmable memory. If it does not exist, it calculates the first hash value and writes it into the one-time programmable memory to form a fixed root of trust. If it exists, it calculates the first hash value and compares it with the first hash value in the one-time programmable memory. If the comparison is inconsistent, it enters the secure boot failure recovery logic.

[0012] Preferably, the integrity of the second storage area storing the firmware in the active boot plane is checked and verified by the secure bootloader, including:

[0013] The secure bootloader checks whether a second hash value exists in the third storage area of ​​the active boot surface. If it does not exist, it calculates the second hash value and writes it into the third storage area of ​​the active boot surface, forming a trust chain with the root of trust. If it exists, it calculates the second hash value and compares it with the second hash value in the third storage area of ​​the active boot surface. If the comparison is inconsistent, it enters the secure boot failure recovery logic.

[0014] Preferably, the secure bootloader clears the reset counter and then jumps to and completes the firmware startup, including: the secure bootloader clears the reset counter; the secure bootloader jumps to the address of the next instruction to the first address of the second memory area of ​​the active boot surface to start the firmware startup.

[0015] Preferably, it further includes: after upgrading the firmware, clearing the corresponding second hash value, switching the boot plane, and software resetting the MCU, specifically including: after upgrading the firmware, clearing the corresponding second hash value, switching the boot plane, and software resetting the MCU, including:

[0016] After the active bootside firmware program overwrites the legitimate firmware program to be upgraded into the second storage area of ​​the inactive bootside, the active bootside firmware program enters privileged mode through a system call to erase the second hash value in the third storage area of ​​the inactive bootside, modifies the reset address to the starting address of the inactive bootside, and then software resets the MCU to update the trust chain.

[0017] Technical effects and advantages of the present invention: The MCU secure boot method integrating functional safety proposed in this invention has the following advantages compared with the prior art:

[0018] This invention ensures the security and reliability of the boot process by burning and verifying the security boot program and firmware of the main and redundant boot surfaces in a factory environment. It particularly emphasizes memory protection and privilege / user mode protection mechanisms, reset counter fault detection mechanisms, and boot surface switching fault recovery logic, effectively improving system security. This method solves the problem of the inability to dynamically update the CMAC checksum in existing technologies, and also supports clearing the corresponding hash value during firmware updates, enabling dynamic updates of the trust chain. Furthermore, using a hash algorithm instead of the MAC algorithm reduces computational overhead, allowing this solution to be applied to low-end and mid-range MCUs, reducing costs and shortening boot time. Overall, this invention achieves synergistic enhancement of functional safety and information security, meeting the functional safety requirements of automotive MCUs at AS1L-B and above. Attached Figure Description

[0019] Figure 1 This is a flowchart of the MCU secure boot method integrating functional safety as described in this invention;

[0020] Figure 2 This is a diagram illustrating the Flash storage area partitioning and data distribution structure of the present invention;

[0021] Figure 3 This is a schematic diagram of the memory protection unit configuration scheme after MCU reset according to the present invention;

[0022] Figure 4 This is a structural diagram of the internal OTP memory area of ​​the MCU of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The specific embodiments described herein are merely used to explain the present invention and are not intended to limit 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.

[0024] Please see Figure 1 and Figure 2To gain a deeper understanding of the Flash storage area partitioning and data distribution structure shown in the embodiments of this invention, this invention specifically relates to a secure boot method for an MCU with integrated functional safety, the steps of which include:

[0025] S1: Under a safe and reliable factory environment, the security bootloader and firmware are programmed onto the main boot surface and redundant boot surface respectively, and the MCU is then powered on and reset. The specific steps are as follows: In the safe environment of the factory production line, firstly, the security bootloader is programmed into the first storage area of ​​the main boot surface and redundant boot surface; then, the firmware is programmed into the second storage area of ​​these two boot surfaces; next, an erase operation is performed on the third storage area of ​​the main boot surface and redundant boot surface; finally, the MCU is powered on and reset.

[0026] The secure bootloader is a piece of code that is permanently stored and will not be updated in the future; it runs in privileged mode and can read and write memory protection units, manipulate debug disable flag registers, and reset counters.

[0027] The memory protection unit is an essential module for all microcontrollers (MCUs) that meet the functional safety level ASIL-B or higher. It supports setting access rules for memory areas within a specific address range to prevent unauthorized access or accidental tampering of data within that area.

[0028] The debug disable flag register is a register in the MCU that can be used to disable JTAG / SWD debugging functionality.

[0029] The reset counter is a register in the MCU that has a power-on clear feature, meaning that the value of the register will be automatically cleared to zero when the MCU is powered on, while the MCU will not be cleared by software reset.

[0030] Firmware is a program that implements the business logic of the MCU. It runs in user mode and cannot access the memory protection unit, debug disable flag register, and reset counter. It can consist of one or more program modules, such as a bootloader and an application program. In this embodiment, the firmware includes two program modules: a bootloader and an application program. The bootloader is used to configure the basic operating environment, and the application program is used to implement business functions, including the security upgrade process.

[0031] The primary boot plane and the redundant boot plane logically divide the MCU's Flash memory into two memory regions of equal capacity and contiguous addresses, with the two boot planes serving as redundant backups for each other. In this embodiment, the Flash memory is divided into two memory regions, each with a capacity of 256kB. The address range of the primary boot plane is [0x00000000, 0x0003FFFF], and the address range of the redundant boot plane is [0x00040000, 0x0007FFFF].

[0032] The first storage area, the second storage area, and the third storage area are storage regions that are further logically divided in the main boot surface and the redundant boot surface, respectively. The first storage area is located at the beginning of its respective boot surface, that is, the starting address of the first storage area is the same as the starting address of its respective boot surface. In this embodiment, the size of the first storage area is set to 16kB, and its address range in the primary boot plane and the redundant boot plane is [0x00000000, 0x00003FFF] and [0x00040000, 0x00043FFF], respectively. The size of the second storage area is set to 239kB, and its address range in the primary boot plane and the redundant boot plane is [0x00004000, 0x0003FBFF] and [0x00044000, 0x0007FBFF], respectively. The size of the third storage area is set to 1kB, and its address range in the primary boot plane and the redundant boot plane is [0x0003FC00, 0x0003FFFF] and [0x0007FC00, 0x0007FFFF], respectively.

[0033] S2: After the MCU is reset, it starts from the reset address and executes the safe boot program on the active boot surface.

[0034] The reset address refers to the address of the first instruction executed by the microcontroller (MCU) after a reset operation. In this embodiment, there are two options for the reset address: either the starting address of the primary boot surface (0x00000000) or the starting address of the redundant boot surface (0x00040000). Normally, the default reset address for the MCU during factory settings is the starting address of the primary boot surface.

[0035] The active boot surface refers to the boot surface that is currently running, that is, the boot surface pointed to by the reset address.

[0036] Please refer to the appendix of this invention specification. Figure 3 To understand the memory protection unit configuration scheme after MCU reset shown in the embodiments of the present invention.

[0037] S3: The secure bootloader enables functional safety and information security protection measures for the MCU to prevent unauthorized access or accidental tampering to the primary boot surface and redundant boot surfaces. Specifically, the secure bootloader configures a memory protection unit to prohibit user-mode access to the first memory area of ​​the primary and redundant boot surfaces, and prohibits privileged mode erase / write operations (reserved read operations). It also prohibits user-mode erase / write operations (reserved read operations) to the second and third memory areas of the primary and redundant boot surfaces, while allowing privileged mode access, thus preventing accidental tampering of the boot surface. Furthermore, the secure bootloader disables the JTAG / SWD debugging function by writing to the debug disable flag register, preventing external debugging tools from connecting to the MCU and preventing human tampering of the boot surface.

[0038] Please refer to the appendix of this invention specification. Figure 4 To understand the structure of the internal OTP memory area of ​​the MCU shown in the embodiments of the present invention.

[0039] S4: The secure bootloader checks and verifies the integrity of the first storage area storing the secure bootloader in the active boot plane. Specifically, this includes: the secure bootloader checks whether a first hash value exists in the OTP; if it does not exist, it calculates the first hash value and writes it into the OTP to form a solidified root of trust; if it exists, it calculates the first hash value and compares it with the first hash value in the OTP; if the comparison is inconsistent, it enters the secure boot failure recovery logic.

[0040] The first hash value is calculated using the SHA-256 hash algorithm over the entire area of ​​the first storage region of the active startup surface.

[0041] The safe boot failure recovery logic includes: incrementing the reset counter by 1, then checking if the reset counter value exceeds the failure count threshold. If it does, the reset address is changed to the starting address of the inactive boot surface, the reset counter is cleared, and the MCU is software reset. If it does not exceed the threshold, the MCU is directly software reset. The failure count threshold is an integer defined based on a comprehensive consideration of actual conditions and requirements such as security, fault recovery timeliness, and MCU computing performance. In this embodiment, the failure count threshold is set to 3, meaning that after a maximum of 3 consecutive safe boot failures on the current boot surface, it will switch to another boot surface for a boot attempt. An inactive boot surface is relative to an active boot surface.

[0042] S5: The secure bootloader checks and verifies the integrity of the second storage area storing the firmware program in the active boot plane. Specifically, this includes: the secure bootloader checks whether a second hash value exists in the third storage area of ​​the active boot plane; if it does not exist, it calculates the second hash value and writes it into the third storage area of ​​the active boot plane, forming a trust chain with the root of trust; if it exists, it calculates the second hash value and compares it with the second hash value in the third storage area of ​​the active boot plane; if the comparison is inconsistent, it enters the secure boot failure recovery logic.

[0043] The second hash value is calculated using the SHA-256 hash algorithm over the entire area of ​​the second storage region of the active startup surface.

[0044] S6: After clearing the reset counter, the secure bootloader jumps to and completes the firmware startup. Specifically, the secure bootloader clears the reset counter; the secure bootloader jumps to the address of the next instruction to the first address of the second memory area of ​​the active boot plane to start the firmware startup.

[0045] S7: Optionally, after upgrading the firmware, the corresponding second hash value is cleared, the boot face is switched, and the MCU is software reset. Specifically, after the active boot face firmware overwrites the legitimate firmware to be upgraded into the second storage area of ​​the inactive boot face, the active boot face firmware enters privileged mode through a system call to erase the second hash value in the third storage area of ​​the inactive boot face, modifies the reset address to the starting address of the inactive boot face, and then software resets the MCU to update the trust chain.

[0046] Legitimate firmware refers to firmware that has undergone a security upgrade process that checks and verifies its integrity and legitimacy of origin.

[0047] The security upgrade process is a function of the firmware program, which realizes the reception, unpacking and necessary security verification of the firmware upgrade package. It is a well-known technology in this field and will not be described in detail here.

[0048] In summary, this invention embeds a secure bootloader into Flash memory and supports direct execution at runtime (XIP), thereby circumventing the limitations of limited storage capacity of traditional One-Time Programming (OTP) and the inability to execute fuse-type OTP. It also supports clearing the corresponding hash value during firmware updates, resolving the deficiency of "CMAC value cannot be dynamically updated" in existing technologies. Furthermore, it clarifies that a power-on reset is triggered in a secure and trusted factory environment to generate a root of trust, and stores this root of trust via OTP, avoiding the source authentication problem caused by the lack of clearly defined security conditions for the root of trust generation environment in existing technologies.

[0049] By using dual startup surfaces as backups for each other and introducing a reset counter to support switching startup surfaces after multiple consecutive failures, the functional safety design requirements of "fault detection-retry-degradation" are met, and the functional safety requirements of ASIL-B and above for automotive microcontrollers (MCUs) are adapted.

[0050] After the secure bootloader starts, it immediately configures the memory protection unit and disables the JTAG / SWD debugging interface. By precisely defining the address range operation in privileged / user mode, it protects against and blocks debug writes, effectively preventing accidental and human tampering with the memory area, and provides higher security compared to existing technologies.

[0051] By designing a memory protection unit, a debug disable register, and a reset counter, the system not only defends against human tampering (such as JTAG / SWD flushing of the memory area), but also protects against occasional failures (such as accidental overwriting of the memory area, electromagnetic interference, etc.), thereby achieving synergistic enhancement of functional safety and information security.

[0052] While retaining the advantages of existing technologies in reducing key management and deployment costs and security risks, a hash algorithm is used to replace the Message Authentication Code (MAC) algorithm. No symmetric key is required, and data integrity can still be ensured. The computational overhead is reduced by 50% (based on actual test data of ARM Cortex-M7, compared with the AES operation of CMAC).

[0053] No hardware cryptographic module is required in the MCU to generate random keys, and there is no key access operation, which shortens the startup time compared to existing technologies. The MCU only needs to have a memory protection unit and standard peripherals such as OTP to implement it, which makes it applicable to low-end and mid-range MCUs, and reduces costs compared to existing technologies.

[0054] During firmware updates, the hash value of the third storage area of ​​the inactive boot surface is erased through privileged mode, realizing the process of "updating firmware first and then rebuilding the trust chain", which solves the problem that the firmware update method is not clearly defined in the existing technology.

[0055] The terms used in this embodiment are explained as follows:

[0056] Functional safety: By employing safety protection and redundant backup design, fault detection and recovery mechanisms, and other technical means, we can address occasional hardware failures and software errors, ensuring that the system can still operate safely after a failure or anomaly, thereby improving the system's reliability.

[0057] Secure Boot: A technology that ensures the trustworthiness and integrity of the code read and executed by a chip during the boot phase.

[0058] OTP: One-Time Programmable, a memory where each bit has only one chance to change from 1 to 0 and cannot be reversed from 0 to 1. It is used to store permanent, fixed data.

[0059] NVM: Non-Volatile Memory, which can retain data without power and includes types such as ROM, Flash, and OTP.

[0060] XIP: eXecutelnPlace, refers to the ability of program code stored in a certain NVM (Non-Machine Virtualization) to be directly fetched, decoded, and executed by the CPU without first loading the program code into memory. MCU (Microcontroller Unit) Flash memory typically supports XIP technology.

[0061] JTAG / SWD: JointTestActionGroup / SerialWireDebug are two commonly used embedded system debugging and programming interfaces, mainly used for MCU development and debugging, including direct flashing of NVM.

[0062] ASIL-B: Automotive Safety Integrity Level B, is a safety integrity level defined in the international standard ISO 26262 (Functional Safety of Road Vehicles) for automotive systems that "may cause serious injury." It requires risk control throughout the entire process, from system architecture and hardware design to software development. Its implementation relies on hardware isolation (such as memory protection units), access control (such as processor privileges / user mode), and strict development standards to ensure that the risk is reduced to an acceptable level in the event of system failure.

[0063] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A secure boot method for a functional safety MCU, characterized in that, Includes the following steps: In a secure and trusted factory environment, a secure bootloader and firmware are programmed for the primary boot surface and the redundant boot surface, respectively, and the MCU is powered on and reset. This process includes: in the secure environment of the factory production line, firstly, the secure bootloader is programmed to the first storage area of ​​the primary boot surface and the redundant boot surface; then, the firmware is programmed to the second storage area of ​​these two boot surfaces; subsequently, an erase operation is performed on the third storage area of ​​the primary boot surface and the redundant boot surface; finally, a power-on reset is performed on the MCU. After the MCU is reset, it starts from the reset address and executes the security boot program on the active boot side. The security boot program will enable the MCU's functional safety and information security protection measures. The secure bootloader checks and verifies the integrity of the first storage area storing the secure bootloader in the active boot plane, including: the secure bootloader checks whether a first hash value exists in the one-time programmable memory; if it does not exist, it calculates the first hash value and writes it into the one-time programmable memory to form a solidified root of trust; if it exists, it calculates the first hash value and compares it with the first hash value in the one-time programmable memory; if the comparison is inconsistent, it enters the secure boot failure recovery logic. The secure bootloader checks and verifies the integrity of the second storage area storing the firmware program in the active boot plane, including: the secure bootloader checks whether a second hash value exists in the third storage area of ​​the active boot plane; if it does not exist, it calculates the second hash value and writes it into the third storage area of ​​the active boot plane to form a trust chain with the root of trust; if it exists, it calculates the second hash value and compares it with the second hash value in the third storage area of ​​the active boot plane; if the comparison is inconsistent, it enters the secure boot failure recovery logic. The security bootloader clears the reset counter, then jumps and completes the firmware startup. After upgrading the firmware, the corresponding second hash value is cleared, the boot plane is switched, and the MCU is software reset. After upgrading the firmware, the corresponding second hash value is cleared, the boot plane is switched, and the MCU is software reset, including: After the active bootside firmware program overwrites the legitimate firmware program to be upgraded into the second storage area of ​​the inactive bootside, the active bootside firmware program enters privileged mode through a system call to erase the second hash value in the third storage area of ​​the inactive bootside, modifies the reset address to the starting address of the inactive bootside, and then software resets the MCU to update the trust chain.

2. The method of claim 1, wherein the method further comprises: The primary boot surface and the redundant boot surface are used to logically divide the MCU's Flash memory into two storage areas with the same capacity and contiguous addresses, and the primary boot surface and the redundant boot surface are redundant backups of each other.

3. The method of claim 1, wherein the method further comprises: The secure bootloader is an unchanging program that runs in privileged mode and has read / write access to the memory protection unit, debug disable flag register, and reset counter.

4. The method of claim 1, wherein the method further comprises: The firmware program is used to implement the MCU business function logic and runs in user mode.

5. The method of claim 1, wherein the method further comprises: The secure bootloader is used to prevent tampering with the boot surface by configuring a memory protection unit.

6. The method of claim 1, wherein the method further comprises: The secure bootloader clears the reset counter, then jumps to and completes the firmware startup process, including: the secure bootloader clears the reset counter; the secure bootloader jumps to the address of the next instruction to the first address of the second memory area of ​​the active boot plane to start the firmware startup.

Images