Security starting method, device and equipment applied to micro control unit and medium

Abstract

Embodiments of the present application provide a secure starting method, device and equipment applied to a micro control unit and a medium. The method comprises: in response to a power-on operation of the micro control unit, starting initial starting code in a first kernel and a second kernel running in the micro control unit respectively; calling an encryption algorithm and an encryption public key stored in a hardware security module through the initial starting code started in the first kernel to perform verification processing on each starting related information provided by the hardware security module to obtain a module verification result; if the module verification result indicates that each starting related information provided by the hardware security module is accurate, generating module successful running information; after the initial starting code started in the second kernel detects the module successful running information, performing pre-starting verification on an application program required to be run by the second kernel based on the hardware security module, and starting the application program in the micro control unit after the verification passes. The development cycle can be shortened and the hardware cost can be reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a secure startup method, apparatus, device, and medium for a microcontroller unit. Background Art

[0002] Currently, secure booting of the Microcontroller Unit (MCU) can be used to verify the integrity and accuracy of key user-defined programs and content in the memory, thereby preventing application tampering and the resulting operational risks.

[0003] In the prior art, secure booting of an MCU can be performed based on a hardware security module (HSM).

[0004] However, traditional HSM design is primarily based on hardware development. This implementation method fixes the HSM's secure boot method and process, resulting in a lack of flexibility in HSM-based secure boot. Furthermore, this hardware-based approach leads to long HSM development cycles, high resource investment, and high hardware costs. Summary of the Invention

[0005] The embodiments of the present application provide a secure boot method, apparatus, device, and medium for a microcontroller unit, so as to shorten the development cycle and reduce hardware costs.

[0006] In a first aspect, an embodiment of the present application provides a secure boot method applied to a microcontroller unit, comprising:

[0007] In response to a power-on operation of the microcontroller unit, initial startup codes are respectively started in a first core and a second core running in the microcontroller unit; wherein the first core is used to run a hardware security module; and the second core is used to run an application program;

[0008] Invoking, by the initial startup code started in the first kernel, an encryption algorithm and an encryption public key stored in the hardware security module, and performing verification processing on various startup-related information provided by the hardware security module to obtain a module verification result; wherein the module verification result is used to indicate whether the various startup-related information provided by the hardware security module is accurate;

[0009] If the module verification result indicates that the startup-related information provided by the hardware security module is accurate, module successful operation information is generated; wherein the module successful operation information indicates that the hardware security module has been successfully operated;

[0010] After the initial startup code started in the second core detects the successful operation information of the module, it performs a pre-startup check on the application required to be run by the second core based on the hardware security module, and starts the application in the micro control unit after the check passes.

[0011] In one possible implementation, the initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module, verifies various startup-related information provided by the hardware security module, and obtains a module verification result, including:

[0012] Calling, through the initial startup code started in the first kernel, the encryption algorithm and the encryption public key stored in the hardware security module from the read-only memory of the hardware security module;

[0013] Based on the encryption algorithm and encryption public key stored in the hardware security module, encrypt the startup related information provided by the hardware security module to obtain an information encryption result;

[0014] The information encryption result is compared with a preset encryption result stored in the non-read-only memory of the hardware security module to obtain the module verification result.

[0015] In one possible implementation, the method further includes: calling, by the initial startup code started in the first kernel, the encryption algorithm and encryption public key stored in the hardware security module, and before verifying various startup-related information provided by the hardware security module:

[0016] Reading a lifecycle register in the hardware security module through the initial startup code started in the first kernel;

[0017] Determining an enable state of the hardware security module based on a value of the lifecycle register; wherein the enable state indicates whether the hardware security module is enabled;

[0018] If it is determined based on the enable state that the hardware security module is enabled, initialization processing is performed on the hardware security module.

[0019] In a possible implementation, if it is determined based on the enable state that the hardware security module is enabled, initializing the hardware security module includes:

[0020] The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module, performs encryption calculation on various startup-related information provided by the hardware security module, obtains a preset encryption result, and saves the preset encryption result to the non-read-only memory of the hardware security module.

[0021] In one possible implementation, the method further includes:

[0022] If it is determined that the hardware security module is not enabled, the application program in the micro control unit is directly started.

