Method and system for secure boot of an embedded terminal

Abstract

This application provides a secure boot method and system for embedded terminals. The method includes: upon detecting that the embedded terminal has completed hardware initialization after power-on, acquiring the hardware configuration information of the embedded terminal, and determining the hardware encryption mode of the embedded terminal based on the hardware configuration information. The hardware encryption modes include an external SE chip mode, a built-in SEC accelerator mode, and a software-implemented encryption / decryption mode. Based on the hardware encryption mode, acquiring the TCR public key of the embedded terminal and verifying its validity. If the TCR public key is valid, performing firmware integrity verification on the embedded terminal based on the hardware encryption mode, obtaining the verification result, and controlling the embedded terminal to boot if the verification result indicates that the firmware integrity verification of the embedded terminal has passed. This solves the problem of poor adaptability in existing secure boot schemes.

Description

Technical Field

[0001] This application relates to the field of secure boot technology for embedded terminals, and more specifically, to a secure boot method and secure boot system for embedded terminals. Background Technology

[0002] With the rapid development of the Internet of Things, industrial control, and smart terminals, embedded terminals, as core control components, directly determine the trustworthiness of the entire terminal device and its upper-layer system. Typical cases include industrial control terminals being injected with malicious firmware, leading to production line paralysis; vehicle-mounted microcontrollers having their boot programs tampered with, causing security incidents; and smart home terminal keys being leaked, resulting in the theft of user privacy. These incidents cause direct economic losses.

[0003] To address the aforementioned threats, existing solution one focuses on the secure boot requirements of RISC-V architecture terminals. It constructs a multi-level secure boot mechanism based on the national cryptographic SM9 algorithm by adding a signature computation unit (SCU), a key verification unit (KVU), and an internal ROM module to a general-purpose RISC-V SoC. However, it has significant limitations in adaptability, being designed only for the RISC-V architecture and incompatible with other mainstream embedded terminal hardware platforms such as ARM and MCU. Furthermore, it requires additional dedicated hardware modules, leading to increased terminal hardware costs and making it unsuitable for low-cost, miniaturized IoT terminal scenarios. Existing solution two focuses on the binding implementation of hardware encryption chips and terminals. Its advantage lies in its strong security under a single encryption mode, but it lacks cross-mode adaptability. Once the terminal hardware configuration changes, adaptation code needs to be redeveloped, making it inflexible and incompatible.

[0004] In summary, existing secure boot solutions suffer from poor compatibility. Summary of the Invention

[0005] The main objective of this application is to provide a secure boot method and secure boot system for embedded terminals, so as to at least solve the problem of poor adaptability of existing secure boot schemes.

[0006] To achieve the above objectives, according to one aspect of this application, a secure boot method for an embedded terminal is provided, comprising: upon detecting that the embedded terminal has completed hardware initialization after power-on, acquiring hardware configuration information of the embedded terminal, and determining a hardware encryption mode of the embedded terminal based on the hardware configuration information, wherein the hardware encryption mode includes an external SE chip mode, a built-in SEC accelerator mode, and a software-implemented encryption / decryption mode; acquiring a TCR public key of the embedded terminal based on the hardware encryption mode, and verifying the legality of the TCR public key; if the TCR public key is legal, performing firmware integrity verification on the embedded terminal based on the hardware encryption mode, obtaining a verification result, and controlling the embedded terminal to boot if the verification result indicates that the firmware integrity verification of the embedded terminal has passed.

[0007] Optionally, performing firmware integrity verification on the embedded terminal according to the hardware encryption mode includes: when the hardware encryption mode is the external SE chip mode, obtaining an encryption scheme corresponding to the external SE chip mode from an encryption algorithm library, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm types, and key lengths; inputting the encryption scheme into the external SE chip, decrypting the firmware of the embedded terminal based on the external SE chip to obtain decrypted firmware, and performing firmware integrity verification on the decrypted firmware.

[0008] Optionally, performing firmware integrity verification on the embedded terminal according to the hardware encryption mode includes: when the hardware encryption mode is the built-in SEC accelerator mode, obtaining an encryption scheme corresponding to the built-in SEC accelerator mode from the encryption algorithm library, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm types, and key lengths; inputting the encryption scheme into the built-in SEC accelerator, decrypting the firmware of the embedded terminal based on the built-in SEC accelerator to obtain decrypted firmware, and performing firmware integrity verification on the decrypted firmware.

[0009] Optionally, performing firmware integrity verification on the embedded terminal according to the hardware encryption mode includes: when the hardware encryption mode is the software implementation encryption / decryption mode, obtaining an encryption scheme corresponding to the software implementation encryption / decryption mode from an encryption algorithm library, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm types, and key lengths; and using a software algorithm to decrypt the firmware of the embedded terminal according to the encryption scheme to obtain decrypted firmware.

[0010] Optionally, obtaining the hardware configuration information of the embedded terminal and determining the hardware encryption mode of the embedded terminal based on the hardware configuration information includes: reading the hardware configuration information of the embedded terminal stored in a preset storage location in Flash, wherein the hardware configuration information is a single-byte parameter; and determining the hardware encryption mode of the embedded terminal based on the single-byte parameter.

[0011] Optionally, the method further includes: upon detecting the first power-on initialization of the embedded terminal, obtaining a random algorithm generated by the user based on custom software, generating a random address for the TCR in on-chip one-time programmable non-volatile memory according to the random algorithm, and writing the TCR public key to the random address.

[0012] Optionally, in the process of writing the TCR public key to the random address, the method further includes: processing the TCR public key using a hash algorithm to obtain a check value corresponding to the TCR public key, and writing the check value to the random address.

