Secure boot method and apparatus for system on chip, and electronic device and storage medium

Abstract

Provided in the present application are a secure boot method and apparatus for a system on chip, and an electronic device and a storage medium. The method provided in the present application comprises: acquiring a certificate, encrypted firmware and a first public key hash value on the basis of a configuration descriptor file and firmware; acquiring public key information and a public key hash type to acquire a second public key hash value; if the first public key hash value is the same as the second public key hash value, using the public key information to perform a decryption operation on signature information, so as to obtain a first certificate hash value, and acquiring a second certificate hash value on the basis of the content of the certificate other than the signature information; and if the first certificate hash value is the same as the second certificate hash value, reading the corresponding encrypted firmware from a firmware storage address on the basis of a firmware loading index, decrypting the corresponding encrypted firmware on the basis of a firmware encryption type, verifying decrypted firmware on the basis of a firmware verification type, and running the decrypted firmware. The method of the present application can avoid the problem of system permissions being illegitimately acquired due to fault injection.

Description

System on chip secure startup method, device, electronic device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on October 26, 2023, with application number 202311404844.8 and invention name “A method, device, electronic device and storage medium for secure booting of a system on a chip”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of system security technology, and in particular to a method, device, electronic device, and storage medium for securely booting a system on a chip. Background Art

[0004] With the increasing prevalence of intelligent and networked electronic devices, they are widely used in our daily lives, and network security issues are becoming increasingly serious. Without relevant security protections, applications in smart terminals are vulnerable to tampering and attacks. To ensure the secure operation of smart terminals, it is necessary to ensure the security and controllability of the smart terminal system from the source. Therefore, reliable system-on-chip secure boot is crucial. Existing secure boot solutions cannot protect against fault injection. Fault injection involves precisely injecting faults through electromagnetic interference, voltage surges, or clock glitches, causing program execution errors and skipping decryption and signature verification. Fault injection can also disrupt the secure boot chain of trust and illegally gain system permissions.

[0005] Summary of the Invention

[0006] The purpose of this application is to provide a method, device, electronic device and storage medium for secure booting of a system on a chip to solve the technical problem of illegally obtaining system permissions due to fault injection in the prior art.

[0007] The technical solution of the present application is as follows, which provides a method for securely booting a system on a chip, including:

[0008] Obtain a configuration descriptor file and firmware, and obtain a certificate, encrypted firmware, and a first public key hash value based on the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address, and signature information;

[0009] Obtain the public key information and the public key hash type to obtain a second public key hash value;

[0010] If the first public key hash value is the same as the second public key hash value, decrypt the signature information using the public key information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate excluding the signature information;

[0011] If the hash value of the first certificate is the same as the hash value of the second certificate, the corresponding encrypted firmware is read from the firmware storage address according to the loaded firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run.

[0012] Furthermore, the system-on-chip secure boot method further includes:

[0013] If the first public key hash value is the same as the second public key hash value, a first tag is generated; if the first certificate hash value is the same as the second certificate hash value, a second tag is generated; after decrypting the corresponding encrypted firmware according to the firmware encryption type, a third tag is generated; after the verification is passed, a fourth tag is generated; accordingly, after the verification is passed, if the first tag, the second tag, the third tag and the fourth tag are detected, the decrypted firmware is run.

[0014] Furthermore, the system-on-chip secure boot method further includes:

[0015] Perform a boot chip self-test. If the self-test is successful, initialize the system on chip, generate a fifth tag, and then execute the steps of obtaining the configuration descriptor file and firmware. Accordingly, after the verification passes, if the first tag, the second tag, the third tag, the fourth tag, and the fifth tag are detected, run the decrypted firmware.

[0016] Furthermore, the firmware also includes extended firmware. After determining that the first certificate hash value is the same as the second certificate hash value, before decrypting the corresponding encrypted firmware according to the firmware encryption type, the extended firmware is loaded and run to generate a sixth tag; accordingly, after the verification passes, if the first tag, the second tag, the third tag, the fourth tag, the fifth tag and the sixth tag are detected, the decrypted firmware is run.