[0023] In one possible implementation, the startup-related information includes at least: public key list information, address mapping table information, and code mirror information; wherein the public key list information includes public key information required for pre-startup verification of an application program required to be run by the second kernel; the address mapping table information includes address information required for pre-startup verification of an application program required to be run by the second kernel; and the code mirror information indicates a mirror file of code required for pre-startup verification of an application program required to be run by the second kernel.

[0024] In one possible implementation, the method further includes:

[0025] If the initial startup code started in the second kernel does not detect the module successful operation information, the initial startup code started in the second kernel is controlled to be in a dormant state.

[0026] In a second aspect, an embodiment of the present application provides a secure booting device for a microcontroller unit, comprising:

[0027] a startup module, configured to, in response to a power-on operation of the microcontroller unit, start initial startup codes in a first core and a second core respectively running in the microcontroller unit; wherein the first core is configured to run the hardware security module; and the second core is configured to run the application program;

[0028] a first verification module, configured to call, through the initial startup code started in the first kernel, the encryption algorithm and encryption public key stored in the hardware security module, and perform verification processing on various startup-related information provided by the hardware security module to obtain a module verification result; wherein the module verification result is used to indicate whether the various startup-related information provided by the hardware security module is accurate;

[0029] a generating module, configured to generate module successful operation information if the module verification result indicates that the startup-related information provided by the hardware security module is accurate; wherein the module successful operation information indicates that the hardware security module has successfully operated;

[0030] The second verification module is used to perform a pre-startup verification on the application required to be run by the second kernel based on the hardware security module after the initial startup code started in the second kernel detects the successful operation information of the module, and start the application in the micro control unit after the verification passes.

[0031] In a possible implementation, the first verification module is configured to:

[0032] Calling, through the initial startup code started in the first kernel, the encryption algorithm and the encryption public key stored in the hardware security module from the read-only memory of the hardware security module;

[0033] Based on the encryption algorithm and encryption public key stored in the hardware security module, encrypt the startup related information provided by the hardware security module to obtain an information encryption result;

[0034] The information encryption result is compared with a preset encryption result stored in the non-read-only memory of the hardware security module to obtain the module verification result.

[0035] In a possible implementation, the device further includes an initialization module, configured to:

[0036] The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module, and reads the life cycle register in the hardware security module through the initial startup code started in the first kernel before verifying various startup related information provided by the hardware security module;

[0037] Determining an enable state of the hardware security module based on a value of the lifecycle register; wherein the enable state indicates whether the hardware security module is enabled;

[0038] If it is determined based on the enable state that the hardware security module is enabled, initialization processing is performed on the hardware security module.

[0039] In a possible implementation, the initialization module is configured to:

[0040] The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module, performs encryption calculation on various startup-related information provided by the hardware security module, obtains a preset encryption result, and saves the preset encryption result to the non-read-only memory of the hardware security module.

[0041] In one possible embodiment, the device is further used for:

[0042] If it is determined that the hardware security module is not enabled, the application program in the micro control unit is directly started.

[0043] In one possible implementation, the startup-related information includes at least: public key list information, address mapping table information, and code mirror information; wherein the public key list information includes public key information required for pre-startup verification of an application program required to be run by the second kernel; the address mapping table information includes address information required for pre-startup verification of an application program required to be run by the second kernel; and the code mirror information indicates a mirror file of code required for pre-startup verification of an application program required to be run by the second kernel.

[0044] In a possible implementation, the second verification module is further configured to:

[0045] If the initial startup code started in the second kernel does not detect the module successful operation information, the initial startup code started in the second kernel is controlled to be in a dormant state.

[0046] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory, a processor;

[0047] The memory stores computer-executable instructions;

[0048] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0049] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementation methods of the first aspect.

[0050] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0051] The secure boot method, apparatus, device, and medium for a microcontroller unit provided in an embodiment of the present application can, in response to a power-on operation of the microcontroller unit, start initial boot code in the first core and the second core running in the microcontroller unit, respectively, to prepare for the startup of the microcontroller unit. Then, the initial boot code started in the first core calls the encryption algorithm and encryption public key stored in the hardware security module to verify the various boot-related information provided by the hardware security module. At this time, the accuracy of the hardware security module for secure boot can be ensured by verifying the various boot-related information stored in the memory of the hardware security module, thereby helping to ensure the effectiveness of the secure boot. Afterwards, if it is determined that the various boot-related information provided by the hardware security module is accurate, module successful operation information can be generated. At this time, after the initial boot code started in the second core detects the module successful operation information, it performs a pre-boot verification on the application required to run in the second core based on the hardware security module, and after the verification passes, the application in the microcontroller unit is started. In this implementation, since the hardware security module is implemented as software, it not only saves costs, shortens the development cycle, and improves the development efficiency of the hardware security module, but also allows the customization of the verification content of the application before startup, thereby improving the flexibility and diversity of secure startup. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0053] Figure 1 A schematic diagram of a secure startup process for a microcontroller unit according to an embodiment of the present application;