[0013] Optionally, after performing firmware integrity verification on the embedded terminal according to the hardware encryption mode and obtaining the verification result, the method further includes: if the verification result indicates that the firmware integrity verification of the embedded terminal has failed, terminating the startup of the embedded terminal and outputting error information.

[0014] According to another aspect of this application, a secure boot system is provided, the secure boot system being used to execute any of the secure boot methods for the embedded terminal described above, the secure boot system comprising: a hardware adaptation layer for detecting the hardware encryption mode of the embedded terminal; a trusted computing base core layer for verifying the legality of the TCR public key according to the hardware encryption mode; and a security function layer for performing firmware integrity verification on the embedded terminal.

[0015] Optionally, the secure boot system further includes an interface layer, which is used to support upper-layer applications or developers in configuring, controlling, and monitoring the status of the secure boot system.

[0016] By applying the technical solution of this application, after the embedded terminal completes hardware initialization upon power-on, it automatically acquires its hardware configuration information and dynamically identifies the hardware encryption mode currently used by the device based on this information, including external SE chip mode, built-in SEC accelerator mode, or software-implemented encryption and decryption mode, thereby achieving adaptive adaptation to terminals with different hardware architectures. Subsequently, based on the identified encryption mode, the TCR public key is extracted from the corresponding secure storage area and its legitimacy is verified to ensure the trustworthiness of the authentication root trust chain. After the public key verification is successful, a matching verification algorithm and execution path are selected in combination with the current hardware encryption mode to perform integrity verification on the firmware. Only when the verification result shows that the firmware has not been tampered with is the terminal allowed to continue booting. This series of linkage mechanisms based on dynamic hardware configuration decisions effectively overcomes the limitations of traditional secure boot processes, which cannot be deployed across platforms due to fixed hardware architectures. It achieves intelligent adaptation and unified security management for diverse embedded terminal hardware environments, thus solving the technical problems of poor cross-platform compatibility, high deployment costs, and insufficient security protection capabilities caused by significant differences in hardware configurations and rigid secure boot processes in existing technologies. This improves the versatility, robustness, and scalability of secure boot for embedded systems, thereby addressing the issue of poor adaptability in existing secure boot solutions. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a mobile terminal for executing a secure boot method for an embedded terminal, according to an embodiment of this application, is shown.

[0019] Figure 2 A flowchart illustrating a secure boot method for an embedded terminal according to an embodiment of this application is shown.

[0020] Figure 3 A structural diagram of a specific secure boot system provided according to an embodiment of this application is shown;

[0021] Figure 4 A flowchart illustrating a secure boot method for a specific embedded terminal provided according to an embodiment of this application is shown.

[0022] Figure 5 A structural block diagram of a secure boot device for an embedded terminal provided according to an embodiment of this application is shown. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] As described in the background section, existing secure boot solutions have poor adaptability. To address this issue, embodiments of this application provide a secure boot method and system for embedded terminals.

[0027] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0028] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for an embedded terminal secure boot method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0029] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the secure boot method for the embedded terminal in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0030] This embodiment provides a secure boot method for an embedded terminal running on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Figure 2 This is a flowchart of a secure boot method for an embedded terminal according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0032] Step S201: When the embedded terminal is detected to have completed hardware initialization, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0033] Specifically, after the embedded terminal powers on and completes hardware initialization, the system reads the hardware configuration information pre-stored within the terminal to identify the encryption hardware architecture type currently used by the terminal, thereby determining whether it belongs to an external SE chip mode, a built-in SEC accelerator mode, or a software-implemented encryption / decryption mode. This process does not rely on external intervention or manual configuration; it only determines the mode based on the configuration data stored within the terminal itself, ensuring that the startup process can automatically adapt to the actual hardware capabilities.

[0034] Step S202: According to the above hardware encryption mode, obtain the TCR public key of the above embedded terminal and verify the legality of the above TCR public key;

[0035] Specifically, based on the hardware encryption mode, the TCR public key of the embedded terminal is obtained, and its legitimacy is verified. This process relies on the identification result of the hardware encryption mode to determine from which storage or processing path the Trusted Root of Computing (TCR) public key is read; the acquisition operation directly targets this specific data object, the TCR public key; and the verification of the public key's legitimacy is achieved by comparing it with preset integrity or authenticity standards to confirm that the obtained public key has not been tampered with or forged, ensuring its trustworthiness as the starting point for initiating the trust chain.

[0036] Step S203: If the TCR public key is valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain the verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

[0037] Specifically, once the legitimacy of the Trusted Computing Root (TCR) public key is verified, the system performs a firmware integrity verification operation based on the hardware encryption mode currently recognized by the embedded terminal. This operation directly relies on the confirmed legitimate public key and the encryption hardware capabilities configured in the terminal to verify the consistency of the firmware content. If the verification result shows that the firmware has not been tampered with and meets the preset integrity standard, the system determines that the verification has passed and triggers the startup control logic of the embedded terminal, enabling the terminal to enter normal operation.

[0038] In this embodiment, by applying the above steps S201, S202, and S203, after the embedded terminal completes hardware initialization upon power-on, its hardware configuration information is automatically acquired, and the hardware encryption mode currently used by the device is dynamically identified based on this information. This includes external SE chip mode, built-in SEC accelerator mode, or software-implemented encryption / decryption mode, thereby achieving adaptive adaptation to terminals with different hardware architectures. Subsequently, based on the identified encryption mode, the TCR public key is extracted from the corresponding secure storage area and its legitimacy is verified to ensure the trustworthiness of the authentication root trust chain. After the public key verification is successful, a matching verification algorithm and execution path are selected in conjunction with the current hardware encryption mode to perform integrity verification on the firmware. Only when the verification result shows that the firmware has not been tampered with is the terminal allowed to continue booting. Through this series of linkage mechanisms based on dynamic hardware configuration decisions, the limitations of traditional secure boot processes that cannot be deployed across platforms due to the rigidity of hardware architecture are effectively overcome. This enables intelligent adaptation and unified security management of diverse embedded terminal hardware environments, thereby solving the technical problems of poor cross-platform compatibility, high deployment costs, and insufficient security protection capabilities caused by large differences in hardware configuration and rigid secure boot processes in existing technologies. This also solves the problem of poor adaptability of existing secure boot solutions.

