Chip-based secure boot method and device

Abstract

This application provides a chip-based secure boot method and apparatus. The chip includes a boot engine and a first memory. The first memory is a one-time programmable memory. Boot information is embedded in the boot engine. The method includes: the boot engine obtaining first verification information from the first memory based on the boot information, obtaining a first instruction set from a second memory, and verifying the first instruction set and a first public key using the first verification information. If the verification passes, the first instruction set is triggered to run. The second memory is a read-write memory. The first public key is used to verify the second instruction set using the first instruction set. The first instruction set is also used to trigger the second instruction set to run after the second instruction set passes verification. The second instruction set is used to boot the operating system. This application can improve the security of device system boot.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a chip-based secure boot method and apparatus. Background Technology

[0002] With the development of the internet and communication technologies, more and more devices can achieve automation and intelligence through communication networks, the Internet of Things (IoT), etc., providing people with greater convenience. As people's lives become increasingly reliant on various devices, device network security is becoming increasingly important. Device network security is related to the device's startup method. For example, some devices store the instruction set used to boot the device in their readable and writable memory. When the device is powered on, the boot instruction set can be read from the readable and writable memory to perform hardware checks, initialization, and other operations. When the operating environment is ready, the boot instruction set is run to boot the device. This method facilitates the repair and upgrading of the boot instruction set, but it is vulnerable to malicious attacks. Others can easily modify the boot instruction set in the readable and writable memory, implanting malicious code and thus threatening the device's security. Summary of the Invention

[0003] This application provides a chip-based secure boot method and apparatus, which can improve the security of device system boot.

[0004] The first aspect of this application provides a chip-based secure boot method. This method can be implemented based on a chip, which may include a first memory and a boot engine. The first memory is a one-time programmable memory, and the boot engine contains boot information.

[0005] In this method, the boot engine retrieves first verification information from the first memory and a first instruction set from the second memory based on the boot information. It then uses the first verification information to verify the first instruction set and the first public key, and triggers the execution of the first instruction set if the verification passes. The second memory is a read-write memory; it can be internal to the chip or external. The first public key serves as the basis for verifying the second instruction set using the first instruction set. The first instruction set is also used to trigger the execution of the second instruction set after its verification passes, and it is used to boot the operating system.

[0006] In this method, the startup information is stored in the startup engine, and the first verification information is stored in the first memory. This enables the startup engine to verify that the verification algorithm of the first instruction set and the first public key (included in the startup information) and the verification benchmark (i.e., the first verification information) are reliable. This ensures that the trust chain for secure startup is reliably transmitted to the first instruction set and the first public key, thereby guaranteeing the secure startup of the device.

[0007] In conjunction with the first aspect, in one alternative approach, the boot engine may include a third memory, and the boot information includes a third instruction set stored in the third memory.

[0008] In conjunction with the first aspect, in one alternative approach, the startup engine may include hardware circuitry, and the startup information includes logic information embedded in the hardware circuitry.

[0009] In conjunction with the first aspect, in one alternative approach, the first verification information includes a first hash value, which is calculated using a merging algorithm and a first hash algorithm.

[0010] When the startup engine uses the first verification information for verification, it specifically determines the first merge result of the first instruction set and the first public key through the aforementioned merging algorithm, and calculates the second hash value of the first merge result through the first hash algorithm. If the second hash value matches the first hash value, the execution of the first instruction set is triggered. Verifying both the first instruction set and the first public key hash using the first hash value saves space occupied by the first verification information in the first memory.

[0011] In conjunction with the first aspect, in one optional approach, the first verification information includes a third hash value and a fourth hash value. The third hash value is used to verify the first instruction set and is calculated using a second hash algorithm. The fourth hash value is used to verify the first public key and is calculated using the third hash operation.

[0012] When the startup engine verifies using the first verification information, it specifically calculates the fifth hash value of the first instruction set using the second hash algorithm and the sixth hash value of the first public key using the third hash algorithm. Then, if the fifth hash value and the third hash value are the same, and the sixth hash value and the fourth hash value are the same, the first instruction set is triggered to run.

[0013] In conjunction with the first aspect, in one optional approach, the first memory stores second verification information. This second verification information is used to verify the first instruction set and the second public key. The startup engine triggers the execution of the first instruction set only after the verification of the first instruction set, the first public key, and the second public key has passed. The second public key serves as the basis for verifying the second instruction set using the first instruction set. Specifically, the first instruction set is used to trigger the execution of the second instruction set only after both the first and second public keys have passed their verification. The first and second verification information stored in the first memory enable dual-signature secure startup, preventing unilateral tampering of the first instruction set or the first public key, thus enhancing device security.

[0014] In conjunction with the first aspect, in one optional approach, the first memory stores two or more verification information, and also stores first indication information used to indicate the first verification information. Specifically, the boot engine can retrieve the first verification information from the two or more verification information based on the first indication information, and use the first verification information to verify the first instruction set and the first public key corresponding to the first verification information. If the verification passes, the first instruction set is triggered to run. Using the first indication information in the first memory to indicate the first verification information used to verify the first instruction set and the first public key improves the flexibility of secure boot.

[0015] In conjunction with the first aspect, in one alternative approach, the second instruction set is specifically used to verify the boot instruction set of the operating system; and to trigger the execution of the boot instruction set to perform the verification of the operating system if the verification of the boot instruction set passes; and to start the operating system if the verification of the operating system passes.

[0016] In conjunction with the first aspect, in one optional approach, after triggering the execution of the first instruction set, the boot engine also retrieves the first signature information of the secondary public key from the second memory, wherein the secondary public key is a derived public key corresponding to the first public key. Then, it verifies the secondary public key using the first signature information and the first public key. If the verification of the secondary public key is successful, it retrieves the second instruction set and the second signature information of the second instruction set from the second memory. The boot engine then verifies the second instruction set using the second signature information and the secondary public key. If the verification is successful, it triggers the execution of the second instruction set.

[0017] In conjunction with the first aspect, in one optional approach, when verifying the secondary public key, the startup engine retrieves the corresponding block information from the first memory. This block information indicates the application device category of the chip. Based on the block information and the secondary public key, a third hash value is determined. Then, the first signature information is decrypted using the first public key to obtain a fourth hash value. If the third and fourth hash values ​​are equal, the execution of the second instruction set is triggered. Since the first signature information of the secondary public key is determined based on the block information, the security risks arising from the mutual copying of the secondary public key and its first signature information between different types of devices are avoided.

[0018] The second aspect of this application provides a secure boot device, which may be a communication device, an Internet device, an Internet of Things device, or a part of such a device (such as a circuit or a chip). The secure boot device includes a first memory and a boot engine.

[0019] The first memory stores the first verification information. The boot engine stores the boot information and is also used to: retrieve the first verification information from the first memory based on the boot information; retrieve the first instruction set from the second memory; verify the first instruction set and the first public key using the first verification information; and trigger the execution of the first instruction set if the verification passes. The first memory is a one-time programmable memory, and the second memory is a read-write memory. The first public key serves as the basis for verifying the second instruction set using the first instruction set. The first instruction set is also used to trigger the execution of the second instruction set after its verification passes. The second instruction set is used to boot the operating system.

[0020] In this device, the startup engine contains startup information, and the first memory contains first verification information. This ensures that the verification algorithm and verification benchmark used by the startup engine to verify the first instruction set and the first public key are reliable. This enables the reliable transmission of the trust chain for secure startup to the first instruction set and the first public key, thereby ensuring the secure startup of the device.

[0021] In conjunction with the second aspect, in one alternative approach, the boot information includes a third instruction set, which instructs the verification of the first instruction set and the first public key using the first verification information, and, if the verification passes, to run the first instruction set. The boot engine includes a third memory and a first processor; the third memory is a read-only memory used to store the third instruction set; the first processor is used to run the third instruction set.

[0022] In conjunction with the second aspect, in one alternative approach, the boot engine includes hardware circuitry, and the boot information includes logic information embedded in the hardware circuitry. The hardware circuitry is used to verify the first instruction set and the first public key using first verification information based on the logic information, and to trigger the second processor to run the first instruction set if the verification of the first instruction set and the first public key passes.

[0023] In conjunction with the second aspect, in one optional approach, the first memory stores second verification information, which is used to verify the first instruction set and the second public key. Specifically, the startup engine is used to trigger the execution of the first instruction set if the verification of the first instruction set, the first public key, and the second public key all pass. The second public key serves as the basis for verifying the second instruction set using the first instruction set. Specifically, the first instruction set is used to trigger the execution of the second instruction set if both the verification of the second instruction set using the first public key and the verification of the second instruction set using the second public key pass. Verification of both the first instruction set and the hash of the first public key is achieved through a first hash value, saving space occupied by the first verification information in the first memory.