[0054] Figure 2 A schematic diagram of another process flow for secure startup of a microcontroller unit provided in an embodiment of the present application;

[0055] Figure 3 A schematic diagram of the memory layout of an HSM provided in an embodiment of the present application;

[0056] Figure 4 A flowchart of a secure boot method for a microcontroller unit according to an embodiment of the present application;

[0057] Figure 5 A schematic structural diagram of a secure startup device applied to a microcontroller unit provided in an embodiment of the present application;

[0058] Figure 6 A schematic structural diagram of another secure startup device applied to a microcontroller unit provided in an embodiment of the present application;

[0059] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0060] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0061] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present application.

[0062] First, the terms involved in this application are explained.

[0063] BootRom: The full name is Boot Read-Only Memory, which is a read-only memory, usually used to store the initial startup code of a computer or embedded system.

[0064] AES: The full name is Advanced Encryption Standard, which is a symmetric encryption algorithm.

[0065] ROM: Read-Only Memory, read-only memory.

[0066] RAM: Random Access Memory.

[0067] FLASH: A non-volatile memory.

[0068] MAC: Message Authentication Code, a value generated by a symmetric encryption algorithm and a key to verify the integrity and authenticity of a message.

[0069] HMAC: Hash-based Message Authentication Code, a MAC value generated based on a hash function and a key.

[0070] Digital signature: Information generated using an asymmetric encryption algorithm and a key to verify the integrity of a message and the identity of the sender.

[0071] BootLoader: boot loader.

[0072] MCU secure boot is designed to verify the integrity and accuracy of user-defined key programs and content in the memory, thereby preventing the application from being tampered with and posing operational risks.

[0073] In existing technology, secure booting of MCUs can be performed using HSMs. However, traditional HSM designs are primarily based on hardware development. For example, various encryption algorithms can be implemented in hardware to achieve secure booting of the MCU. However, this implementation method and process are fixed for the HSM, resulting in a lack of flexibility in secure booting based on HSMs. Furthermore, this hardware-based approach leads to long HSM development cycles, high resource investment, and high hardware costs.

[0074] The secure boot method for a microcontroller unit provided in this application implements HSM through software, and then implements secure boot of the MCU based on HSM to solve the above technical problems.

[0075] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0076] Figure 1 A schematic diagram of a secure startup process for a microcontroller unit is provided in an embodiment of the present application. Figure 1 As shown, the method includes:

[0077] S101 , in response to a power-on operation of a micro control unit, initial startup codes are respectively started in a first core and a second core running in the micro control unit.

[0078] The first core is used to run the hardware security module; the second core is used to run the application program.

[0079] In one example, a microcontroller unit can be applied to an embedded system. In this case, after detecting that the embedded system is powered on, it can be determined that the power-on operation of the microcontroller unit is detected. Thereafter, in response to the power-on operation of the microcontroller unit, the initial startup code can be started in each core included in the microcontroller unit (for example, including a first core and a second core).

[0080] In the embodiment of the present application, the number of second cores running in the MCU can be one or more, and this is not limited here.

[0081] In one example, the initial startup code can be understood as a code stored in the BootRom of the MCU for initial startup of the system.

[0082] S102: The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module, verifies various startup related information provided by the hardware security module, and obtains a module verification result.

[0083] The module verification result is used to indicate whether the startup-related information provided by the hardware security module is accurate.

[0084] In one example, the encryption algorithm stored in the HSM may be a symmetric encryption algorithm or an asymmetric encryption algorithm, which is not limited here. For example, the encryption algorithm stored in the HSM may be an AES algorithm (e.g., AES128).

[0085] In one example, the encryption public key can be understood as public key information generated when the MCU establishes a connection with the kernel. The specific content of the encryption public key is not limited here.