[0039] In the specific implementation process, the firmware integrity verification of the embedded terminal is performed according to the aforementioned hardware encryption mode, including: when the aforementioned hardware encryption mode is the aforementioned external SE chip mode, obtaining the encryption scheme corresponding to the aforementioned external SE chip mode from the encryption algorithm library, wherein each of the aforementioned encryption schemes in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm types and key lengths; inputting the aforementioned encryption scheme into the external SE chip, decrypting the firmware of the embedded terminal based on the aforementioned external SE chip to obtain decrypted firmware, and performing the aforementioned firmware integrity verification on the decrypted firmware.

[0040] In this embodiment, when the embedded terminal's hardware encryption mode is detected to be external SE chip mode, the system will call an encryption scheme that strictly matches this mode from a pre-built encryption algorithm library. This encryption algorithm library contains preset configurations for the combination order, algorithm type, and key length of various encryption algorithms, such as "SM4-CBC-256 + SHA3-512 + The "ECDH key negotiation" sequence is designed to provide a flexible decryption and verification path for firmware with different security levels, rather than using a fixed algorithm. This encryption scheme is then securely injected into an external SE chip, a hardware security module independent of the main processor. This chip is tamper-proof and resistant to side-channel attacks, and can securely perform key derivation, decryption operations, and hash verification, ensuring that sensitive operations are not exposed in the main system memory. The decryption process performed by this chip decrypts the encrypted firmware block by block, generating the original decrypted firmware, and immediately performs integrity verification within the chip, such as comparing the hash value of the decrypted firmware with the pre-stored TCR public key signature, thus achieving an integrated security closed loop of "decryption equals verification." This process is triggered only when the external SE chip mode is confirmed, avoiding interference with the built-in SEC accelerator or software encryption mode. Through this collaborative mechanism of mode awareness and dynamic scheme loading, the system can accurately adapt to the encryption implementation methods of different hardware platforms, effectively solving the technical defect of firmware verification failure due to the undefined encryption scheme of the external SE chip. This enables highly reliable and adaptive verification of diverse encrypted firmware in cross-platform embedded terminals during the secure boot phase.

[0041] Specifically, the firmware integrity verification of the embedded terminal according to the aforementioned hardware encryption mode includes: when the aforementioned hardware encryption mode is the aforementioned built-in SEC accelerator mode, obtaining an encryption scheme corresponding to the aforementioned built-in SEC accelerator mode from the encryption algorithm library, wherein each of the aforementioned encryption schemes in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm types and key lengths; inputting the aforementioned encryption scheme into the built-in SEC accelerator, decrypting the firmware of the embedded terminal based on the aforementioned built-in SEC accelerator to obtain decrypted firmware, and performing the aforementioned firmware integrity verification on the decrypted firmware.

[0042] In this embodiment, after the embedded terminal powers on and completes hardware initialization, if its hardware encryption mode is detected to be the built-in SEC accelerator mode, an encryption scheme matching this mode is retrieved from the pre-configured encryption algorithm library. This encryption scheme is not a fixed single algorithm, but a configurable strategy composed of multiple encryption algorithms (such as AES-256, SM4, SHA-384, etc.) in a specific combination order, algorithm type, and key length (such as 256-bit key + CTR mode + HMAC check chain). It aims to adapt to different security level scenarios—for example, a high-strength combination of "SM4-CBC + SHA-512" is used in financial terminals, while a lightweight combination of "AES-128-ECB + CRC-32" is selected in industrial control equipment to balance performance and security. The encryption scheme is actively loaded and input into the built-in SEC accelerator hardware module, where its internal dedicated circuit directly parses the algorithm configuration parameters and performs decryption operations, rather than relying on general-purpose CPU software simulation. This ensures that the decryption process is efficient and resistant to side-channel attacks. After decryption, the system performs integrity verification on the obtained original firmware image (such as hash comparison or digital signature verification) to confirm that it has not been tampered with. Through this mechanism, the built-in SEC accelerator is no longer limited to the factory-fixed algorithm, but can flexibly switch encryption strategies based on the dynamic configuration in the encryption algorithm library. This enables adaptive secure boot for multiple scenarios, from high-security military-grade to low-power IoT-grade, without modifying the hardware design or reflashing the firmware driver. This significantly improves the system's scalability and deployment flexibility on heterogeneous hardware platforms.

[0043] More specifically, the firmware integrity verification of the embedded terminal according to the above hardware encryption mode includes: when the above hardware encryption mode is the above software implementation encryption and decryption mode, obtaining an encryption scheme corresponding to the above software implementation encryption and decryption mode from the encryption algorithm library, wherein each of the above encryption schemes in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm type and key length; and using a software algorithm to decrypt the firmware of the embedded terminal according to the above encryption scheme to obtain decrypted firmware.