[0024] In conjunction with the second aspect, in one optional approach, the first memory stores two or more verification information; the first memory also stores first indication information. The boot engine is specifically used to: obtain the first verification information from the two or more verification information according to the first indication information, and use the first verification information to verify the first instruction set and the first public key corresponding to the first verification information; and, if the verification is successful, trigger the execution of the first instruction set. The first and second verification information stored in the first memory can achieve dual-signature secure boot, preventing unilateral tampering of the first instruction set or the first public key, thus improving device security.

[0025] A third aspect of this application provides a storage medium storing instructions that, when executed on a processor, cause the processor to perform the chip-based secure boot method described in the first aspect and any possible implementation thereof.

[0026] The fourth aspect of this application provides a program product, which includes program code that, when run on a processor, causes the processor to execute the chip-based secure boot described in the first aspect and any possible implementation thereof. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of a secure boot process provided in an embodiment of this application;

[0029] Figure 2 This is a schematic diagram of a secure boot architecture provided in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of another secure boot architecture provided in an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of another secure boot architecture provided in an embodiment of this application;

[0032] Figure 5 This is a schematic flowchart of a chip-based secure boot method provided in an embodiment of this application;

[0033] Figure 6 This is a schematic diagram of a process for securely launching a device app according to an embodiment of this application;

[0034] Figure 7 A schematic diagram illustrating the updating of a first public key as provided in an embodiment of this application;

[0035] Figure 8 This is a schematic diagram of a dual-signature secure boot method provided in an embodiment of this application;

[0036] Figure 9 This is a schematic diagram of the structure of a safe start device provided in an embodiment of this application. Detailed Implementation

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

[0038] This application addresses the security vulnerabilities in existing devices during startup by proposing a chip-based secure startup method. To better understand this method, before introducing the chip-based secure startup method provided in this application, we will first introduce the objects or technologies that may be involved in this application.

[0039] 1. Safe Start

[0040] Secure boot is a technology that primarily uses digital signatures to ensure the trustworthiness of a system during startup. By employing public-key decryption, digital signatures, and hash algorithms, it guarantees that only systems or software signed by a specific entity (such as the equipment manufacturer of a communication device) can run on the device.

[0041] Secure boot typically requires certain hardware infrastructure, often referred to as the Root of Trust (RoT). The RoT verifies the integrity of the first instruction outside the RoT. Once the integrity of the first instruction is verified, the digital signature of the subsequently loaded object is verified using the first instruction to ensure the integrity of the subsequently loaded object. This "verify first, execute if verification is successful" approach is used to pass the trust chain down level by level.

[0042] See Figure 1 , Figure 1 This is a schematic diagram of a secure boot process provided in an embodiment of this application, such as... Figure 1 As shown, Figure 1 In this key pair, private key 1 and public key 1 are a key pair, private key 2 and public key 2 are a key pair, and private key 3 and public key 3 are a key pair. These key pairs can be generated by a certificate authority. Each key pair can be different, or there can be identical key pairs. For example, private key 1 and private key 2 are the same, and public key 1 and public key 2 are the same. Figure 1 In this process, the digital signature of the loader is obtained by encryption using private key 1, the digital signature of the operating system (OS) is obtained by encryption using private key 2, and the digital signature of the application is obtained by encryption using private key 3. The device can boot the loader, operating system, and application sequentially through the root of trust. Specifically: First, the root of trust decrypts and verifies the digital signature of the loader using public key 1; then, if the loader's digital signature verification is successful, the loader runs, and the loader decrypts and verifies the operating system's digital signature using public key 2; subsequently, if the operating system's digital signature verification is successful, the operating system runs, and the operating system decrypts and verifies the application's digital signature using public key 3, and then runs the application. The loader is used to initialize and boot the operating system. This process, by verifying the integrity of subsequent programs through digital signatures, achieves secure boot.

[0043] 2. Single-signature secure boot mechanism and multi-signature secure boot mechanism

[0044] A single-signature secure boot mechanism is a scheme that uses a single digital signature for verification during the secure boot process. For example, in some secure boot verification scenarios for communication devices, the object to be loaded can be signed using the device manufacturer's private key. During boot verification, the device manufacturer's public key is used to decrypt and verify the signature. The device manufacturer's private key is held by the device manufacturer, while the device manufacturer's public key can be obtained by the device user and used for digital signature verification.

[0045] Multi-signature secure boot is a scheme that uses multiple independent digital signatures for verification during the secure boot process. For example, dual-signature secure boot is a type of multi-signature secure boot mechanism. During secure boot, the device user needs to ensure secure boot through the digital signatures of both the device manufacturer and the user. That is, both the device manufacturer and the user sign the object to be loaded using their own private keys. During boot verification, the device manufacturer's digital signature is decrypted and verified using their public key, and the device user's digital signature is decrypted and verified using their public key. If both digital signatures pass verification, the subsequent objects to be loaded can be executed. The device manufacturer's private key is held by the device manufacturer, and the device user's private key is held by the device user. Both the device manufacturer's and the device user's public keys can be obtained by the device user and used for digital signature verification. It is clear that multi-signature secure boot, through multiple independent digital signatures, ensures that the object to be loaded cannot be unilaterally tampered with, resulting in higher security and better meeting the needs of complex application environments.

[0046] 3. Digital signature, verification mechanism, and signature key pair

[0047] Digital signature and verification mechanisms can be implemented based on a signature key pair containing a public key and a private key. The private key is used for signing, and the public key is used for decryption and verification. The digital signature mechanism calculates a digest of the information to be signed using a hash algorithm, and then encrypts this digest using the private key to obtain the digital signature. The verification mechanism decrypts the digital signature of the information to be verified using the public key, calculates the digest of the information to be verified using the same hash algorithm, and compares the decrypted digest with the hashed digest. If they are the same, the verification is successful; otherwise, the verification fails.

[0048] The signing party (such as the device manufacturer or user) typically possesses a long-term signing key pair. This key pair may be issued by a CA (Certificate Authority), and its security level is usually quite high. The signing party typically does not directly use this key pair to sign the object to be loaded (such as an operating system or application). Instead, it periodically derives new key pairs from this root key pair using a specific key derivation algorithm. The key pair issued by the CA can be called the root key pair, and the derived key pairs can be called subkey pairs or secondary key pairs. A secondary key pair also contains a secondary public key and a secondary private key. The secondary private key is used for signing, and the secondary public key is used for decrypting and verifying the digital signature. By periodically updating the secondary key pair and using the new secondary key pair to sign and protect the object to be loaded, the risk of unauthorized tampering with the object due to the leakage of the original secondary key pair is avoided.

[0049] 4. OTP memory

[0050] OTP (One-Time Programmable) memory can limit the number of times data can be written to it using write protection. For example, a flag can be set in the OTP memory to indicate the number of times it can be written to. Typically, this type of memory is set to allow data to be written only once; after the data is written, it can only be read and cannot be modified or deleted. This memory can store parameters that do not need to be changed during secure boot, preventing malicious tampering.

[0051] When writing data to an OTP memory, after the data is written, there may still be bits in the OTP memory that have not been written. Write protection is to prevent other illegal information from being written to these unwritten bits. A dedicated bit in the OTP memory is used to lock the remaining bit space, thereby limiting the number of write operations to the OTP memory. For example, when the dedicated bit is "0", it means that the remaining bit space in the OTP memory is not locked, and write operations can continue to be performed on the OTP memory; when the dedicated bit is "1", it means that the remaining bit space in the OTP memory is locked, and when an external command attempts to write to the OTP memory, the OTP memory refuses to execute the command.

[0052] OTP memory includes eFuse (one-time electrically programmable fuse) memory, Antifuse (anti-fuse) memory, etc.

[0053] 5. BootRom

[0054] BootROM (or Boot ROM) is a small mask ROM inside the chip that contains the first set of instructions executed when the chip is powered on or reset. Depending on the configuration of certain ribbon pins or internal fuses, it can determine where to load the next set of instructions to be executed and how to verify that it is correct or valid.

[0055] 6. BSBC

[0056] BSBC (Boot ROM Secure Boot Code) is logic code embedded within the chip during the chip manufacturing process (e.g., embedded in the Boot ROM). This code is read-only and cannot be tampered with by any hardware or software. During its execution, this embedded code will not be interrupted by any external logic.

[0057] The main function of BSBC is to perform security verification on objects whose integrity is unknown before loading them, and to load and run the object if the integrity verification passes.

[0058] 7. ESBC