[0017] Furthermore, the content of the certificate also includes a firmware loading address and a firmware running address. Accordingly, the corresponding encrypted firmware is read from the firmware storage address according to the loaded firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run, including:

[0018] The corresponding encrypted firmware is read from the firmware storage address according to the loading firmware index, the corresponding encrypted firmware is stored according to the firmware loading address, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run at the firmware running address.

[0019] Further, obtaining a certificate, an encrypted firmware, and a first public key hash value according to the configuration descriptor file and the firmware includes:

[0020] A secure boot firmware file and a first public key hash value are generated according to the configuration descriptor file and the firmware, where the secure boot firmware file includes the certificate and the encrypted firmware.

[0021] Furthermore, after generating a secure boot firmware file and a first public key hash value according to the configuration descriptor file and the firmware, the method further includes burning the secure boot firmware file into a storage medium and burning the public key hash value into a non-secure OTP area.

[0022] Furthermore, the content of the certificate also includes version, signature type, extended firmware tag and firmware quantity.

[0023] Another technical solution of the present application is as follows: a system-on-chip secure boot device is provided, comprising a secure firmware generation module, a public key hash acquisition module, a certificate hash acquisition module, and a firmware execution module;

[0024] The secure firmware generation module is configured to obtain a configuration descriptor file and firmware, and obtain a certificate, encrypted firmware, and a first public key hash value based on the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address, and signature information;

[0025] The public key hash acquisition module is used to obtain the public key information and the public key hash type to obtain a second public key hash value;

[0026] The certificate hash acquisition module is configured to, when the first public key hash value and the second public key hash value are the same, perform a decryption operation on the signature information using the public key information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate excluding the signature information;

[0027] The firmware running module is used to read the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index when the hash value of the first certificate is the same as the hash value of the second certificate, decrypt the corresponding encrypted firmware according to the firmware encryption type to obtain the decrypted firmware, verify the decrypted firmware according to the firmware verification type, and run the decrypted firmware after the verification passes.

[0028] Another technical solution of the present application is as follows: an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program that can be executed by the processor, and when the processor executes the computer program, it implements the on-chip system secure startup method as described in any of the above technical solutions.

[0029] Another technical solution of the present application is as follows: a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the system-on-chip secure boot method as described in any of the above technical solutions is implemented.

[0030] The beneficial effects of the present application are: by obtaining a configuration descriptor file and firmware, obtaining a certificate, encrypted firmware and a first public key hash value according to the configuration descriptor file and the firmware, the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address and signature information; obtaining a second public key hash value by obtaining the public key information and the public key hash type; if the first public key hash value is the same as the second public key hash value, decrypting the signature information using the public key information to obtain a first certificate hash value, and obtaining a second certificate hash value according to the content of the certificate other than the signature information; if the first certificate hash value is the same as the second certificate hash value, reading the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index, decrypting the corresponding encrypted firmware according to the firmware encryption type to obtain the decrypted firmware, verifying the decrypted firmware according to the firmware verification type, and running the decrypted firmware after passing the verification; ensuring that the trust chain of the secure boot is not damaged, avoiding the problem of illegal acquisition of system permissions caused by fault injection, and improving the security of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG1 is a schematic diagram of a flow chart of a method for securely booting a system on a chip according to an embodiment of the present application;

[0032] FIG2 is a schematic diagram of the structure of a configuration descriptor file provided in an embodiment of the present application;

[0033] FIG3 is a flowchart of a secure firmware generation process according to an embodiment of the present application;

[0034] FIG4 is a schematic diagram of the structure of a certificate provided in an embodiment of the present application;

[0035] FIG5 is a schematic diagram of the hardware system structure including a storage medium provided in an embodiment of the present application;

[0036] FIG6 is a system block diagram of a security module provided in an embodiment of the present application;

[0037] FIG7 is a schematic diagram of the structure of the OTP provided in an embodiment of the present application;