[0044] In this embodiment, when the embedded terminal is detected to be using a software-implemented encryption / decryption mode, the system no longer relies on a fixed, single software encryption algorithm. Instead, it dynamically selects an encryption scheme that matches the current security requirements from a pre-built encryption algorithm library. This encryption scheme is a pre-configured multi-layered algorithm combination, including combinations such as AES-256 and SM4, concatenated RSA-4096 and ECC-256, or SHA-512 hash chains and ChaCha20 stream encryption concatenated in a specific order. Each combination explicitly specifies the algorithm type, execution order, and key length, thereby achieving precise adaptation to different security levels. Subsequently, the software algorithm is executed by a general-purpose CPU, and the firmware is decrypted layer by layer according to the selected scheme. For example, a lightweight combination (SM4+SHA256) can be enabled on low-performance MCUs, while a high-strength combination (AES-256+ECDSA+HKDF) can be called in high-security scenarios. This ensures that even without SE chips or SEC accelerators, a verifiable, auditable, and upgradeable software-level secure decryption path can still be flexibly constructed. By shifting the encryption strategy from hardware-bound to configuration-driven, the same embedded platform can dynamically improve security strength by updating the algorithm library without changing the hardware. This effectively solves the technical bottleneck of rigid decryption strategies and inability to cope with differentiated security needs in the software implementation mode, and significantly enhances the adaptive secure boot capability of embedded terminals in heterogeneous hardware environments.

[0045] Further, obtaining the hardware configuration information of the aforementioned embedded terminal and determining the hardware encryption mode of the aforementioned embedded terminal based on the aforementioned hardware configuration information includes: reading the hardware configuration information of the aforementioned embedded terminal stored in a preset storage location in Flash, wherein the aforementioned hardware configuration information is a single-byte parameter; and determining the aforementioned hardware encryption mode of the aforementioned embedded terminal based on the aforementioned single-byte parameter.

[0046] In this embodiment, reading a single-byte parameter stored at a preset location in the Flash memory of the embedded terminal means that after the terminal powers on and completes hardware initialization, the system no longer relies on complex configuration files or dynamic detection of hardware modules. Instead, it directly extracts an 8-bit identifier value from a fixed, predefined byte address in the Flash memory (e.g., 0x1000). This value uniquely corresponds to three hardware encryption modes through encoding—for example, 0x01 represents an external SE chip, 0x02 represents a built-in SEC accelerator, and 0x03 represents software encryption / decryption—thus achieving rapid identification of hardware capabilities with minimal overhead. Determining the hardware encryption mode based on this single-byte parameter means that the startup process does not require embedding any hardware detection logic or conditions. The system can directly map the corresponding public key acquisition path and verification algorithm based on the parameter value alone. For example, when the parameter is 0x01, the system automatically reads the TCR public key from the secure area of ​​the SE chip, while when the parameter is 0x03, it calls the software key verification module from the firmware signature area. This allows the system to adapt to different platform encryption architectures without modifying the underlying firmware code. Overall, by compressing the originally scattered and unstructured hardware configuration information into a standardized single-byte identifier and embedding it in a preset location in Flash, the system can automatically, accurately, and with low latency identify and adapt to various encryption hardware forms without modifying the bootloader. This significantly improves the compatibility and deployment efficiency of embedded terminals for secure booting across heterogeneous platforms.

[0047] Furthermore, the above method also includes: upon detecting the first power-on initialization of the embedded terminal, obtaining a random algorithm generated by the user based on custom software, generating a random address for the TCR in the on-chip one-time programmable non-volatile memory according to the random algorithm, and writing the TCR public key to the random address.

[0048] In this embodiment, upon detecting the first power-on initialization of the embedded terminal, the system triggers a user-defined random algorithm injection process. This algorithm, input by the user through a dedicated configuration tool or secure interactive interface, is essentially an unpredictable numerical sequence generated based on nonlinear chaotic functions, hash perturbation, or key derivation mechanisms. For example, after the user inputs a unique password, it is expanded into a 256-bit random seed using the PBKDF2 algorithm, ensuring that the address distribution generated each time possesses statistical randomness and collision resistance. Subsequently, the system dynamically calculates the physical storage address of the TCR public key in the on-chip one-time programmable nonvolatile memory (OTP) based on this random algorithm. This address is not a preset fixed offset (e.g., 0x1000), but a unique and unrepeatable random value (e.g., 0x5F3A or 0xB91C) each time it is first powered on, thereby completely breaking the predictability of the public key address. Next, the TCR public key is directly written to this random address, instead of being uniformly written to a fixed security area as in traditional schemes. This makes it impossible for attackers to locate the public key by reverse enumerating common addresses even if they obtain the OTP content through physical probes or side-channel analysis. In the subsequent power-on process, the system automatically locates this random address to read the public key based on the hardware encryption mode, completing the legitimacy verification and firmware verification. The entire process is completely transparent to the upper-layer boot logic and does not change the original adaptive mode. By introducing a user-driven randomized storage mechanism in the initial power-on phase, the physical storage location of the TCR public key has a dynamic attribute of one-time pad, fundamentally blocking the path for attackers to locate the root of trust public key through reverse engineering, firmware dumping, or chip analysis. This significantly improves the anti-persistent attack capability of embedded terminals for secure boot under multiple hardware platforms, achieving "no fixed trace" protection for the root of trust.

[0049] Specifically, in the process of writing the TCR public key to the random address, the method further includes: processing the TCR public key using a hash algorithm to obtain the verification value corresponding to the TCR public key, and writing the verification value to the random address.

[0050] In this embodiment, during the process of writing the TCR public key to a random address, a hash algorithm is used to process the TCR public key, obtaining its unique checksum, which is then written to the same random address. The hash algorithm refers to a one-way encryption function such as SHA-256, which can convert a TCR public key of arbitrary length into a fixed-length, irreversible, and unique digital digest. This checksum can be considered the "digital fingerprint" of the public key; even if only one bit of the public key is tampered with, its hash value will change significantly. This step is performed during the initial power-on initialization. The random address is generated by user-defined software to ensure that the public key of each device is stored correctly. The storage locations are all different, thus avoiding the risk of fixed addresses being maliciously scanned or subjected to mass attacks. During the subsequent startup process, the system reads the TCR public key and checksum from the random address, recalculates the hash value of the public key and compares it with the stored checksum value. If they do not match, the system immediately determines that the public key has been tampered with and rejects the subsequent startup process. By generating and binding the checksum value during the writing stage, real-time protection of the integrity of the public key storage is achieved. This effectively solves the problem that the public key trustworthiness is invalidated due to the vulnerability of non-volatile storage to physical tampering or firmware injection attacks, and significantly improves the security and reliability of embedded terminals in various hardware environments.