[0059] The ESBC (External Secure Boot Code) is the first secure boot code executed after the embedded code in the chip runs. The ESBC can be loaded as a BSBC object, and is verified and started by the BSBC.

[0060] The functions of ESBC may include:

[0061] (1) Initialize hardware, such as initializing memory, initializing bus, initializing DAW (Digital Audio Workstation), etc.

[0062] (2) Select the boot medium (such as RAM) and load the lower-level image, such as UEFI (Unified Extensible Firmware Interface) or BIOS (Basic Input and Output System).

[0063] (3) Verify the lower-level image according to the security policy. If the verification is successful, execute the lower-level image; if the verification fails, stop executing the lower-level image.

[0064] 8. Boot command set

[0065] The boot instruction set can be a BIOS or UEFI instruction set, and can have the following functions:

[0066] (1) The hardware is tested when the power is on, also known as Power On Self Test (POST).

[0067] (2) Initialization, including creating interrupt vectors, setting registers, initializing and detecting some external devices, setting hardware parameters, etc.

[0068] (3) Boot the operating system.

[0069] It can be seen that the functions of BIOS and ESBC overlap to some extent, such as initialization-related functions. In some practical applications, ESBC can include BIOS, that is, ESBC can take on some of the functions of BIOS, or BIOS can be regarded as part of ESBC.

[0070] 9. SoC

[0071] A System-on-a-Chip (SoC) is a system that integrates controllers for various external modules on a single chip via a bus. For example, the SoC inside a mobile phone integrates an ARM (Advanced RISC Machine) core (CPU), DDR SDRAM (Double Data Rate Synchronous Dynamic Random Access Memory), Wi-Fi (Wireless Fidelity) module, UART (Universal Asynchronous Receiver / Transmitter), camera, touchscreen, and other modules onto a single chip via a bus. The ARM core can interconnect these modules at high speed via the AXI (Advanced eXtensible Interface) protocol.

[0072] A SoC is a system that performs secure boot functions on a chip. It can serve as a RoT for secure device boot and may include BootROM and OTP, as well as hardware accelerators. The BootROM may contain a BSBC.

[0073] 10. Reliable version instruction set, reliable version key, reliable version certificate

[0074] The signature of a reliable version instruction set can be used to verify other version instruction sets corresponding to that reliable version instruction set. These other version instruction sets can be instruction sets that have been used for a period of time and transmitted through certain transmission nodes. These other version instruction sets may be at risk of being tampered with during use or transmission; therefore, the signature of the reliable version instruction set can be used to verify whether these other version instruction sets have been tampered with. In one implementation, the reliable version instruction set can be an instruction set that has been developed, tested, and released by researchers and has never been tampered with.

[0075] Correspondingly, the signature of the reliable version key can be used to verify other version keys corresponding to that reliable version key. These other version keys can be keys obtained after the reliable version key has been used for a period of time and transmitted through certain transmission nodes. Similarly, the signature of the reliable version certificate can be used to verify other version certificates corresponding to that reliable version certificate. These other version certificates can be certificates obtained after the reliable version certificate has been used for a period of time and transmitted through certain transmission nodes. In one implementation, the reliable version key can be a reliable key contained in a certificate issued by a certificate authority that has not been tampered with, and the reliable version certificate can be a certificate issued by a certificate authority that has not been tampered with.

[0076] The architecture upon which the chip-based secure boot method provided in this application is based is described below. (See attached document.) Figure 2 , Figure 2 This is a schematic diagram of a secure boot architecture provided in an embodiment of this application, such as... Figure 2 As shown, the secure boot architecture 1 includes a first memory 10, a second memory 20, and a boot engine 30. The boot engine 30 is connected to both the first memory 10 and the second memory 20. Optionally, the first memory 10 and the boot engine 30 can be modules within the SoC, while the second memory 20 can be a module outside the SoC. For example, the second memory 20 can be a memory on the same board as the chip, or it can be a memory in a remote device. Alternatively, the second memory 20 can also be a module within the SoC, which can be connected to other modules within the SoC via a bus.

[0077] The functions of each module in this Secure Boot Architecture 1 are described in detail below:

[0078] The first memory 10 may be an one-time programmable (OTP) memory, which is used to store the first verification information.

[0079] The second memory 20 can be a read-write memory. The second memory 20 stores the first instruction set, which is used to verify the second instruction set, and the second instruction set is used to boot the operating system. Optionally, the second memory 20 can also store the first public key.

[0080] The startup engine 30 is used to store startup information, retrieve first verification information from the first memory 10 based on the startup information, retrieve the first instruction set from the second memory 20, verify the first instruction set and the first root public key using the first verification information, and trigger the execution of the first instruction set if the verification is successful.

[0081] The startup engine 30 has multiple implementation methods, combined with Figure 3 The first implementation method is introduced; please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of another secure boot architecture provided in an embodiment of this application, such as... Figure 3 As shown, the startup engine 30 includes a first processor 301 and a third memory 302.

[0082] The third memory 302 stores a third instruction set, which is boot information embedded in the boot engine 30. This third instruction set instructs the use of the first verification information in the first memory 10 to verify the first instruction set and the first public key in the second memory 20, and to run the first instruction set if the verification passes. The first processor 301 is used to run the third instruction set.

[0083] Optional, such as Figure 3 As shown, the startup engine 30 may also include a fourth memory 303, which may be an internal static random access memory (ISRAM). The fourth memory 303 is used to store temporary files and data generated by the first processor 301 when running the third instruction set.