[0038] FIG8 is a schematic structural diagram of a secure boot device for a system on a chip according to an embodiment of the present application;

[0039] FIG9 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0041] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0042] In the embodiments of this application, "at least one" refers to one or more; "a plurality" refers to two or more. In the description of this application, the terms "first," "second," "third," etc. are used only for the purpose of distinguishing descriptions and should not be understood as indicating or implying relative importance or order.

[0043] FIG1 is a flow chart of a secure boot method for a system on a chip according to an embodiment of the present application. It should be noted that the secure boot method for a system on a chip according to the present application is not limited to the flow sequence shown in FIG1 if substantially the same result is achieved. As shown in FIG1 , the secure boot method for a system on a chip mainly includes the following steps:

[0044] S101, obtaining a configuration descriptor file and firmware, and obtaining a certificate, encrypted firmware, and a first public key hash (HASH) value based on the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash (HASH) type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address, and signature information;

[0045] Among them, the content of the above-mentioned configuration descriptor file may include public key hash type, signature type, public key and private key, loaded firmware index, encryption type, firmware verification type, and the derived source of encryption KEY (key). The structural diagram of the above-mentioned configuration descriptor file is shown in Figure 2. The order of the content in the configuration descriptor file in Figure 2 can be set arbitrarily.

[0046] In some embodiments, obtaining a certificate, an encrypted firmware, and a first public key hash value according to the configuration descriptor file and the firmware includes:

[0047] A secure boot firmware file (BOOT.bin file) and a first public key hash value are generated according to the configuration descriptor file and the firmware, wherein the secure boot firmware file includes the certificate and the encrypted firmware.

[0048] In some embodiments, after generating a secure boot firmware file and a first public key hash value based on the configuration descriptor file and the firmware, it also includes burning the secure boot firmware file into a storage medium and burning the public key hash value into a non-secure OTP area.

[0049] In a specific embodiment, a secure boot firmware file and a first public key hash value are generated using a secure boot tool based on a configuration description file and the firmware to be run. The secure boot firmware file is burned into a storage medium, and the first public key hash value is burned into a non-secure OTP area. A flowchart of secure firmware generation is shown in FIG3 . In FIG3 , the firmware includes non-encrypted firmware and extended firmware. The non-encrypted firmware includes at least one, and the extended firmware may or may not exist. When the extended firmware exists, a secure boot firmware file including a certificate, encrypted firmware, extended firmware, and the first public key hash value can be generated based on the configuration description file, the non-encrypted firmware, and the extended firmware. When the extended firmware does not exist, the extended firmware does not exist in the secure boot firmware file.

[0050] In some embodiments, the content of the certificate further includes a version, a signature type, an extended firmware tag, and a firmware quantity.

[0051] The structural diagram of the above certificate is shown in Figure 4. In addition to the above content, the certificate also includes the version, signature type, firmware quantity and other contents. When extended firmware exists, the certificate also includes the extended firmware mark. The order of the certificate content in Figure 4 can be set arbitrarily.

[0052] In one specific embodiment, a schematic diagram of the hardware system structure including a storage medium is shown in FIG5 . The hardware system in FIG5 also includes a boot chip (ROOTROM), a security module, SRAM (Static Random-Access Memory), a storage interface controller, a processor, and a bus. A system block diagram of the security module is shown in FIG6 , which includes a bus, a hash engine, a symmetric encryption engine, a key ladder (a hardware module for generating symmetric encryption keys), an asymmetric encryption engine, an OTP interface, a rights management module, and a secure OTP area and a non-secure OTP area connected to the OTP interface. The source of the encryption key can also be burned into the secure OTP area. In FIG6 , the rights management module can be used to divide the OTP (One Time Programmable) space into two areas with different access rights: a secure OTP area and a non-secure OTP area. The former has a higher security level. During the R&D phase, both areas are readable and writable. During the production phase, the contents of the secure area can only be accessed and used by modules within the security engine. This effectively protects the source of the symmetric encryption key and ensures system security. During application, the KEY Ladder processes the derived source of the encryption key and restores it to the encrypted key. This generates the decryption key using the user's secret key, enhancing system security. Figure 7 shows the OTP structure. The OTP consists of a secure domain (secure OTP area) and a non-secure domain (non-secure OTP area).