[0086] In one example, before starting the MCU, the encryption algorithm and encryption public key can be stored in the ROM of the HSM. At this time, the encryption algorithm and encryption public key in the HSM can be prevented from being tampered with through the ROM, thereby ensuring the accuracy of the verification processing based on the encryption algorithm and encryption public key.

[0087] In one example, the startup-related information provided by the HSM is used to indicate the verification-related information required by each application running in the MCU. For example, the startup-related information may include at least: public key list information, address mapping table information, and code image files, etc. At this time, the startup-related information may indicate the public key information that all verification modules for secure startup rely on (that is, the public key information required for the application running on the second core of the MCU to perform pre-startup verification), the address information required for secure startup (that is, the address information required for the application running on the second core of the MCU to perform pre-startup verification), and other algorithms / codes involved in the secure startup process (wherein, the code can be used to implement the various functional modules required in the verification process, such as a security log module, a public key information management module, etc., or the code indicates other algorithms, such as a hash algorithm, etc.) and the corresponding image files.

[0088] S103: If the module verification result indicates that the startup-related information provided by the hardware security module is accurate, then module successful operation information is generated.

[0089] The module successful operation information indicates that the hardware security module has successfully operated.

[0090] In one example, after the module successful operation information is generated, the module successful operation information may be saved in a preset register, or the module successful operation information may be sent to the second core.

[0091] S104: After the initial startup code started in the second core detects the successful module operation information, it performs a pre-startup check on the application program to be run by the second core based on the hardware security module, and starts the application program in the micro control unit after the check passes.

[0092] For example, the boot loader loaded in the application program to be run by the second kernel may be verified by the HSM to ensure that the boot loader has not been tampered with.

[0093] In addition, the HSM can also be used to verify information such as images and data that the application program required to run on the second core depends on, and after the verification is passed, the application program in the MCU can be started.

[0094] As can be seen from the above description, in response to the power-on operation of the microcontroller, the embodiment of the present application can respectively start the initial startup code in the first core and the second core running in the microcontroller to prepare for the startup of the microcontroller. Then, the initial startup code started in the first core calls the encryption algorithm and encryption public key stored in the hardware security module to verify the various startup-related information provided by the hardware security module. At this time, the accuracy of the hardware security module performing the secure startup can be ensured by verifying the various startup-related information stored in the memory of the hardware security module, thereby helping to ensure the effectiveness of the secure startup. Afterwards, if it is determined that the various startup-related information provided by the hardware security module is accurate, a module success run message can be generated. At this time, after the initial startup code started in the second core detects the module success run message, it performs a pre-startup check on the application program to be run by the second core based on the hardware security module, and after the check passes, the application program in the microcontroller is started. In this embodiment, since the hardware security module is implemented in software, it not only saves costs, shortens the development cycle, and improves the development efficiency of the hardware security module, but also allows the customization of the verification content of the application program before startup, thereby enhancing the flexibility and diversity of the secure startup.

[0095] Figure 2 Another flow chart of secure startup of a microcontroller unit provided in an embodiment of the present application is as follows: Figure 2 As shown, the method includes:

[0096] S201 : In response to a power-on operation of a micro control unit, initial startup codes are respectively started in a first core and a second core running in the micro control unit.

[0097] The first core is configured to run the hardware security module, and the second core is configured to run the application program.

[0098] S202, reading a lifecycle register in the hardware security module through initial start code started in the first core.

[0099] In one example, the lifecycle register can indicate a lifecycle register, and at this time, the lifecycle phase of the MCU security start can be determined according to the values of the register bits in the lifecycle register.

[0100] S203, determining an enable state of the hardware security module based on the values of the lifecycle register.

[0101] The enable state indicates whether the hardware security module is enabled, for example, the enable state can indicate that the HSM is enabled, or that the HSM is not enabled.

[0102] The enable state indicates that the HSM can execute corresponding security functions and strategies, and the not enable state indicates that the HSM does not execute corresponding security functions and strategies.

[0103] S204, if it is determined that the hardware security module is not enabled, directly starting the application program in the micro control unit.

[0104] At this time, in the case where it is determined that the HSM is not enabled, the HSM is not started, and therefore the application program in the micro control unit can be directly started, thereby accelerating the start speed of the application program.