[0084] Combination Figure 4 This section introduces a second implementation method for Startup Engine 30; see [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of another secure boot architecture provided in an embodiment of this application, such as... Figure 4 As shown, the boot engine 30 includes a hardware circuit 304. The hardware circuit 304 stores logic information, which is the boot information stored in the boot engine 30, used to guide the hardware circuit 304 to perform a secure boot.

[0085] Optional, such as Figure 4 As shown, in the second implementation, the architecture may further include a second processor 40, which may be a central processing unit. The architecture may also include a fifth memory 50, which may be an internal static random access memory.

[0086] Hardware circuit 304 is used to verify the first instruction set and the first root public key in the second memory 20 using the first verification information in the first memory 10, and to trigger the second processor 40 to run the first instruction set if the verification is successful. The fifth memory 50 can be used to store temporary files and data generated by the second processor 40 when running the first instruction set.

[0087] It should be understood that Figure 3 and Figure 4 In the architecture shown, the first memory 10 and the boot engine 30 are internal modules of the SoC, and the second memory 20 is an external module of the SoC. It is understood that in another alternative embodiment, not shown, the first memory 10, the second memory 20, and the boot engine 30 can all be internal modules of the SoC.

[0088] In this architecture, since the second memory 20 is a readable and writable memory and is a non-secure guarantee area in the architecture, the boot engine 30 verifies the first instruction set and the first public key in the non-secure guarantee area based on the boot information stored in the hard drive and the first verification information written-protected in the first memory 10. Since the boot information is hard-stored in the boot engine 30 and the first verification information is stored in the first memory 10 with write protection, both are immutable. This ensures that when verifying the first instruction set and the first public key, the verification algorithm (included in the boot information) and the verification benchmark (i.e., the first verification information) are reliable. This realizes the reliable transmission of the trust chain for secure boot to the first instruction set and the first public key, thereby ensuring the secure boot of the system.

[0089] based on Figures 2-4 Any of the following architectures can implement the chip-based secure boot method provided in this application embodiment. The chip-based secure boot method provided in this application embodiment is described below. This method can be applied to the system boot process of various devices, such as communication devices including routers and switches, and internet devices such as servers and firewalls. The device may include a chip, thereby completing the secure boot of the system through the chip. Specifically, the chip may include at least a first memory and a boot engine, with the boot engine storing boot information. Optionally, the device may also include a second memory, which can be internal to the chip or external to the chip. For a detailed description of the first memory, the boot engine, and the second memory, as well as the connection relationship between them, please refer to [link to relevant documentation]. Figures 2 to 4 The architecture described in the text, including the first memory 10, the boot engine 30, and the second memory 20, will not be repeated here.

[0090] It should be noted that the instruction sets involved in the embodiments of this application, such as the first instruction set, the second instruction set, the third instruction set, the original instruction set, the boot instruction set, etc., can be instruction sets in any assembly language form, such as those using semi-compiled or fully compiled languages.

[0091] See Figure 5 , Figure 5 This is a flowchart illustrating a chip-based secure boot method provided in an embodiment of this application, as shown below. Figure 5 As shown, the method may include at least steps S501-S503.

[0092] S501, the startup engine obtains the first verification information from the first memory according to the startup information.

[0093] After the device is powered on, the engine automatically executes step S501. There are different implementations of the engine startup method; please refer to [reference needed]. Figure 3 and Figure 4 The article introduces two implementation methods for startup engine 30.

[0094] When the boot engine includes a third memory and a first processor, the third memory can be a read-only memory, specifically a boot read-only memory (BootROM). The third memory stores a third instruction set, which can be a BSBC. After the processor is powered on, the third instruction set is copied from the third memory to the execution space of the first processor, and the third instruction set is executed. The execution process of the third instruction set can obtain the first verification information from the first memory and execute S502 and S503.

[0095] When the engine starts, it includes hardware circuitry. The hardware circuitry contains logic information. The hardware circuitry may include devices such as AND gates, OR gates, NOT gates, RAM, and flip-flops. The logic information is stored in the hardware circuitry through the arrangement, connection, and combination of these devices. When the hardware circuitry is powered on, it retrieves the first verification information from the first memory and executes S502 and S503.

[0096] Both of the above methods can solidify the startup information within the chip, ensuring the integrity and reliability of the first instruction set executed by the startup engine after power-on, thus laying a safe foundation for the subsequent system startup.

[0097] The first memory is a readable and writable memory. The first verification information can be written into the first memory during the chip manufacturing stage or before the device is put into use. The first verification information is determined based on the original instruction set and the original root public key, where the original instruction set is the reliable version instruction set corresponding to the first instruction set, and the original root public key is the reliable version key corresponding to the first public key.

[0098] There are several ways to determine the first verification information based on the original instruction set and the original root public key. Two examples are described here: In the first method, the first verification information includes a first hash value. The original instruction set and the original root public key are merged according to a first merging algorithm to obtain an original merged result. The first hash value of this original merged result is then calculated using the first hash operation. In the second method, the first verification information includes a third hash value and a fourth hash value. The third hash value of the original instruction set is calculated using a second hash algorithm, and the fourth hash value of the original root public key is calculated using the third hash algorithm.

[0099] In the above method, the first merging algorithm can be a method of concatenating the original instruction set and the original root public key one after the other, or a method of cross-concatenating the original instruction set and the original root public key according to a specified method, or other merging algorithms, none of which are limited. It can generate a hash value for the original instruction set and the original root public key and store it in the first memory, saving storage space in the first memory. The first hash algorithm, the second hash algorithm, and the third hash algorithm can be algorithms such as MD5 (Message-Digest Algorithm 5), SHA1 (Secure Hash Algorithm 1), or SHA256 (Secure Hash Algorithm 256). The first hash algorithm, the second hash algorithm, and the third hash algorithm can be the same or different from each other.

[0100] S502, the start engine fetches the first instruction set from the second memory.

[0101] In this system, the first instruction set is used to verify the second instruction set, which is used to boot the operating system. The second instruction set can directly verify the operating system and boot it upon successful verification; in this case, the first instruction set can be an ESBC (Executable Startup Controller). Alternatively, the second instruction set can be used to verify the operating system indirectly through multiple lower-level instruction sets, indirectly triggering its boot process upon successful verification. For example, if the lower-level instruction set of the second instruction set is a boot instruction set (such as BIOS or UEFI), the second instruction set can verify the boot instruction set. If the boot instruction set verification is successful, it triggers the execution of the boot instruction set, which then verifies the operating system. If the operating system verification is successful, the boot instruction set's execution process boots the operating system. In this case, the first instruction set can be a level-one ESBC, and the second instruction set can be a level-two ESBC.

[0102] Optionally, the startup information may include the address of the first instruction set, so that the startup engine can obtain the first instruction set.

[0103] S503, the startup engine uses the first verification information to verify the first instruction set and the first public key, and triggers the execution of the first instruction set if the verification is successful.

[0104] The first public key serves as the basis for verifying the second instruction set using the first instruction set. Optionally, the first public key can be the root public key of the device's security authenticator, such as the device manufacturer or user. Optionally, the first public key can be stored in a second memory. The first instruction set and the first public key can be obtained simultaneously by the startup engine, or they can be obtained separately based on different actions.

[0105] The way the boot engine verifies the first instruction set and the first public key using the first verification information corresponds to the way the first verification information is generated. In other words, during the chip manufacturing stage, the corresponding verification method is written into the boot information according to the way the first verification information is generated, such as being written into the third instruction set or embedded in the logic information of the hardware circuit. Then the boot engine can perform verification according to the verification method in the boot information.

[0106] For example, if the first verification information is determined according to the first method exemplified in step S501, then the way the startup engine verifies the first instruction set and the first root public key using the first verification information is as follows: the startup engine calculates the first merge result of the first instruction set and the original root public key through the first merging algorithm, calculates the second hash value of the first merge result through the first hash algorithm, and triggers the execution of the first instruction set if the second hash value is the same as the first hash value in the first verification information.

[0107] For example, if the first verification information is determined in the second way exemplified in step S501, then the startup engine calculates the fifth hash value of the first instruction set using the second hash algorithm and the sixth hash value of the original root public key using the third hash algorithm. If the fifth hash value is the same as the third hash value in the first verification information and the sixth hash value is the same as the fourth hash value in the first verification information, the first instruction set is triggered to run.

[0108] There are multiple ways to implement the startup engine internally, and correspondingly, there are also multiple ways for the startup engine to trigger the execution of the first instruction set. This is not limited to any specific method, but only illustrated with examples. For instance, when the startup engine... Figure 3When the boot engine 30 includes a first processor 301, a third memory 302, and a fourth memory 303, if the first processor 301 successfully verifies the first instruction set and the first public key using the first verification information, the first processor 301 uses the fourth memory 303 as the execution space for running the first instruction set. For example, when the boot engine... Figure 4 When the startup engine 30 includes hardware circuit 304, when the hardware circuit 304 verifies the first instruction set and the first public key using the first verification information, the hardware circuit 304 sends a run instruction to the second processor 40. When the second processor 40 receives the run instruction, it copies the first instruction set from the second memory 20 to the fifth memory 50, uses the fifth memory 50 as the running space for running the first instruction set, and runs the first instruction set.

[0109] In this embodiment, the startup information is stored in the startup engine, and the first verification information is stored in the first memory. This enables the startup engine to verify that the verification algorithm of the first instruction set and the first public key (included in the startup information) and the verification benchmark (i.e., the first verification information) are reliable. This ensures that the trust chain for secure startup is reliably transmitted to the first instruction set and the first public key, thereby guaranteeing the secure startup of the device.

[0110] Optionally, after the engine starts and triggers the execution of the first instruction set, the trust chain can be passed down level by level. The following describes the transmission of the trust chain. After S503, the following steps may also be included:

[0111] In step S504, the process executing the first instruction set retrieves the first signature information of the secondary public key from the second memory and verifies the secondary public key using the first public key and the first signature information. If the secondary public key verification is successful, step S505 is executed. Here, the secondary public key is a derived public key from the first public key.

[0112] S505, the execution process of the first instruction set obtains the second instruction set and the second signature information of the second instruction set, and verifies the second instruction set using the secondary public key and the second signature information. If the verification is successful, the execution of the second instruction set is triggered, and S506 is executed.

[0113] S506, the running process of the second instruction set obtains the boot instruction set and the third signature information of the boot instruction set, and uses the digital certificate and the third signature information corresponding to the boot instruction set to verify the boot instruction set. If the verification is successful, the running of the boot instruction set is triggered, and S507 is executed.

[0114] S507: The process of booting the instruction set obtains the application software instruction set and its fourth signature information. It then uses the digital certificate and fourth signature information corresponding to the application software instruction set to verify the instruction set. If the verification is successful, the process of booting the application software instruction set is triggered to start the application software.

[0115] To further illustrate the above process, please refer to [reference needed]. Figure 6 , Figure 6 This is a schematic diagram of a device APP secure startup process provided in an embodiment of this application, such as... Figure 6 As shown, the device contains a chip and flash memory. The chip is a system-on-a-chip (SoC) with a SoC deployed inside it.

[0116] The SoC contains a boot engine, including BootROM and OTP memory. BootROM stores BSBC, and OTP stores the first verification information.

[0117] The flash memory stores ESBC(L1) files, ESBC(L2) files, BIOS / OS files, and APP files.

[0118] The ESBC(L1) file contains the ESBC(L1) and the first root public key. The ESBC(L1) is the first-level ESBC.

[0119] The ESBC(L2) file contains the secondary public key and its first private key signature, ESBC(L2), digital signature verification certificate 1, and the secondary private key signature.

[0120] The first private key signature is the signature of the reliable version key corresponding to the second-level public key using the first private key. The first private key and the first public key belong to the same key pair.

[0121] Secondary private key signing can be implemented in two ways. In one optional implementation, secondary private key signing can be used solely to verify the ESBC(L2). For example, secondary private key signing can be the signing of the reliable version instruction set corresponding to the ESBC(L2) using the secondary private key. In another optional implementation, secondary private key signing can be used to verify both the ESBC(L2) and digital signature verification certificate 1, ensuring the reliability of both the ESBC(L2) and digital signature verification certificate 1. For example, secondary private key signing can be the signing of the reliable version instruction set of the ESBC(L2) and the reliable version certificate corresponding to digital signature verification certificate 1 using the secondary private key. Alternatively, secondary private key signing can include both the signing of the ESBC(L2) using the secondary private key and the signing of digital signature verification certificate 1 using the secondary private key. The secondary private key and secondary public key belong to the same key pair. Digital signature verification certificate 1 is a certificate used to verify BIOS / OS files. For example, it can be a certificate from the publisher of the BIOS / OS code, and digital signature verification certificate 1 includes public key 1.

[0122] The BIOS / OS file includes the BIOS / OS code, digital signature verification certificate 2, and digital signature 1.

[0123] Digital signature 1 can be implemented in two ways. In one optional implementation, digital signature 1 can be used only to verify the BIOS / OS code. For example, digital signature 1 can be a signature of the reliable version instruction set corresponding to the BIOS / OS code using private key 1. In another optional implementation, digital signature 1 can be used to verify both the BIOS / OS code and the digital signature verification certificate 2. For example, digital signature 1 can be a signature of the reliable version instruction set corresponding to the BIOS / OS code and the reliable version certificate corresponding to digital signature verification certificate 2 using private key 1. Alternatively, digital signature 2 can include a signature of the reliable version instruction set corresponding to the BIOS / OS code using private key 1 and a signature of the reliable version certificate corresponding to digital signature verification certificate 2 using private key 1. Private key 1 and public key 1 contained in digital signature verification certificate 1 belong to the same key pair. Digital signature verification certificate 2 is used to verify the certificate of the APP file. For example, it can be the certificate of the APP code's publisher. Digital signature verification certificate 2 includes public key 2.

[0124] The APP file includes the APP code and its digital signature 2. Digital signature 2 is a signature of the APP code using private key 2, and private key 2 and public key 2 in the digital signature verification certificate 2 belong to the same key pair.

[0125] like Figure 6 As shown, the specific process for secure app startup is as follows:

[0126] S1. After the SoC is powered on, the BSBC in the BootRom runs. The BSBC process uses the first verification information in the OTP memory to verify the first public key in the flash memory and ESBC(L1). If the verification fails, the boot fails. If the verification passes, the ESBC(L1) is triggered to run and S2 is executed.

[0127] The S2 and ESBC(L1) processes use the first public key and the first private key to sign and verify the second public key. If the verification fails, the startup fails; if the verification succeeds, S3 is executed.

[0128] The S3 and ESBC(L1) processes use the secondary public key and secondary private key to sign and verify EBCS(L2). If the verification fails, the startup fails. If the verification succeeds, the ESBC(L2) process is triggered and S4 is executed.

[0129] The S4 and ESBC(L2) processes use digital signature verification certificate 1 and digital signature 1 to verify the BIOS / OS code. If the verification fails, the boot process fails. If the verification passes, the BIOS / OS code is triggered to run and S5 is executed.

[0130] The S5 and OS running processes use digital signature verification certificate 2 and digital signature 2 to verify the APP code. If the verification fails, the startup fails. If the verification succeeds, the APP code is triggered to run, thus launching the APP.

[0131] If the secondary private key signature is a signature of the reliable version instruction set of ESBC(L2) using the secondary private key, then in S3, after the verification of EBCS(L2) is successful, S4 can be executed. If the secondary private key signature is a signature of the reliable version instruction set of ESBC(L2) and the reliable version certificate corresponding to digital signature verification certificate 1 using the secondary private key, then in S3, the running process of ESBC(L1) uses the secondary public key and secondary private key signature to verify EBCS(L2) and digital signature verification certificate 1, and executes S4 if the verification of EBCS(L2) and digital signature verification certificate 1 is successful; otherwise, the startup fails.

[0132] If digital signature 1 is a signature of the reliable version instruction set corresponding to the BIOS / OS code using private key 1, then in S4, after the BIOS / OS code is verified, S5 can be executed. If digital signature 1 is a signature of the reliable version instruction set corresponding to the BIOS / OS code and the reliable version certificate corresponding to digital signature verification certificate 2 using private key 1, then in S4, the ESBC(L2) running process uses digital signature verification certificate 1 and digital signature 1 to verify the BIOS / OS code and digital signature verification certificate 2. If the verification of both the BIOS / OS code and digital signature verification certificate 2 is successful, S5 is executed; otherwise, the boot process fails.

[0133] The above-mentioned S1 corresponds to the execution process of steps S501-S503, and S2-S5 correspond to the optional steps S504-S507 after S503, respectively. Through the above process, the trust chain can be sequentially passed from the boot information (BSBC) and the first verification information to the first instruction set (ESBC(L1)), the secondary public key, the second instruction set (ESBC(L2)), the boot instruction set (BIOS / OS code), and the application software instruction set (APP code), realizing a secure boot from the application software level and ensuring the security of the device.

[0134] It should be noted that the aforementioned BIOS / OS file can be an OS file, or a BIOS / OS file that includes both BIOS and OS files. When the BIOS / OS file is an OS file, ESBC(L1) and / or ESBC(L2) can perform BIOS functions, such as power-on self-test (POST), initialization, and booting the operating system. When the BIOS / OS file includes both BIOS and OS files, after the ESBC(L2) process verifies the BIOS / OS code, the BIOS can perform a self-test and initialization before booting the OS.

[0135] Optionally, the first memory may also store the validity information of the secondary public key. The method may further include verifying the secondary public key based on the validity information of the secondary public key. If the verification of the secondary public key based on the validity information of the secondary public key is successful, and the verification of the secondary public key using the first public key and the first signature information in S504 is successful, then S505 is executed.

[0136] In one implementation, the validity information of the secondary public key includes derived key revocation information. The first public key may have multiple periodically updated derived public keys. Whenever a new derived public key is generated and put into use, the old derived public key will be revoked. The derived key revocation information can indicate the revoked old derived public key and / or the new valid derived public key, and thus the validity of the secondary public key can be determined based on the derived key revocation information.

[0137] For example, the validity of a secondary public key can be indicated by the value of eight bits. These eight bits indicate the validity of eight derived public keys. When a bit is "0", it means the corresponding derived public key is valid; when a bit is "1", it means the corresponding derived public key has been revoked. In practice, all eight bits are defaulted to "0". After the first derived public key is generated and used for a period of time, an updated second derived public key is generated, and the first derived public key is revoked. At this time, the bit indicating the first derived public key can be set to "1". After the second derived public key is used for a period of time, an updated third derived public key is generated, and the second derived public key is revoked. At this time, the bit indicating the second derived public key can be set to "1". In this way, when the derived public keys are updated periodically, the old derived public keys are revoked, maintaining the validity of the new derived public keys.

[0138] Optionally, the first memory may store two or more verification information and a first indication information, while the second memory stores two or more root public keys. The verification information in the first memory may correspond one-to-one with the root public keys in the second memory. The first indication information may instruct the boot engine to select the first verification information from the two or more verification information stored in the first memory for verifying the first instruction set. Therefore, the boot engine can, based on the first indication information, retrieve the first verification information from the two or more verification information in the first memory, retrieve the first root public key corresponding to the first verification information from the second memory, and then use the first verification information to verify the first instruction set and the first public key. If the verification is successful, the execution of the first instruction set is triggered.

[0139] In one alternative approach, the first indication information is represented by the value of a first indication bit in the first memory, where the first indication bit is a bit in the first memory. For example, the first memory may store two parity information entries, and the first indication information can be represented by the value of one bit, which can be "0" or "1", indicating the two parity information entries respectively. Alternatively, the first memory may store three parity information entries, and the first indication information can be represented by the values ​​of two bits, which can be "00", "10", or "11", indicating the three parity information entries respectively.

[0140] Further optionally, the first indication information may indicate two or more verification information for verifying the first instruction set. That is, in addition to indicating the first verification information, it may also indicate the second verification information, which may be one or more.

[0141] For example, the first memory can store four verification messages. The first indication message can be represented by the values ​​of four bits, each corresponding to one of the four verification messages. When the value of the bit corresponding to the verification message is "1", it indicates that the verification message is indicated by the first indication message. For example, when the value of these four bits is "1100", it means that one of the verification messages corresponding to the first two bits is the first verification message, and the other is the second verification message. Furthermore, the startup engine uses the first verification message to verify the first instruction set and the first public key, and uses the second verification message to verify the first instruction set and the second public key. The second public key is the root public key corresponding to the second verification message. If both the verification using the first verification message and the verification using the second verification message pass, the execution of the first instruction set is triggered.

[0142] This method of using the first instruction information to indicate the first verification information and the second verification information can realize a multi-signature secure boot mechanism. The multi-signature secure boot mechanism will be introduced later and will not be described in detail here.

[0143] The method described above, which uses the first instruction information to indicate verification information, can be applied in various scenarios. For example, in the first scenario, multiple verification information entries can be pre-stored in the first memory. These multiple verification information entries correspond to different verification parties. When using the system, the user can indicate the verification information to be verified according to their needs through the first instruction information, offering high flexibility. In another scenario, when the first instruction set and / or the first public key need to be updated, such as if it becomes invalid or insecure, the first instruction set and / or the first public key can be updated, and the new first verification information can be determined based on the updated first instruction set and the first public key. It should be understood that if the first instruction set is updated but the first public key is not, the new first verification information is determined based on the updated first instruction set and the unupdated first public key; if the first instruction set is not updated but the first public key is updated, the new first verification information is determined based on the unupdated first instruction set and the updated first public key; if both the first instruction set and the first public key are updated, the new first verification information is determined based on the updated first instruction set and the updated first public key.

[0144] Figure 7 For an example of the second scenario, see Figure 7 , Figure 7 This application provides a schematic diagram of updating a first public key, as shown in the embodiment. Figure 7As shown, the first memory before the update stores the first verification information, and the second memory stores the first public key corresponding to the first verification information. The first indicator bit in the first memory is set to "0", which is used to indicate that when the startup engine is powered on, it verifies the first instruction set and the first public key according to the first verification information.

[0145] If the first public key is updated using the second public key, the second public key is stored in the second memory, and new verification information is determined according to the first instruction set and the second public key to obtain the second verification information. The second verification information is stored in the first memory, and the value of the first indicator bit is modified to "1" to instruct the start engine to verify the first instruction set and the second public key according to the second verification information when it is powered on.

[0146] like Figure 7 The trust chain continues from the first instruction set downwards. The second memory before the update can store the second public key 1 and its first private key signature, as well as the second instruction set and its second private key 1 signature. The value "0" of the first indicator bit can also indicate verification of the second public key 1 based on the first public key. If the second public key 1 is verified successfully, the second instruction set and digital signature verification certificate 1 are verified using the second public key 1 and the second private key 1 signature. If both the second instruction set and digital signature verification certificate 1 are verified successfully, the operating system and digital signature verification certificate 2 are verified using digital signature verification certificate 1 and digital signature 1. If the operating system and digital signature verification certificate 2 are verified successfully, the application software is verified using digital signature verification certificate 2 and digital signature 2. If the application software is verified successfully, the application software is started.

[0147] After updating the first public key using the second public key, the second public key 2 and its second private key signature are stored in the second memory. The second private key signature is a signature of the reliable version key corresponding to the second public key 2 using the second private key, where the second private key and the second public key belong to the same key pair. Then, the reliable version instruction set of the second instruction set is signed using the private key corresponding to the second public key 2, resulting in the second private key 2 signature, which is stored in the second memory. Furthermore, a value of "1" in the first indicator bit indicates that the second public key 2 is verified based on the second public key and the second private key signature. If the verification is successful, the second instruction set and digital signature verification certificate 3 are verified using the second public key 2 and the second private key 2 signature. If both the second instruction set and digital signature verification certificate 3 are verified successfully, the operating system's digital signature certificate 3 is verified using the digital signature verification certificate 3 and the digital signature 3. If the operating system and digital signature verification certificate 3 are verified successfully, the application software is verified using the digital signature verification certificate 4 and the digital signature 4. If the application software is verified successfully, the application software is launched.

[0148] It should be noted that the aforementioned digital signature verification certificate 3 can be the same as or different from digital signature verification certificate 1, and digital signature certificate 4 can be the same as or different from digital signature verification certificate 2. Optionally, if digital signature verification certificate 3 is the same as digital signature verification certificate 1, then digital signature certificate 3 and digital signature 1 are the same; if digital signature verification certificate 3 is different from digital signature verification certificate 1, then digital signature 3 and digital signature 1 are different. If digital signature verification certificate 4 is the same as digital signature verification certificate 2, then digital signature 4 and digital signature 2 are the same; if digital signature verification certificate 4 is different from digital signature verification certificate 2, then digital signature 4 and digital signature 2 are different.

[0149] The above process completes the update and upgrade of the first public key. The update and upgrade of the first instruction set can also be carried out by referring to the above process, and will not be repeated here.

[0150] Optionally, the first memory may also store packet information corresponding to the secondary public key. The packet information is used to indicate the application device category of the chip. For example, the application device category of the chip can be one of the device categories such as router, switch, repeater, etc. In other words, the packet information indicates that the chip can be used in a type of device.

[0151] The first signature information of the secondary public key is obtained by jointly signing the reliable version of the secondary public key (which can be an unaltered public key immediately after its derivation) and the block information of the secondary public key. Therefore, in S504, during the verification of the secondary public key, the block information of the secondary public key in the first memory is obtained. Based on the block information and the secondary public key, a third hash value is determined. The first signature information is then decrypted using the first public key to obtain a fourth hash value. If the third and fourth hash values ​​are the same, the execution of the second instruction set is triggered.

[0152] In practical applications, some device manufacturers derive different secondary public keys for different types of devices. If someone maliciously copies the secondary public key and its first signature information of a certain type of device to other types of devices, the signing mechanism of the aforementioned secondary public key signature will prevent other types of devices from passing the verification of the secondary public key during the startup process based on their own grouping information and the first signature information of the secondary public key. This avoids malicious startup of other types of devices caused by such malicious behavior.

[0153] For example, a device manufacturer derives secondary public keys A and B from the first public key. Secondary public key A is used for secure booting of the router, and secondary public key B is used for secure booting of the switch. Under normal use, the router can use secondary public key A to complete secure booting through steps S501-S507, and the switch can use secondary public key B to complete secure booting through steps S501-S507. However, in abnormal situations, such as when the router's secondary private key A (which belongs to the same key pair as secondary public key A) is maliciously leaked to others, while the secondary private key B (which belongs to the same key pair as secondary public key B) remains unleashed.

[0154] At this point, someone maliciously obtaining the secondary private key A can only maliciously modify and start the switch's secondary instruction set. If they modify the router's secondary instruction set and sign it with the secondary private key A, copying the router's secondary public key A and its first signature information to the switch, attempting to start the switch using the secondary public key A, then, because the first signature information of the secondary public key A is obtained by signing the secondary public key A and the router's packet information during the switch's verification of the secondary public key B, but the switch stores the switch's own packet information, the verification of the secondary public key A in the switch will fail. This malicious method cannot start the switch, thus ensuring the switch's security.

[0155] The above describes the single-signature secure boot mechanism in this method for the device. This method can also support a multi-signature secure boot mechanism for the device. It should be understood that when the device boots the instruction set level by level based on the multi-signature secure boot mechanism, the instruction set at any level can be signed by multiple signature information (these multiple signature information are signed by different private keys). During the verification process, each signature information needs to be used to independently verify the instruction set. If all verifications pass, the execution of the instruction set is triggered. If any signature information fails to verify the instruction set, the device boot fails and the boot process is interrupted.

[0156] Here, we will take the dual-signature secure boot mechanism as an example for a detailed introduction. Please refer to [link / reference]. Figure 8 , Figure 8 This is a schematic diagram of a dual-signature secure boot method provided in an embodiment of this application, such as... Figure 8 As shown, the second memory can store the first public key and the second public key. Correspondingly, the first memory can store the first verification information corresponding to the first public key and the second verification information corresponding to the second public key. Both the first and second public keys can be used as the basis for the first instruction set to verify the second instruction set. If the verification of the second instruction set using both the first and second public keys passes, the first instruction set triggers the execution of the second instruction set. It should be understood that... Figure 8 The image shows the case where the second memory is external to the chip; alternatively, the second memory can also be internal to the chip.

[0157] like Figure 8 As shown, specifically, based on the startup information, the first public key and the second public key can be retrieved from the first memory, the first instruction set can be retrieved from the second memory, and operations 1A and 1B can be executed:

[0158] 1A. Verify the first instruction set and the first public key using the first verification information.

[0159] 1B. Use the second verification information to verify the first instruction set and the second public key.

[0160] If the verifications in 1A and 1B both pass, the engine is started to trigger the execution of the first instruction set.

[0161] After the first instruction set is executed, its execution process can verify the reliability of the second instruction set. Optionally, such as... Figure 8 As shown, the signature information for the second instruction set can be two: a signature for secondary private key 1 corresponding to secondary public key 1, and a signature for secondary private key 2 corresponding to secondary public key 2. Secondary public key 1 is a derived public key corresponding to the first public key, and secondary public key 2 is a derived public key corresponding to the second public key. The verification of the reliability of the second instruction set by the execution process of the first instruction set can include operations 2A and 2B:

[0162] 2A. The execution process of the first instruction set uses the first public key and the first private key to sign and verify the second public key 1.

[0163] 2B. The execution process of the first instruction set uses the second public key and the second private key to sign and verify the secondary public key 2.

[0164] If the verifications in 2A and 2B both pass, then perform the operations in 3A and 3B:

[0165] 3A. The execution process of the first instruction set uses the second-level public key 1 and the second-level private key 1 to sign and verify the second instruction set.

[0166] 3B. The execution process of the first instruction set uses the second-level public key 2 and the second-level private key 2 to sign and verify the second instruction set.

[0167] In one optional method, the signature of the secondary private key 1 can also be used to verify the signature certificate 1, and the signature of the secondary private key 2 can also be used to verify the digital signature verification certificate 2. In 3A, the signature of the secondary public key 1 and the secondary private key 1 can be used to verify the second instruction set and the digital signature verification certificate 1. In 3B, the signature of the secondary public key 2 and the secondary private key 2 can be used to verify the second instruction set and the digital signature verification certificate 2.

[0168] If the verifications in 3A and 3B pass, the execution of the second instruction set is triggered. The execution process of the second instruction set can verify the reliability of the operating system. Optional, such as... Figure 8 As shown, the operating system can have two signature information: digital signature 1 corresponding to digital signature verification certificate 1, and digital signature 2 corresponding to digital signature verification certificate 2. The verification of the operating system by the execution process of the second instruction set can include operations 4A and 4B:

[0169] 4A. The second instruction set execution process uses digital signature verification certificate 1 and digital signature 1 to verify the operating system.

[0170] 4B. The second instruction set execution process uses digital signature verification certificate 2 and digital signature 2 to verify the operating system.

[0171] In one optional method, digital signature 1 can also be used to verify digital signature verification certificate 3, and digital signature 2 can also be used to verify digital signature verification certificate 4. In 4A, digital signature verification certificate 1 and digital signature 1 can be used to verify the operating system and digital signature verification certificate 3. In 4B, digital signature verification certificate 2 and digital signature 2 can be used to verify the operating system and digital signature verification certificate 4.

[0172] If both 4A and 4B verifications pass, the operating system is triggered to run, allowing it to verify the application software's reliability. Optional, such as... Figure 8 As shown, application software can have two signature information: digital signature 3 corresponding to digital signature verification certificate 3, and digital signature 4 corresponding to digital signature verification certificate 4. The operating system's verification of application software can include operations 5A and 5B:

[0173] 5A. The operating system uses digital signature verification certificate 3 to verify digital signature 3.

[0174] 5B. The operating system uses digital signature verification certificate 4 to verify digital signature 4.

[0175] If both 5A and 5B verifications pass, the application software will be triggered to run.

[0176] It should be noted that digital signature verification certificate 1 and digital signature verification certificate 3 can be the same or different; digital signature verification certificate 2 and digital signature verification certificate 4 can be the same or different. The operations in 1A and 1B can be executed simultaneously or sequentially, and the order of 1A and 1B is not limited; the operations in 2A and 2B can be executed simultaneously or sequentially, and the order of 2A and 2B is not limited; the operations in 3A and 3B can be executed simultaneously or sequentially, and the order of 3A and 3B is not limited; the operations in 4A and 4B can be executed simultaneously or sequentially, and the order of 4A and 4B is not limited; the operations in 5A and 5B can be executed simultaneously or sequentially, and the order of 5A and 5B is not limited.

[0177] It should be understood that the multi-signature secure boot mechanism can be executed either as the device's default boot method when the first and second verification information are stored in the first memory, or as a boot method selected by indication information in the first memory. For example, the first indication information could indicate the first and second verification information, thus implementing the dual-signature mechanism. Other indication information could also be used; this is not limited here. Through the implementation of the multi-signature secure boot mechanism, dual-signature verification is performed on the first instruction set, the second instruction set, the operating system, and the application software. If any one of these components is unilaterally tampered with, the secure boot process will be interrupted, thereby improving the device's security level.

[0178] The secure boot method provided in this embodiment embeds the verification algorithm for the first instruction set into the boot information of the boot engine, and embeds the verification benchmark for the first instruction set into the first verification information in the first memory. The reliability of the first instruction set can be determined by the embedded boot information and the embedded first verification information. The first instruction set and its subordinate instruction sets can be stored in a readable and writable second memory, so that the first instruction set, the first public key, or the subordinate instruction sets of the first instruction set can be modified or rewritten.

[0179] For example, in one scenario, if the number of times the first memory is written has not reached the maximum value, the first instruction set or the first public key can be modified, the first verification information of the modified first instruction set and the first public key can be redefined, and the new first verification information can be written into the first memory.

[0180] For example, in another scenario, the lower-level instruction set of the first instruction set can be modified, such as the second instruction set. After modifying the second instruction set and re-signing it, the original first instruction set can be run during secure boot. The modified second instruction set can be verified by the running process of the first instruction set and the new signature of the second instruction set. If the verification is successful, the second instruction set will be triggered to run. Therefore, the legitimate modification of the second instruction set does not affect the secure boot of the device system, and there is no need to modify the design and structure of the chip due to the algorithm upgrade.

[0181] For example, in another scenario, if the equipment manufacturer discovers that the algorithm in the first instruction set of the previously produced chip is defective and needs to upgrade the first instruction set, the equipment manufacturer can write the upgraded first instruction set into the second memory during the subsequent chip production process, and solidify the new first verification information determined according to the upgraded first instruction set and the first public key into the first memory, thus realizing the upgrade of the chip without changing the chip hardware structure.

[0182] The method in this application embodiment is more flexible than the approach of embedding all verification algorithms and benchmarks for secure system startup into the chip. It not only ensures secure device startup but also shortens the cycle and cost of upgrading the chip due to changes in the instruction set or public key used in secure startup.

[0183] This application also provides a secure boot device, which can be a communication device, an internet device, or an IoT device, or it can be a part of the device (such as a circuit or a chip). This secure boot device can improve the security of device system startup. See also... Figure 9 , Figure 9 This is a schematic diagram of the structure of a safety start device provided in an embodiment of this application, as shown below. Figure 9 As shown, the safety start device 90 may include at least a first memory 901 and a start engine 902.

[0184] The first memory 901 is used to store the first verification information.

[0185] The boot engine 902 is used to store boot information and also to: obtain first verification information from the first memory based on the boot information, obtain the first instruction set from the second memory, verify the first instruction set and the first root public key using the first verification information, and trigger the execution of the first instruction set if the verification passes.

[0186] The first public key serves as the basis for verifying the second instruction set through the first instruction set. The first instruction set is also used to trigger the execution of the second instruction set after the verification of the second instruction set is successful. The second instruction set is used to boot the operating system.

[0187] The first memory 901 is a one-time programmable memory.

[0188] The second memory is a read-write memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD), or any combination thereof. Optionally, the second memory can be internal to the secure boot device 90 or external to the secure boot device 90.