[0051] More specifically, after performing firmware integrity verification on the embedded terminal according to the above hardware encryption mode and obtaining the verification result, the above method further includes: if the above verification result indicates that the firmware integrity verification of the embedded terminal has failed, terminating the startup of the embedded terminal and outputting error information.

[0052] In this embodiment, after verifying the firmware integrity of the embedded terminal according to the hardware encryption mode and obtaining the verification result, if the verification result indicates that the firmware integrity has failed, it means that the firmware loaded by the terminal has failed the digital signature verification or hash comparison performed based on the hardware encryption mode (such as an external SE chip, a built-in SEC accelerator, or software-implemented encryption and decryption), and may contain tampered, malicious code, or unauthorized firmware. At this time, the system will immediately terminate the boot process, block the execution of subsequent boot programs, and prevent illegal code from running in the kernel or application layer; at the same time, the system will actively output error information, such as through flashing LED indicators, serial... The system prints logs or sends error codes through the debug interface, clearly indicating to maintenance personnel or users that the startup failure is due to firmware integrity issues rather than power or hardware malfunctions, thus providing a visual alarm for security risks. This mechanism, together with the previous steps of dynamically adapting encryption modes based on hardware configuration and verifying the legitimacy of the TCR public key, forms a complete closed loop. This ensures that on any hardware platform, once the firmware trust chain is broken, the system immediately enters a protective shutdown state and provides traceable fault feedback. This fundamentally eliminates the risk of malicious firmware lurking and running due to unresponsive verification failures, significantly improving the security and trustworthiness of embedded terminals in complex deployment environments.

[0053] This embodiment relates to a secure boot system, which is used to execute any of the above-described secure boot methods for embedded terminals. The secure boot system includes:

[0054] The hardware adaptation layer is used to detect the hardware encryption mode of the embedded terminal.

[0055] The core layer of the Trusted Computing Base is used to verify the legitimacy of the TCR public key according to the above hardware encryption mode;

[0056] The security function layer is used to perform firmware integrity verification on the aforementioned embedded terminal.

[0057] The secure boot system provided in this embodiment automatically identifies the encryption hardware configuration of the embedded terminal through a hardware adaptation layer, achieving indiscriminate detection and abstraction of three modes: external SE chip, built-in SEC accelerator, and software-implemented encryption / decryption. This avoids the reliance on customized development for different hardware platforms. The trusted computing base core layer calls the corresponding trusted root verification process based on the detection results, ensuring that the public key validity verification matches the hardware capabilities, thus improving the adaptability and reliability of the authentication process. The security function layer selects the corresponding firmware decryption and integrity verification path according to the hardware mode, achieving precise coordination between encryption algorithm execution and underlying hardware capabilities. This allows for a unified secure boot process under multiple hardware architectures without modifying the core system logic, effectively reducing system deployment costs and enhancing the security compatibility and maintainability of embedded terminals in heterogeneous hardware environments.

[0058] In addition, the aforementioned secure boot system also includes an interface layer, which is used to support upper-layer applications or developers in configuring, controlling, and monitoring the status of the secure boot system.

[0059] In this embodiment, the interface layer is an independent functional module designed specifically to enable external interaction capabilities of the secure boot system. It establishes a two-way channel with upper-layer applications or developers through standardized communication protocols, supports dynamic configuration of boot strategies (such as selecting verification algorithms and setting timeout thresholds), real-time control of the boot process (such as forced interruption, restart, or skipping verification), and comprehensive monitoring of system status (such as returning TCR public key verification results, firmware hash comparison logs, hardware encryption mode identification status, etc.).

[0060] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the secure startup method for embedded terminals of this application will be described in detail below with reference to specific embodiments.

[0061] This embodiment relates to a specific secure boot system. This system is based on a layered architecture and modular design, including a hardware adaptation layer, a trusted computing core layer, a security function layer, and an interface layer, which together construct a complete secure boot system. The overall architecture of the specific secure boot system is as follows: Figure 3 As shown.

[0062] The hardware adaptation layer is responsible for interacting with embedded terminal hardware and peripheral devices. It includes SE driver, electronic fuse (EFUSE) module driver with one-time programmable read-only storage function, encryption and decryption accelerator driver, general IO interface adaptation and other modules, realizes unified abstraction of different hardware configurations and provides standardized hardware operation interface for the upper layer.

[0063] The TCB management layer (Trusted Computing Base core layer) includes modules such as TCR management, hardware configuration detection, and startup process scheduling. It is responsible for the secure storage and retrieval of the root of trust, adaptive scheduling of the startup process, and verification of the trusted state.

[0064] The security function layer implements core security functions, including a nested encryption algorithm library, firmware encryption / decryption module, integrity verification module, etc., and is responsible for the management and combination of encryption algorithms, firmware encryption processing, and verification of firmware integrity and legality during the boot process.

[0065] The interface layer provides standardized interfaces to the outside world, including hardware environment configuration interfaces, encryption and decryption algorithm configuration interfaces, status query interfaces, etc., which support upper-layer applications or developers to configure, control and monitor the status of the system.