[0053] S102, obtaining the public key information and the public key hash type to obtain a second public key hash value;

[0054] S103: If the first public key hash value is the same as the second public key hash value, decrypt the signature information using the public key information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate excluding the signature information;

[0055] S104, if the hash value of the first certificate is the same as the hash value of the second certificate, read the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index, decrypt the corresponding encrypted firmware according to the firmware encryption type to obtain the decrypted firmware, verify the decrypted firmware according to the firmware verification type, and run the decrypted firmware after the verification passes.

[0056] In an embodiment of the present application, a configuration descriptor file and firmware are obtained, and a certificate, encrypted firmware and a first public key hash value are obtained according to the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address and signature information; the public key information and the public key hash type are obtained to obtain a second public key hash value; if the first public key hash value is the same as the second public key hash value, the signature information is decrypted using the public key information to obtain a first certificate hash value, and a second certificate hash value is obtained according to the content of the certificate other than the signature information; if the first certificate hash value is the same as the second certificate hash value, the corresponding encrypted firmware is read from the firmware storage address according to the loaded firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run; this ensures that the trust chain of the secure boot is not damaged, can avoid the problem of illegal acquisition of system permissions caused by fault injection, and improves the security of the system.

[0057] In some embodiments, the system on chip secure boot method further includes:

[0058] If the first public key hash value is the same as the second public key hash value, a first tag is generated; if the first certificate hash value is the same as the second certificate hash value, a second tag is generated; after decrypting the corresponding encrypted firmware according to the firmware encryption type, a third tag is generated; after the verification is passed, a fourth tag is generated; accordingly, after the verification is passed, if the first tag, the second tag, the third tag and the fourth tag are detected, the decrypted firmware is run.

[0059] In a specific embodiment, the content of the certificate is read from the corresponding storage medium, the public key information and the public key hash (HASH) type (public key hash calculation type) are extracted, the second public key hash value is calculated, and then it is compared with the first public key hash value read from the non-secure OTP area. If the comparison fails, the exception handling process is entered. If the comparison is successful, the label B is set, that is, the first label is generated.

[0060] Extract the certificate information, i.e., the content of the certificate, and determine the asymmetric algorithm type. Use the public key information to verify the certificate. Specifically, use the public key information and the asymmetric algorithm type to decrypt the signature information of the certificate to obtain a first certificate hash value (decrypted hash value) M. Perform a hash calculation on the content of the certificate (excluding the signature information) to obtain a second certificate hash value N. The hash algorithm used for the hash calculation is the same as the hash algorithm used to generate the signature information. If M and N are different, enter the exception handling process. Otherwise, set the label C, that is, generate the second label. If the first public key hash value does not exist in the non-secure OTP area, the exception handling process is also entered.

[0061] It should be noted that when generating signature information, the signature information is obtained based on the content other than the signature information in the certificate and the private key, and then during public key hash verification, the signature information of the above certificate is decrypted using the public key information and the asymmetric algorithm type to obtain the first certificate hash value M, and the content other than the signature information in the certificate is hashed to obtain the second certificate hash value N.

[0062] In a specific embodiment, information such as the firmware verification type, firmware encryption type, loaded firmware index, and firmware storage address is obtained from the certificate; firmware information is read from the firmware storage address according to the loaded firmware index, and then the firmware is decrypted based on the firmware encryption type, and label E is set, that is, a third label is generated, and then the firmware is verified according to the firmware verification type. If the verification fails, the exception handling process is entered. If the verification succeeds, label F is set, that is, a fourth label is generated, and it is detected whether the first label, the second label, the third label, and the fourth label exist, that is, whether the label setting of the key process node of the secure startup is correct. If it is an error, the exception handling process is entered. If it is correct, the process jumps to the firmware running address to execute the firmware, and before jumping to the firmware running address, the system's access to the boot chip (ROOTROM) space is closed.