[0189] The first memory 901 and the boot engine 902 are interconnected, for example, via a bus 904. The bus 904 can be a PCI bus or an EISA bus, etc. The bus 904 can be divided into an address bus, a data bus, and a control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0190] Optionally, the safety start device 90 also includes a communication interface 903, which is used to communicate with other devices or other equipment. For example, when the second memory is an external memory of the safety start device 90, the first instruction set can be obtained from the second memory through the communication interface 903.

[0191] Optionally, the startup information includes a third instruction set, which is used to instruct the first verification information to verify the first instruction set and the first root public key, and to run the first instruction set if the verification is successful.

[0192] The boot engine 902 may include a third memory and a first processor. The third memory is used to store a third instruction set. The first processor is used to run the third instruction set.

[0193] The first processor can be a central processing unit (CPU), and the third memory can be a read-only memory (ROM), such as a boot ROM.

[0194] In this optional method, the internal structure of the starting engine 902 can be found in [reference needed]. Figure 3 The internal structure of the startup engine 30 in the corresponding architecture and its corresponding description will not be elaborated here.

[0195] Optionally, the startup engine 902 may include hardware circuitry, and the startup information includes logic information embedded in the hardware circuitry. The hardware circuitry is used to verify the first instruction set and the first public key using the first verification information based on the logic information, and to trigger the second processor to run the first instruction set if the verification of the first instruction set and the first public key passes.