[0066] Based on the above architecture, the overall system startup process can be summarized as follows: after the embedded terminal is powered on, the hardware adaptation layer automatically detects the hardware encryption configuration, the trusted computing core layer schedules the corresponding secure startup process according to the detection results, and the security function layer calls the specified nested encryption algorithm to decrypt and verify the integrity of the firmware. If the verification is successful, the trusted startup is completed; if the verification fails, the startup is terminated and an alarm is triggered.

[0067] This system provides a mode-adaptive secure boot technology, which is the core of the trusted computing base layer. This technology is responsible for the automatic detection of embedded terminal hardware encryption configurations, the adaptive scheduling of the secure boot process, and the trusted verification of the boot process, ensuring secure booting under different hardware configurations. Based on these requirements, this technology relies on four functional modules: a hardware configuration detection module, a boot process scheduling module, a firmware encryption / decryption module, and an integrity verification module.

[0068] The hardware configuration detection module reads a single-byte parameter (0 represents an external SE, 1 represents a built-in encryption / decryption accelerator, and 2 represents software-implemented encryption / decryption) from the Flash storage location of the embedded terminal to detect the current encrypted hardware configuration of the embedded terminal. After identifying one of the three modes, the detection result is fed back to the startup process scheduling submodule.

[0069] The startup process scheduling module has three preset safe startup process templates and schedules the corresponding startup process based on the hardware configuration detection results:

[0070] 1) External SE mode: The startup process relies on SE, and operations such as encryption calculation and key storage are delegated to SE. During startup, TCR is verified through SE, firmware is decrypted and integrity is verified.

[0071] 2) Built-in SEC accelerator mode: The startup process utilizes the embedded terminal's built-in SEC accelerator to improve encryption / decryption efficiency. The TCR is stored in EFUSE, and the firmware is decrypted and verified through the SEC accelerator during startup.

[0072] 3) Software-implemented encryption / decryption mode: When there is no hardware encryption module, encryption and decryption operations are implemented through a software algorithm library. The TCR is stored in EFUSE. At startup, the firmware is decrypted and verified through a software algorithm, balancing security and compatibility.

[0073] The firmware encryption / decryption module and integrity verification module are key nodes in the boot process. They perform checks on hardware status, firmware integrity, and TCR validity. If the verification fails, the boot process is terminated immediately, and an alarm signal is output through a designated pin to prevent malicious boot.

[0074] Based on the above functional modules, this embodiment relates to a specific secure boot method for an embedded terminal, such as... Figure 4 As shown, the process includes the following:

[0075] 1) The embedded terminal is powered on and initialized. The hardware configuration detection module starts and reads the embedded terminal hardware configuration information in the Flash.

[0076] 2) Identify the hardware encryption mode and send the mode information to the startup process scheduling module;

[0077] 3) The startup process scheduling module loads the startup template for the corresponding mode and initializes the relevant hardware and algorithms;

[0078] 4) Obtain the public key by calling the TCR management module and verify the legitimacy of the TCR;

[0079] 5) Call the firmware encryption / decryption module and integrity verification module in the security function layer to complete firmware decryption and integrity verification;

[0080] 6) If the verification passes, the firmware will be loaded and the startup will be completed; if the verification fails, the startup will be terminated and an alarm will be triggered.

[0081] This system also provides configurable nested encryption technology, which is the working mechanism of the firmware encryption / decryption module in the security function layer. It offers unified management of the SM2 / SM3 / SM4 national cryptographic algorithms and AES, supporting flexible nested combinations of encryption algorithms. The order and types of algorithm combinations can be specified according to security requirements to achieve high-strength encryption and decryption of the firmware, ensuring firmware confidentiality and integrity. Therefore, this technology relies on the encryption algorithm library and serves the integrity verification module. For the nested combination configuration function, this technology provides an encryption combination configuration interface, allowing developers or upper-layer applications to specify the combination order, algorithm types, and key length of encryption algorithms through configuration files. For example, it can be configured as any nested combination such as "SM4 encryption → AES encryption → SM3 hash verification" or "SM2 encryption → SM4 encryption → SM3 hash verification".

[0082] This technology employs a configuration-driven implementation, integrating the algorithm library as a lib library. Nested combination rules are stored in a configuration table, allowing for adjustments to the encryption strategy without modifying the core code. The encryption strategy is implemented by generating a firmware header from a configuration file, while decryption involves parsing the firmware header to obtain the corresponding algorithm type and its order, thus enabling algorithm nesting. Based on this strategy, algorithm combinations can be quickly switched to adapt to specific scenario requirements. During encryption, the output of each algorithm layer serves as the input for the next layer, ultimately generating the encrypted firmware and a verification value. The decryption process is executed in reverse order to ensure accurate firmware restoration.

[0083] This system also provides public key random storage technology, a core security mechanism for TCR management. This technology is responsible for the random storage, secure retrieval, and legitimacy verification of public keys, solving the problem that traditional fixed storage is easily located and stolen, allowing attackers to attack all terminals with the same hardware at once after obtaining the location. This ensures the security and availability of the root of trust, providing a trusted foundation for the entire secure boot process. The core of this technology is the random generation of the storage location. During the initial power-on initialization of the embedded terminal, to ensure the uniqueness of a manufacturer's hardware random algorithm, users can customize a software-implemented random algorithm to generate a random storage address in EFUSE. This address must avoid critical configuration areas and already occupied areas to ensure the uniqueness and security of the storage location. After the random address is generated, it is updated to the uniquely matching secure boot firmware, and a public key can be written to this address. During writing, the public key is first hashed using SM3 to generate a checksum, and then the public key and checksum are written together to the randomly generated address. During reading, the public key and checksum are retrieved from the storage address, and the legitimacy of the public key is verified using the SM3 hash algorithm to ensure that the public key has not been tampered with. At the same time, based on the processor's memory access control function, access to EFUSE should be subject to full-domain access control, and unauthorized modules should be prohibited from accessing it.