[0063] In some embodiments, the system on chip secure boot method further includes:

[0064] Perform a boot chip self-test. If the self-test is successful, initialize the system on chip, generate a fifth tag, and then execute the steps of obtaining the configuration descriptor file and firmware. Accordingly, after the verification passes, if the first tag, the second tag, the third tag, the fourth tag, and the fifth tag are detected, run the decrypted firmware.

[0065] In a specific embodiment, after the system is powered on, a boot chip self-test can be performed. If the self-test fails, the system will not start. If the self-test succeeds, relevant system configurations are performed, that is, the system is initialized and label A is set, that is, the fifth label is generated. Accordingly, after the verification is passed, it is determined whether the first label, the second label, the third label, the fourth label and the fifth label are detected. If so, the decrypted firmware is run.

[0066] In some embodiments, the firmware also includes extended firmware. After determining that the first certificate hash value is the same as the second certificate hash value, the extended firmware is loaded and run before decrypting the corresponding encrypted firmware according to the firmware encryption type to generate a sixth tag; accordingly, after the verification passes, if the first tag, the second tag, the third tag, the fourth tag, the fifth tag and the sixth tag are detected, the decrypted firmware is run.

[0067] In a specific embodiment, if the hash value of the first certificate is the same as the hash value of the second certificate, it can be determined that the hash value of the first certificate is the same as the hash value of the second certificate; the firmware also includes extended firmware, and the extended firmware information also exists in the certificate. The extended firmware information is obtained from the certificate, the extended firmware is loaded and run, and the tag D is set, that is, the sixth tag is generated. Accordingly, after the verification is passed, it is determined whether the first tag, the second tag, the third tag, the fourth tag, the fifth tag and the sixth tag are detected. If so, the decrypted firmware is run.

[0068] In some embodiments, the content of the certificate also includes a firmware loading address and a firmware running address. Accordingly, the corresponding encrypted firmware is read from the firmware storage address according to the loaded firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run, including:

[0069] The corresponding encrypted firmware is read from the firmware storage address according to the loading firmware index, the corresponding encrypted firmware is stored according to the firmware loading address, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run at the firmware running address.

[0070] In a specific embodiment, information such as the firmware quantity, firmware loading address, and firmware running address is also obtained from the certificate, and the encrypted firmware to be read can be determined based on the loaded firmware index.

[0071] The embodiment of the present application provides a method for securely booting a system on a chip, which obtains a configuration descriptor file and firmware, obtains a certificate, encrypted firmware and a first public key hash value according to the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address and signature information; obtains the public key information and the public key hash type to obtain a second public key hash value; if the first public key hash value is the same as the second public key hash value, decrypts the signature information using the public key information to obtain a first certificate Hash value, obtain the second certificate hash value according to the content of the certificate except the signature information; if the first certificate hash value is the same as the second certificate hash value, read the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index, decrypt the corresponding encrypted firmware according to the firmware encryption type, obtain the decrypted firmware, verify the decrypted firmware according to the firmware verification type, and run the decrypted firmware after the verification passes; ensure that the trust chain of the secure boot is not damaged, avoid the problem of illegal acquisition of system permissions due to fault injection, and improve the security of the system.

[0072] Most existing secure boot solutions encrypt and sign the boot program. The public key and encryption key of the trusted root are directly stored in the OTP. During the system secure boot process, decryption and signature verification are performed to ensure the authenticity and integrity of the boot program and prevent the program from being tampered with or replaced. These solutions have the following defects: the public key length is long. For example, the SM2 algorithm public key is 512 bits, and the RSA2048 algorithm public key is 2048 bits, which takes up a lot of OTP storage space. The encryption key is directly stored, which has the risk of exposure. There is no verification and protection of the BOOTROM, which cannot prevent fault injection.