[0105] S205, if it is determined that the hardware security module is enabled based on the enable state, initializing the hardware security module.

[0106] At this time, the enable state of the HSM can be quickly determined through the values of the lifecycle register, that is, whether the HSM is started for security start can be quickly determined, thereby enabling the security start based on the HSM as needed, and improving the performance of the embedded system / device in which the micro control unit is located.

[0107] In one example, when it is determined that the hardware security module is enabled and the hardware security module is initialized, the initial start code started in the first core can be used to call the encryption algorithm and the encryption public key stored in the hardware security module from the read-only memory of the hardware security module, to perform encryption calculation on the start-related information provided by the hardware security module, to obtain a preset encryption result, and to save the preset encryption result to the non-readonly memory of the hardware security module. The non-readonly memory can be RAM or FLASH, and the type of the non-readonly memory is not limited here, and the actual needs shall prevail.

[0108] At this time, during the HSM initialization process, the preset encryption results corresponding to the various startup-related information in the HSM can be determined based on the encryption algorithm and encryption public key stored in the HSM's read-only memory, so as to verify the accuracy of the various startup-related information used when performing secure startup based on the HSM based on the preset encryption results.

[0109] In one example, the preset encryption result may indicate a MAC value, digital signature, etc. calculated according to an encryption algorithm, or an HMAC value generated using a hash function and an encrypted public key, etc. The type of the preset encryption result is not limited here.

[0110] In one example, after determining that the HSM initialization is complete, a secure boot can be performed based on the HSM. In specific implementation, the following steps can be performed.

[0111] S206 : Calling the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module through the initial startup code started in the first kernel.

[0112] S207 : Based on the encryption algorithm and encryption public key stored in the hardware security module, encrypt the startup related information provided by the hardware security module to obtain an information encryption result.

[0113] S208: Compare the information encryption result with the preset encryption result stored in the non-read-only memory of the hardware security module to obtain a module verification result.

[0114] The module verification result is used to indicate whether the startup-related information provided by the hardware security module is accurate.

[0115] In one example, if the information encryption result is the same as the preset encryption result, the obtained module verification result indicates that the startup-related information provided by the hardware security module is accurate. At this time, the steps described in S209 below can be continued.

[0116] If the information encryption result is different from the preset encryption result, the module verification result obtained indicates that the startup-related information provided by the hardware security module is inaccurate. At this time, you can stop starting the application in the micro control unit or enter the safe mode. The specific execution content of the safe mode is not limited here, and it is subject to implementation.

[0117] S209: If the module verification result indicates that the startup-related information provided by the hardware security module is accurate, then module successful operation information is generated.

[0118] The module successful operation information indicates that the hardware security module has successfully operated.

[0119] S210, after the initial boot code started in the second kernel detects the module successful running information, the application program required to be run by the second kernel is pre-boot verified based on the hardware security module, and after the verification passes, the application program in the micro control unit is started.

[0120] S211, if the initial boot code started in the second kernel does not detect the module successful running information, the initial boot code started in the second kernel is controlled to be in a dormant state.

[0121] This embodiment can ensure that the application program required to be run by the second kernel is pre-boot verified after confirming that the HSM is accurate, thereby ensuring the accuracy of the verification and the effectiveness of the secure start.

[0122] In one example, since the HSM is implemented by software, a corresponding memory space needs to be set in the HSM to store the software-implemented code and data.

[0123] In one example, the HSM can be allocated with a corresponding memory as needed, for example, a 74KB memory can be configured in the HSM, or a 100KB memory can also be configured, etc. At this time, the memory space corresponding to the HSM can be arranged according to the functions of the HSM implementation.