[0084] The system employs three key technologies: adaptive secure boot technology, configurable nested encryption technology, and public key random storage technology. These technologies enable a two-level boot process that can be decomposed to adapt to scenarios with insufficient ROM space.

[0085] This application also provides a secure boot device for an embedded terminal. It should be noted that the secure boot device for an embedded terminal in this application can be used to execute the secure boot method for an embedded terminal provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0086] The following describes the secure boot device for an embedded terminal provided in the embodiments of this application.

[0087] Figure 5 This is a schematic diagram of a secure boot device for an embedded terminal according to an embodiment of this application. Figure 5 As shown, the device includes:

[0088] The acquisition unit 51 is used to acquire the hardware configuration information of the embedded terminal when the embedded terminal is detected to have completed hardware initialization, and to determine the hardware encryption mode of the embedded terminal based on the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0089] Verification unit 52 is used to obtain the TCR public key of the embedded terminal according to the above hardware encryption mode, and verify the legality of the TCR public key.

[0090] The integrity verification unit 53 is used to perform firmware integrity verification on the embedded terminal according to the hardware encryption mode when the TCR public key is valid, and obtain the verification result. When the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the unit controls the embedded terminal to start.

[0091] In this embodiment, after the embedded terminal completes hardware initialization upon power-on, its hardware configuration information is automatically acquired. Based on this information, the hardware encryption mode currently used by the device is dynamically identified, including external SE chip mode, built-in SEC accelerator mode, or software-implemented encryption / decryption mode, thereby achieving adaptive adaptation to terminals with different hardware architectures. Subsequently, based on the identified encryption mode, the TCR public key is extracted from the corresponding secure storage area and its legitimacy is verified to ensure the trustworthiness of the authentication root trust chain. After the public key verification is successful, a matching verification algorithm and execution path are selected in conjunction with the current hardware encryption mode to perform integrity verification on the firmware. Only when the verification result shows that the firmware has not been tampered with is the terminal allowed to continue booting. Through this series of linkage mechanisms based on dynamic hardware configuration decisions, the limitation of traditional secure boot processes being unable to be deployed across platforms due to the fixed hardware architecture is effectively overcome. Intelligent adaptation and unified security management of diverse embedded terminal hardware environments are achieved, thereby solving the technical problems of poor cross-platform compatibility, high deployment costs, and insufficient security protection capabilities caused by large differences in hardware configuration and rigid secure boot processes in the prior art. This also solves the problem of poor adaptability of existing secure boot solutions.

[0092] As an optional scheme, the integrity verification unit includes a first acquisition module and a first decryption module; the first acquisition module is used to acquire an encryption scheme corresponding to the external SE chip mode from the encryption algorithm library when the hardware encryption mode is the external SE chip mode, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm type and key length; the first decryption module is used to acquire an encryption scheme corresponding to the external SE chip mode from the encryption algorithm library when the hardware encryption mode is the external SE chip mode, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm type and key length.

[0093] An optional scheme, the integrity verification unit includes a second acquisition module and a second decryption module; the second acquisition module is used to acquire an encryption scheme corresponding to the built-in SEC accelerator mode from the encryption algorithm library when the hardware encryption mode is the built-in SEC accelerator mode, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm type and key length; the second decryption module is used to input the encryption scheme into the built-in SEC accelerator, decrypt the firmware of the embedded terminal based on the built-in SEC accelerator to obtain decrypted firmware, and perform the firmware integrity verification on the decrypted firmware.

[0094] An optional scheme, the integrity verification unit includes a third acquisition module and a third decryption module; the third acquisition module is used to acquire an encryption scheme corresponding to the software implementation encryption and decryption mode from the encryption algorithm library when the hardware encryption mode is the software implementation encryption and decryption mode, wherein each encryption scheme in the encryption algorithm library is a pre-configured scheme containing a combination order of multiple encryption algorithms, algorithm type and key length; the third decryption module is used to decrypt the firmware of the embedded terminal according to the encryption scheme using a software algorithm to obtain decrypted firmware.

[0095] In one optional scheme, the acquisition unit includes a reading module and a determining module; the reading module is used to read the hardware configuration information of the embedded terminal stored in a preset storage location in Flash, wherein the hardware configuration information is a single-byte parameter; the determining module is used to determine the hardware encryption mode of the embedded terminal based on the single-byte parameter.

[0096] In one alternative embodiment, the device further includes a generation unit and a writing unit; the generation unit is used to obtain a random algorithm generated by the user based on custom software when the first power-on initialization of the embedded terminal is detected, and generate a random address of the TCR in the on-chip one-time programmable non-volatile memory according to the random algorithm; the writing unit is used to write the TCR public key into the random address.

[0097] In an optional embodiment, the apparatus further includes a processing unit, configured to process the TCR public key using a hash algorithm during the process of writing the TCR public key to the random address, obtain a verification value corresponding to the TCR public key, and write the verification value to the random address.

[0098] In an optional embodiment, the apparatus further includes a termination unit, configured to terminate the startup of the embedded terminal and output an error message after performing firmware integrity verification on the embedded terminal according to the aforementioned hardware encryption mode and obtaining the verification result, provided that the verification result indicates that the firmware integrity verification of the embedded terminal has failed.

[0099] The aforementioned secure boot device for the embedded terminal includes a processor and a memory. The acquisition unit, verification unit, integrity verification unit, etc., are all stored as program units in the memory, and the processor executes these program units to achieve their respective functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0100] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured; adjusting kernel parameters can address the poor compatibility issues of existing secure boot schemes.

[0101] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0102] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute the secure boot method of the embedded terminal.