[0196] The hardware circuit can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The second processor can be a central processing unit (CPU), which can be an internal processor of the safety start device 90 or an external processor.

[0197] In this optional method, the internal structure of the starting engine 902 can be found in [reference needed]. Figure 4 The internal structure of the startup engine 30 in the corresponding architecture and its corresponding description will not be elaborated here.

[0198] Optionally, the second memory stores a second public key, and the first memory stores second verification information. The second verification information is used to verify the first instruction set and the second public key. Specifically, the startup engine 902 can be used to trigger the execution of the first instruction set if the verification of the first instruction set, the first public key, and the second public key all pass. The second public key is the basis for verifying the second instruction set using the first instruction set. Specifically, the first instruction set is used to trigger the execution of the second instruction set if both the verification of the second instruction set using the first public key and the verification of the second instruction set using the second public key pass.

[0199] Optionally, the first memory 901 stores two or more verification information and also stores first indication information. The startup engine 902 is specifically used to: obtain the first verification information from the two or more verification information according to the first indication information, verify the first instruction set and the first public key corresponding to the first verification information using the first verification information, and trigger the execution of the first instruction set if the verification is successful.

[0200] It is understood that the safe start device 90 in the embodiments of this application can achieve... Figure 5 The steps in the corresponding embodiments. Regarding... Figure 9 For details on the specific implementation methods and corresponding beneficial effects of the functional components included in the safety start device 90, please refer to the aforementioned... Figure 5 The specific details of the corresponding embodiments will not be repeated here.