[0073] The system-on-chip secure boot method of the embodiment of the present application stores the public key hash value (first public key hash value) of the trusted root in the OTP, and relatively directly writes the public key information to the OTP, saving the storage space of the OTP and preventing its leakage; the encryption key is not directly stored, but the chip batch number, chip ID and other information are stored, and the encryption key is derived from it during operation, and the decryption key is generated by deriving the user secret key, thereby improving security; during the secure boot, the boot chip itself can be optionally checked to ensure its own integrity, so that the user can make a trade-off between performance and security at the boot time, set labels at the key process nodes of the secure boot, mark the running track, and prevent the illegal acquisition of system (system-on-chip, embedded system) permissions through fault injection; the access rights of sensitive information can be controlled through specific fields, for example, specific fields (domains) are set in the non-secure OTP to control the access rights of the secure OTP to achieve control of the access rights of sensitive information. The system-on-chip secure boot method of the embodiment of the present application supports extended firmware to execute some additional logic during the secure boot process, such as repairing boot chip problems and executing some user code logic in the startup phase.

[0074] FIG8 is a schematic diagram of the structure of a secure boot device for a system on a chip according to an embodiment of the present application. As shown in FIG8 , the secure boot device for a system on a chip 20 includes a secure firmware generation module 21, a public key hash acquisition module 22, a certificate hash acquisition module 23, and a firmware execution module 24.

[0075] The secure firmware generation module 21 is configured to obtain a configuration descriptor file and firmware, and obtain a certificate, encrypted firmware, and a first public key hash value based on the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address, and signature information;

[0076] The public key hash acquisition module 22 is configured to acquire the public key information and the public key hash type to obtain a second public key hash value;

[0077] The certificate hash acquisition module 23 is configured to, when the first public key hash value and the second public key hash value are the same, use the public key information to perform a decryption operation on the signature information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate excluding the signature information;

[0078] The firmware running module 24 is used to read the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index when the hash value of the first certificate is the same as the hash value of the second certificate, decrypt the corresponding encrypted firmware according to the firmware encryption type to obtain the decrypted firmware, verify the decrypted firmware according to the firmware verification type, and run the decrypted firmware after the verification passes.

[0079] FIG3 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. As shown in FIG3 , the electronic device 30 includes a processor 31 and a memory 32 in communication with the processor 31 .

[0080] The memory 32 stores program instructions for implementing the system on chip secure boot method according to any one of the above embodiments.

[0081] The processor 31 is configured to execute program instructions stored in the memory 32 to perform secure booting of the system on chip.

[0082] The processor 31 may also be referred to as a CPU (Central Processing Unit). The processor 31 may be an integrated circuit chip having signal processing capabilities. The processor 31 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The general-purpose processor may be a microprocessor or any conventional processor.

[0083] The memory 32 may be used to store the computer programs and / or modules. The processor 31 implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory 32 and calling data stored in the memory 32. The memory 32 may mainly include a program storage area and a data storage area. The program storage area may store an operating system, at least one application required for a function, and the like.

[0084] The memory 32 may be integrated into the processor 31 or may be provided separately from the processor 31 .

[0085] An embodiment of the present application provides a storage medium. The storage medium of the embodiment of the present application stores program instructions that can implement all the above methods. The storage medium can be non-volatile or volatile.

[0086] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0087] In addition, the functional modules in each embodiment of the present application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. The above is only an implementation method of the present application and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the content of the description and drawings of this application, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for securely booting a system on a chip, characterized in that: The steps include: Obtain a configuration descriptor file and firmware, and obtain a certificate, encrypted firmware, and a first public key hash value according to the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loading firmware index, firmware storage address, and signature information; Obtain the public key information and the public key hash type to obtain a second public key hash value; If the first public key hash value is the same as the second public key hash value, decrypt the signature information using the public key information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate except the signature information; If the hash value of the first certificate is the same as the hash value of the second certificate, the corresponding encrypted firmware is read from the firmware storage address according to the loaded firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run.