[0124] Referring to Figure 3 , Figure 3 A memory arrangement diagram of the HSM provided by the embodiment of the present application is shown in Figure 3 The HSM memory can include two types of memories, one is a read-only memory, and the other is a non-read-only memory (for example, a random access memory shown in Figure 3 According to the contents required to be stored in the HSM memory, a corresponding memory size is allocated, for example, in the case of configuring a 74KB memory for the HSM, the memory of the HSM can be configured as follows.

[0125] In one example, the encryption algorithm and the encryption public key determined in the process of establishing the trust chain of the HSM can be stored in the read-only memory, thereby ensuring that this part of the content cannot be changed. At this time, the encryption algorithm and the encryption public key can be configured with a corresponding memory space according to the type of the encryption algorithm, for example, if the encryption algorithm is a 128-bit encryption algorithm, the encryption public key can be allocated with a 128-bit memory space, and the encryption algorithm can be allocated with a 10KB memory space.

[0126] At the same time, the random access memory portion of the HSM can also be divided into three sub-parts for storing different types of startup related information and preset encryption results corresponding to each startup related information. For example, the first sub-part can be used to store public key list information and the public key list information (such as Figure 3 As shown, the preset encryption result corresponding to 1KB of memory space) (such as Figure 3 As shown, corresponding to 128-bit memory space); the second sub-part can be used to store address mapping table information (such as Figure 3 As shown, corresponding to 1KB of memory space), and the preset encryption result corresponding to the address mapping table information (such as Figure 3 As shown, corresponding to 128-bit memory space); the third sub-part can be used to store code image information (such as Figure 3 As shown, corresponding to 61KB of memory space), and the preset encryption result corresponding to the code image information (such as Figure 3 As shown, it corresponds to 128 bits of memory space).

[0127] At this time, the preset encryption key stored in the first sub-part is used to verify the public key list information, the preset encryption key stored in the second sub-part is used to verify the address mapping table information, and the preset encryption key stored in the third sub-part is used to verify the code mirror information.

[0128] In one example, Figure 4 This is a flowchart of a secure boot method for a microcontroller unit provided in an embodiment of the present application. Figure 4 As shown, after the microcontroller is powered on, the initial startup code can be started in the first core and the second core running in the microcontroller, respectively. The first core is used to run the hardware security module, and the second core is used to run the application program.

[0129] At this time, if it is determined that the hardware security module is being started for the first time, the initial startup code of the first kernel can first read the life cycle register in the hardware security module and determine whether the hardware security module is enabled based on the value of the life cycle register. If it is not enabled, the hardware security module is disabled. At this time, the micro-control unit is not verified based on the hardware security module, and the application in the micro-control unit is directly started.

[0130] If the hardware security module is determined to be enabled, the hardware security module is first initialized. Specifically, the preset encryption result corresponding to the public key list information stored in the hardware security module is calculated and stored in the corresponding memory space. Next, the preset encryption result corresponding to the address mapping table information stored in the hardware security module is calculated and stored in the corresponding memory space. Finally, the preset encryption result corresponding to the code image information stored in the hardware security module is calculated and stored in the corresponding memory space.

[0131] Afterwards, the hardware security module can be run and verified according to the preset encryption result. If the module verification result indicates that the startup related information provided by the hardware security module is accurate, module successful operation information is generated.

[0132] If it is determined that the hardware security module is not started for the first time, the encryption algorithm and encryption public key stored in the hardware security module can be directly called to verify the startup-related information provided by the hardware security module. If the module verification result indicates that the startup-related information provided by the hardware security module is accurate (that is, the verification passes), module successful operation information is generated.

[0133] At this point, after the initial boot code launched in the second core detects the successful module operation information, it can use the hardware security module to perform pre-launch verification of the application program that the second core needs to run. For example, it can first verify the bootloader loaded in the second core and start the bootloader after the verification passes. Then, it can verify the image and data in the second core and start the application program in the microcontroller unit after the verification passes.

[0134] In the embodiment of the present application, the MCU secure boot speed / verification processing speed can be improved by increasing the CPU main frequency or increasing the number of second cores.

[0135] Figure 5 This is a schematic diagram of a secure startup device for a microcontroller unit according to an embodiment of the present application. Figure 5 As shown, the secure booting device 500 applied to a micro control unit provided in this embodiment includes:

[0136] The startup module 501 is used to start the initial startup code in the first core and the second core running in the microcontroller in response to the power-on operation of the microcontroller; wherein the first core is used to run the hardware security module; the second core is used to run the application program.

[0137] The first verification module 502 is used to call the encryption algorithm and encryption public key stored in the hardware security module through the initial startup code started in the first kernel, verify the startup-related information provided by the hardware security module, and obtain a module verification result; wherein the module verification result is used to indicate whether the startup-related information provided by the hardware security module is accurate.

[0138] The generating module 503 is configured to generate module successful operation information if the module verification result indicates that the startup related information provided by the hardware security module is accurate; wherein the module successful operation information indicates that the hardware security module has successfully operated.

[0139] The second verification module 504 is used to perform a pre-startup verification on the application required to be run by the second kernel based on the hardware security module after the initial startup code started in the second kernel detects the successful operation information of the module, and start the application in the micro control unit after the verification passes.

[0140] Figure 6 This is a structural diagram of another secure startup device applied to a microcontroller unit provided in an embodiment of the present application. Figure 6 As shown, the secure booting device 600 applied to a micro control unit provided in this embodiment includes:

[0141] The startup module 601 is used to start the initial startup code in the first core and the second core running in the microcontroller in response to the power-on operation of the microcontroller; wherein the first core is used to run the hardware security module; the second core is used to run the application program.

[0142] The first verification module 602 is used to call the encryption algorithm and encryption public key stored in the hardware security module through the initial startup code started in the first kernel, verify the startup-related information provided by the hardware security module, and obtain a module verification result; wherein the module verification result is used to indicate whether the startup-related information provided by the hardware security module is accurate.

[0143] The generating module 603 is configured to generate module successful operation information if the module verification result indicates that the startup related information provided by the hardware security module is accurate; wherein the module successful operation information indicates that the hardware security module has successfully operated.

[0144] The second verification module 604 is used to perform a pre-startup verification on the application required to be run by the second kernel based on the hardware security module after the initial startup code started in the second kernel detects the successful operation information of the module, and start the application in the micro control unit after the verification passes.

[0145] In a possible implementation, the first verification module 602 is configured to:

[0146] Calling the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module through the initial startup code started in the first kernel;

[0147] Based on the encryption algorithm and encryption public key stored in the hardware security module, encryption calculation is performed on each startup related information provided by the hardware security module to obtain an information encryption result;

[0148] The information encryption result is compared with the preset encryption result stored in the non-read-only memory of the hardware security module to obtain the module verification result.

[0149] In a possible implementation, the apparatus further includes an initialization module 605, configured to:

[0150] The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module, and reads the life cycle register in the hardware security module through the initial startup code started in the first kernel before verifying various startup related information provided by the hardware security module;

[0151] Determine the enable state of the hardware security module based on the value of the life cycle register; wherein the enable state indicates whether the hardware security module is enabled;

[0152] If it is determined based on the enable state that the hardware security module is enabled, the hardware security module is initialized.

[0153] In a possible implementation, the initialization module 605 is configured to:

[0154] The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module, performs encryption calculation on various startup-related information provided by the hardware security module, obtains a preset encryption result, and saves the preset encryption result to the non-read-only memory of the hardware security module.

[0155] In one possible embodiment, the device is further used for:

[0156] If it is determined that the hardware security module is not enabled, the application program in the micro control unit is directly started.

[0157] In one possible implementation, each startup-related information includes at least: public key list information, address mapping table information, and code mirror information; wherein the public key list information includes public key information required for pre-startup verification of an application program required to be run by the second kernel; the address mapping table information includes address information required for pre-startup verification of an application program required to be run by the second kernel; and the code mirror information indicates a mirror file of code required for pre-startup verification of an application program required to be run by the second kernel.

[0158] In a possible implementation, the second verification module 604 is further configured to:

[0159] If the initial startup code started in the second core does not detect the module successful operation information, the initial startup code started in the second core is controlled to be in a dormant state.

[0160] The secure boot device applied to a micro control unit provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar, and are not described in detail in this embodiment.

[0161] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 7 As shown, the electronic device 700 provided in this embodiment includes: at least one processor 701 and a memory 702. Optionally, the electronic device 700 further includes a communication component 703. The processor 701, the memory 702 and the communication component 703 are connected via a bus 704.

[0162] During the specific implementation process, at least one processor 701 executes the computer-executable instructions stored in the memory 702, so that the at least one processor 701 performs the above method.

[0163] The specific implementation process of the processor 701 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0164] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly implemented by a hardware processor or implemented by a combination of hardware and software modules in the processor.