[0201] This application also provides a storage medium that can be used to store... Figure 9 The instructions used by the secure boot device 90 in the illustrated embodiment include programs designed for executing the secure boot device 90 in the above embodiments. The storage medium includes, but is not limited to, flash memory, hard disk, and solid-state drive.

[0202] This application also provides a program product that, when run by a secure boot device, can execute the above-mentioned... Figure 9 The embodiment shown illustrates a safe start method designed for the safe start device 90.

[0203] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. 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 includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0204] Furthermore, in the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, in the description of the embodiments of this application, "multiple" refers to two or more.

[0205] Those skilled in the art will understand that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

Claims

1. A chip-based secure boot method, characterized in that, The chip includes a first memory and a boot engine, wherein boot information is embedded in the boot engine, and the method includes: The startup engine obtains first verification information from the first memory according to the startup information. The first memory is a one-time programmable memory. The first verification information includes a first hash value, which is calculated by a merging algorithm and a first hash algorithm. The startup engine retrieves a first instruction set from a second memory, which is a readable and writable memory; The boot engine calculates a first merge result of the first instruction set and the first public key using the merging algorithm; the boot engine calculates a second hash value of the first merge result using the first hash algorithm; the boot engine triggers the execution of the first instruction set if the second hash value is the same as the first hash value; the first public key is the root public key of the device's security authenticator, and the first public key is used as the basis for verifying the second instruction set using the first instruction set; the first instruction set is also used to trigger the execution of the second instruction set after the verification of the second instruction set is successful; the second instruction set is used to boot the device's operating system.