2. The method for securely booting a system on a chip according to claim 1, characterized in that: The system on chip secure boot method further includes: If the first public key hash value is the same as the second public key hash value, a first tag is generated; if the first certificate hash value is the same as the second certificate hash value, a second tag is generated; after decrypting the corresponding encrypted firmware according to the firmware encryption type, a third tag is generated; after the verification passes, a fourth tag is generated; correspondingly, after the verification passes, if the first tag, the second tag, the third tag and the fourth tag are detected, the decrypted firmware is run.

3. The method for securely booting a system on a chip according to claim 2, wherein: The system on chip secure boot method further includes: Perform a self-check on the boot chip. If the self-check is successful, initialize the system on chip, generate the fifth tag, and then execute the steps of obtaining the configuration descriptor file and firmware. Correspondingly, after the verification is passed, if When the first tag, the second tag, the third tag, the fourth tag, and the fifth tag are detected, the decrypted firmware is run.

4. The method for securely booting a system on a chip according to claim 3, characterized in that: The firmware also includes extended firmware. After determining that the first certificate hash value is the same as the second certificate hash value, before decrypting the corresponding encrypted firmware according to the firmware encryption type, the extended firmware is loaded and run to generate a sixth tag; accordingly, after the verification passes, if the first tag, the second tag, the third tag, the fourth tag, the fifth tag and the sixth tag are detected, the decrypted firmware is run.

5. The method for securely booting a system on a chip according to claim 1, characterized in that: The content of the certificate also includes a firmware loading address and a firmware running address. Accordingly, the corresponding encrypted firmware is read from the firmware storage address according to the loading firmware index, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run, including: The corresponding encrypted firmware is read from the firmware storage address according to the loading firmware index, the corresponding encrypted firmware is stored according to the firmware loading address, the corresponding encrypted firmware is decrypted according to the firmware encryption type to obtain the decrypted firmware, the decrypted firmware is verified according to the firmware verification type, and after the verification passes, the decrypted firmware is run on the firmware running address.

6. The method for securely booting a system on a chip according to claim 1, characterized in that: Obtaining a certificate, an encrypted firmware, and a first public key hash value according to the configuration descriptor file and the firmware, including: A secure boot firmware file and a first public key hash value are generated according to the configuration descriptor file and the firmware, wherein the secure boot firmware file includes the certificate and the encrypted firmware.

7. The method for securely booting a system on a chip according to claim 6, wherein: After generating a secure boot firmware file and a first public key hash value according to the configuration descriptor file and the firmware, the method further includes burning the secure boot firmware file into a storage medium and burning the first public key hash value into a non-secure OTP area.

8. The method for securely booting a system on a chip according to claim 4, characterized in that: The content of the certificate also includes version, signature type, extended firmware tag and firmware quantity.

9. A system on chip secure boot device, characterized in that: It includes a secure firmware generation module, a public key hash acquisition module, a certificate hash acquisition module and a firmware operation module; The secure firmware generation module is used to obtain a configuration descriptor file and firmware, and obtain a certificate, encrypted firmware and a first public key hash value according to the configuration descriptor file and the firmware, wherein the firmware includes non-encrypted firmware, and the content of the certificate includes public key information, public key hash type, firmware verification type, firmware encryption type, loaded firmware index, firmware storage address and signature information; The public key hash acquisition module is used to obtain the public key information and the public key hash type to obtain a second public key hash value; The certificate hash acquisition module is used to, when the first public key hash value is the same as the second public key hash value, use the public key information to perform a decryption operation on the signature information to obtain a first certificate hash value, and obtain a second certificate hash value based on the content of the certificate except the signature information; The firmware running module is used to read the corresponding encrypted firmware from the firmware storage address according to the loaded firmware index when the first certificate hash value is the same as the second certificate hash value, decrypt the corresponding encrypted firmware according to the firmware encryption type to obtain the decrypted firmware, verify the decrypted firmware according to the firmware verification type, and run the decrypted firmware after the verification passes.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable by the processor, wherein: When the processor executes the computer program, the system on chip secure boot method according to any one of claims 1 to 8 is implemented.

11. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the system on chip secure boot method as described in any one of claims 1 to 8 is implemented.

Images