[0165] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk memory.

[0166] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified into address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0167] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0168] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0169] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0170] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0171] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0172] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0173] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0174] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling an electronic device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0175] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0176] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A secure boot method for a microcontroller unit, characterized in that: The method comprises: In response to a power-on operation of the microcontroller unit, initial startup codes are respectively started in a first core and a second core running in the microcontroller unit; wherein the first core is used to run a hardware security module; and the second core is used to run an application program; The initial startup code started in the first kernel is used to call the encryption algorithm and encryption public key stored in the hardware security module, and verify the startup related information provided by the hardware security module to obtain a module verification result; wherein the module verification result is used to indicate whether the startup related information provided by the hardware security module is accurate; the startup related information includes at least: public key list information, address mapping table information and code mirror information; wherein the public key list information includes public key information required for pre-startup verification of an application to be run by the second kernel; the address mapping table information includes address information required for pre-startup verification of an application to be run by the second kernel; the code mirror information indicates the image file of the code required for pre-startup verification of the application to be run by the second kernel; If the module verification result indicates that the startup-related information provided by the hardware security module is accurate, module successful operation information is generated; wherein the module successful operation information indicates that the hardware security module has been successfully operated; After the initial startup code started in the second core detects the successful operation information of the module, it performs a pre-startup check on the application required to be run by the second core based on the hardware security module, and starts the application in the micro control unit after the check passes.