2. The method according to claim 1, characterized in that, The startup engine includes a third memory, and the startup information includes a third instruction set permanently stored in the third memory.

3. The method according to claim 1, characterized in that, The startup engine includes hardware circuitry, and the startup information includes logic information embedded in the hardware circuitry.

4. The method according to any one of claims 1-3, characterized in that, The first memory stores second verification information, which is used to verify the first instruction set and the second public key. The operation of the startup engine triggering the execution of the first instruction set is performed when the verification of the first instruction set, the first public key, and the second public key is all successful; The second public key serves as the basis for verifying the second instruction set using the first instruction set; specifically, the first instruction set is used to trigger the execution of the second instruction set when the verification of the second instruction set using the first public key and the verification of the second instruction set using the second public key both pass.

5. The method according to any one of claims 1-3, characterized in that, The first memory stores two or more verification information; the first memory also stores first indication information; The first indication information is used to indicate the first verification information; The startup engine obtains the first verification information from the first memory, including: The startup engine obtains the first verification information from the two or more verification information according to the first instruction information; The startup engine uses the first verification information to verify the first instruction set and the first public key, and triggers the execution of the first instruction set if the verification is successful, including: The startup engine uses the first verification information to verify the first instruction set and the first public key corresponding to the first verification information. If the verification is successful, the engine triggers the execution of the first instruction set.

6. The method according to any one of claims 1-3, characterized in that, The second instruction set is specifically used to verify the boot instruction set of the operating system; and to trigger the execution of the boot instruction set to perform the verification of the operating system if the verification of the boot instruction set is successful; and to start the operating system if the verification of the operating system is successful.

7. The method according to any one of claims 1-3, characterized in that, After the startup engine triggers the execution of the first instruction set when the second hash value is the same as the first hash value, it further includes: The startup engine runs the first instruction set and retrieves the first signature information of the secondary public key from the second memory. The secondary public key is a derived public key corresponding to the first root public key. The startup engine uses the first signature information and the first root public key to verify the second-level public key; If the verification of the secondary public key is successful, the startup engine retrieves the second instruction set and the second signature information of the second instruction set from the second memory. The startup engine uses the second signature information and the second-level public key to verify the second instruction set. If the verification is successful, it triggers the execution of the second instruction set.

8. The method according to claim 7, characterized in that, The startup engine uses the first signature information and the first root public key to verify the secondary public key. If the verification is successful, triggering the execution of the second instruction set includes: Obtain the packet information corresponding to the secondary public key from the first memory; the packet information is used to indicate the application device category of the chip. The third hash value is determined based on the grouping information and the secondary public key; The first signature information is decrypted using the first public key to obtain the fourth hash value; If the third hash value is equal to the fourth hash value, the execution of the second instruction set is triggered.

9. A safety start device, characterized in that, Includes the first memory and the boot engine, wherein: The first memory is used to store first verification information. The first memory is a one-time programmable memory. The first verification information includes a first hash value, which is calculated by a merging algorithm and a first hash algorithm. The startup engine is used to permanently store startup information and also for: According to the startup information, the first verification information is obtained from the first memory, the first instruction set is obtained from the second memory, the first merge result of the first instruction set and the first root public key is calculated by the merging algorithm, the second hash value of the first merge result is calculated by the first hash algorithm, and the first instruction set is triggered to run if the second hash value is the same as the first hash value. The first public key is the root public key of the device's security verification party. Wherein, the second memory is a readable and writable memory; the first public key is the basis for verifying the second instruction set through the first instruction set, and the first instruction set is also used to trigger the execution of the second instruction set after the verification of the second instruction set is successful; the second instruction set is used to guide the operating system of the device to start.

10. The apparatus according to claim 9, characterized in that, The startup information includes a third instruction set, which is used to instruct the first instruction set and the first root public key to be verified using the first verification information, and to run the first instruction set if the verification passes. The startup engine includes a third memory and a first processor; The third memory is used to store the third instruction set, and the third memory is a read-only memory; The first processor is used to run the third instruction set.

11. The apparatus according to claim 9, characterized in that, The startup engine includes hardware circuitry, and the startup information includes logic information embedded in the hardware circuitry. The hardware circuit is used to verify the first instruction set and the first public key using the first verification information according to the logic information, and to trigger the second processor to run the first instruction set if the verification of the first instruction set and the first public key passes.

12. The apparatus according to any one of claims 9-11, characterized in that, The first memory is used to store the second verification information, which is used to verify the first instruction set and the second public key. The startup engine is specifically used to trigger the execution of the first instruction set when the verification of the first instruction set, the first public key, and the second public key all pass. The second public key serves as the basis for verifying the second instruction set using the first instruction set; specifically, the first instruction set is used to trigger the execution of the second instruction set when the verification of the second instruction set using the first public key and the verification of the second instruction set using the second public key both pass.

13. The apparatus according to any one of claims 9-11, characterized in that, The first memory stores two or more verification information; the first memory is also used to store first indication information; The startup engine is specifically used for: According to the first instruction information, the first verification information is obtained from the two or more verification information, and the first instruction set and the first root public key corresponding to the first verification information are verified using the first verification information. If the verification is successful, the execution of the first instruction set is triggered.

14. A storage medium, characterized in that, The storage medium stores instructions that, when executed on a processor, cause the processor to perform the chip-based secure boot method according to any one of claims 1-8.

Images