[0103] Specifically, the secure boot method for embedded terminals includes:

[0104] Step S201: When the embedded terminal is detected to have completed hardware initialization, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0105] Step S202: According to the above hardware encryption mode, obtain the TCR public key of the above embedded terminal and verify the legality of the above TCR public key;

[0106] Step S203: If the TCR public key is valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain the verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

[0107] This invention provides a processor for running a program, wherein the program executes the secure boot method of the embedded terminal.

[0108] Specifically, the secure boot method for embedded terminals includes:

[0109] Step S201: When the embedded terminal is detected to have completed hardware initialization, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0110] Step S202: According to the above hardware encryption mode, obtain the TCR public key of the above embedded terminal and verify the legality of the above TCR public key;

[0111] Step S203: If the TCR public key is valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain the verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

[0112] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0113] Step S201: When the embedded terminal is detected to have completed hardware initialization, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0114] Step S202: According to the above hardware encryption mode, obtain the TCR public key of the above embedded terminal and verify the legality of the above TCR public key;

[0115] Step S203: If the TCR public key is valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain the verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

[0116] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0117] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0118] Step S201: When the embedded terminal is detected to have completed hardware initialization, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode.

[0119] Step S202: According to the above hardware encryption mode, obtain the TCR public key of the above embedded terminal and verify the legality of the above TCR public key;

[0120] Step S203: If the TCR public key is valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain the verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

[0121] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0122] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0123] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0124] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0125] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0126] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0127] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0128] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0130] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0131] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A secure boot method for an embedded terminal, characterized in that, include: When the embedded terminal is detected to have completed hardware initialization after power-on, the hardware configuration information of the embedded terminal is obtained, and the hardware encryption mode of the embedded terminal is determined according to the hardware configuration information. The hardware encryption mode includes external SE chip mode, built-in SEC accelerator mode and software implementation encryption / decryption mode. According to the hardware encryption mode, obtain the TCR public key of the embedded terminal and verify the legality of the TCR public key; If the TCR public key is verified as valid, the embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode to obtain a verification result. If the verification result indicates that the firmware integrity verification of the embedded terminal is successful, the embedded terminal is controlled to start.

2. The method according to claim 1, characterized in that, The embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode, including: When the hardware encryption mode is the external SE chip mode, an encryption scheme corresponding to the external SE chip mode is obtained from the encryption algorithm library. Each encryption scheme in the encryption algorithm library is a pre-configured scheme that includes a combination order of multiple encryption algorithms, algorithm types and key lengths. The encryption scheme is input into the external SE chip, and the firmware of the embedded terminal is decrypted based on the external SE chip to obtain decrypted firmware. The firmware integrity is then verified on the decrypted firmware.

3. The method according to claim 1, characterized in that, The embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode, including: When the hardware encryption mode is the built-in SEC accelerator mode, an encryption scheme corresponding to the built-in SEC accelerator mode is obtained from the encryption algorithm library. Each encryption scheme in the encryption algorithm library is a pre-configured scheme that includes a combination order of multiple encryption algorithms, algorithm types and key lengths. The encryption scheme is input into the built-in SEC accelerator, and the firmware of the embedded terminal is decrypted based on the built-in SEC accelerator to obtain decrypted firmware. The firmware integrity is then verified on the decrypted firmware.

4. The method according to claim 1, characterized in that, The embedded terminal is subjected to firmware integrity verification according to the hardware encryption mode, including: When the hardware encryption mode is the software implementation encryption / decryption mode, an encryption scheme corresponding to the software implementation encryption / decryption mode is obtained from the encryption algorithm library. Each encryption scheme in the encryption algorithm library is a pre-configured scheme that includes a combination order of multiple encryption algorithms, algorithm types, and key lengths. The firmware of the embedded terminal is decrypted using a software algorithm according to the encryption scheme to obtain decrypted firmware.

5. The method according to claim 1, characterized in that, Obtaining the hardware configuration information of the embedded terminal and determining the hardware encryption mode of the embedded terminal based on the hardware configuration information includes: Read the hardware configuration information stored in a preset storage location in Flash of the embedded terminal, wherein the hardware configuration information is a single-byte parameter; The hardware encryption mode of the embedded terminal is determined based on the single-byte parameter.

6. The method according to claim 1, characterized in that, The method further includes: Upon detecting the first power-on initialization of the embedded terminal, a random algorithm generated by the user based on custom software is obtained, and a random address in the on-chip one-time programmable non-volatile memory of the TCR is generated according to the random algorithm; Write the TCR public key into the random address.

7. The method according to claim 6, characterized in that, The method further includes the following steps during the process of writing the TCR public key to the random address: The TCR public key is processed using a hash algorithm to obtain a check value corresponding to the TCR public key, and the check value is written to the random address.

8. The method according to claim 1, characterized in that, After performing firmware integrity verification on the embedded terminal according to the hardware encryption mode and obtaining the verification result, the method further includes: If the verification result indicates that the firmware integrity verification of the embedded terminal has failed, the startup of the embedded terminal is terminated and an error message is output.

9. A safe start system, characterized in that, The secure boot system is used to execute the secure boot method for an embedded terminal according to any one of claims 1 to 8, the secure boot system comprising: The hardware adaptation layer is used to detect the hardware encryption mode of the embedded terminal. The core layer of the Trusted Computing Base is used to verify the legitimacy of the TCR public key according to the hardware encryption mode; The security function layer is used to perform firmware integrity verification on the embedded terminal.

10. The safe start system according to claim 9, characterized in that, The secure boot system also includes an interface layer, which is used to support upper-layer applications or developers in configuring, controlling, and monitoring the status of the secure boot system.

Images