2. The method according to claim 1, characterized in that The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module, verifies the startup related information provided by the hardware security module, and obtains a module verification result, including: calling, through the initial startup code started in the first kernel, from the read-only memory of the hardware security module, the encryption algorithm and the encryption public key stored in the hardware security module; Based on the encryption algorithm and encryption public key stored in the hardware security module, encrypt the startup related information provided by the hardware security module to obtain an information encryption result; The information encryption result is compared with a preset encryption result stored in the non-read-only memory of the hardware security module to obtain the module verification result.

3. The method according to claim 1, characterized in that The method further includes, before verifying various startup-related information provided by the hardware security module, calling the encryption algorithm and encryption public key stored in the hardware security module through the initial startup code started in the first kernel: Reading a lifecycle register in the hardware security module through the initial startup code started in the first kernel; Determining an enable state of the hardware security module based on a value of the lifecycle register; wherein the enable state indicates whether the hardware security module is enabled; If it is determined based on the enable state that the hardware security module is enabled, initialization processing is performed on the hardware security module.

4. The method according to claim 3, characterized in that If it is determined based on the enabled state that the hardware security module is enabled, initializing the hardware security module includes: The initial startup code started in the first kernel calls the encryption algorithm and encryption public key stored in the hardware security module from the read-only memory of the hardware security module, performs encryption calculation on various startup-related information provided by the hardware security module, obtains a preset encryption result, and saves the preset encryption result to the non-read-only memory of the hardware security module.

5. The method according to claim 3, characterized in that The method further comprises: If it is determined that the hardware security module is not enabled, the application program in the micro control unit is directly started.

6. The method according to any one of claims 1 to 3, characterized in that The method further comprises: If the initial startup code started in the second kernel does not detect the module successful operation information, the initial startup code started in the second kernel is controlled to be in a dormant state.

7. A safe starting device applied to a micro control unit, characterized in that: include: a startup module, configured to, in response to a power-on operation of the microcontroller unit, start initial startup codes in a first core and a second core respectively running in the microcontroller unit; wherein the first core is configured to run the hardware security module; and the second core is configured to run the application program; a first verification module, configured to call the encryption algorithm and encryption public key stored in the hardware security module through the initial startup code started in the first kernel, verify the startup related information provided by the hardware security module, and obtain a module verification result; wherein the module verification result is used to indicate whether the startup related information provided by the hardware security module is accurate; the startup related information includes at least: public key list information, address mapping table information, and code mirror information; wherein the public key list information includes public key information required for pre-startup verification of an application to be run by the second kernel; the address mapping table information includes address information required for pre-startup verification of an application to be run by the second kernel; and the code mirror information indicates a mirror file of code required for pre-startup verification of an application to be run by the second kernel; a generating module, configured to generate module successful operation information if the module verification result indicates that the startup-related information provided by the hardware security module is accurate; wherein the module successful operation information indicates that the hardware security module has successfully operated; The second verification module is used to perform a pre-startup verification on the application required to be run by the second kernel based on the hardware security module after the initial startup code started in the second kernel detects the successful operation information of the module, and start the application in the micro control unit after the verification passes.

8. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the secure boot method applied to a micro control unit according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the secure startup method applied to a microcontroller unit according to any one of claims 1 to 6.

Images