CN121239409A

CN121239409A - Encryption method, verification method, encryption and decryption chip and system for firmware data

Info

Publication number: CN121239409A
Application number: CN202511657509.8A
Authority: CN
Inventors: 胡磊; 潘学功; 程生根; 刘蔚; 黄烁
Original assignee: Open Security Research Inc
Current assignee: Open Security Research Inc
Priority date: 2025-11-12
Filing date: 2025-11-12
Publication date: 2025-12-30

Abstract

This application discloses a firmware data encryption method, verification method, encryption/decryption chip, and system, applied to a first computing device. The method includes: generating random key derivation parameters, and calculating an encryption key for unencrypted firmware based on the key derivation parameters and a root key using a key derivation algorithm; encrypting the unencrypted firmware using the encryption key and initialization parameters of the encryption algorithm to obtain encrypted firmware; determining a first hash value based on the encrypted firmware and its encrypted fields; and generating a certificate chain based on the encrypted firmware, the first hash value, the encrypted fields of the encrypted firmware, and a multi-level certificate; wherein the encrypted fields of the encrypted firmware include an encryption algorithm, initialization parameters of the encryption algorithm, and key derivation parameters. This application can improve the security of firmware data.

Description

Encryption method, verification method, encryption and decryption chip and system for firmware data

Technical Field

The present application relates to the field of cryptographic security technologies, and in particular, to a firmware data encryption method, a firmware data verification method, an encryption/decryption chip, and a firmware data verification system.

Background

With the rapid development of the internet of things, mobile terminals and embedded systems, the security problem of the system starting process is increasingly prominent. For this reason, the trusted board level boot requirement specification (Trusted Board Boot Requirements, TBBR) proposed by ARM corporation is a widely adopted secure boot solution for embedded systems. TBBR is to build a digital certificate chain based on asymmetric encryption to realize the gradual verification from the root certificate to the firmware. In this scheme, the hash value of the root public key of the root certificate is burned in the one-time programmable memory (One Time Programmable, OTP) during the chip production process to serve as a tamper-proof trust origin. When the chip is started, the digital signature of each level of certificates in the certificate chain is verified step by step, and finally the hash value of the firmware is verified, so that the integrity of the loaded firmware is ensured. However, the existing TBBR scheme lacks confidentiality protection for the firmware data, which causes security risk of leakage of the firmware data, so that a method for encrypting the firmware data is needed to improve the security of the firmware data.

Disclosure of Invention

The embodiment of the application provides an encryption method, a verification method, an encryption and decryption chip and a system for firmware data, which can improve the security of the firmware data.

The technical scheme of the embodiment of the application is realized as follows:

In a first aspect, an embodiment of the present application provides a firmware data encryption method, which is applied to a first computing device, and includes generating a random key derivation parameter, calculating a key derivation parameter and a root key based on a key derivation algorithm to obtain an encryption key of an unencrypted firmware, encrypting the unencrypted firmware based on the encryption key of the unencrypted firmware and an initialization parameter of the encryption algorithm by an encryption algorithm to obtain an encrypted firmware, determining a first hash value based on the encrypted firmware and an encryption field of the encrypted firmware, and generating a certificate chain based on the encrypted firmware, the first hash value, the encryption field of the encrypted firmware and a multi-stage certificate, wherein the encryption field of the encrypted firmware includes the encryption algorithm, the initialization parameter of the encryption algorithm and the key derivation parameter.

In the embodiment of the application, the unencrypted firmware is encrypted based on the root key and the encryption parameter, and the visible Wen Gujian data in the existing TBBR certificate chain is replaced by the encrypted firmware and the encryption field of the encrypted firmware, so that the potential safety hazard of the clear text storage of the firmware in the existing TBBR scheme can be solved, the confidentiality protection of the firmware data is realized, and the firmware data can be further prevented from being threatened by security. In addition, even if an attacker acquires a certificate chain mirror image, the encrypted firmware cannot be cracked and sensitive codes and algorithm implementation in the firmware can not be read, so that the integrity and confidentiality of the firmware can be doubly protected. Moreover, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the embodiment of the application, so that the compatibility with the existing TBBR verification standard can be realized.

In some embodiments, the method further comprises sending the certificate chain to an encryption and decryption chip in a second computing device, wherein the encryption and decryption chip is used for checking and decrypting the encrypted firmware in the certificate chain based on the first hash value and an encryption field of the encrypted firmware and obtaining decrypted firmware.

In the embodiment of the application, since the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the first computing device, the second computing device can execute the verification process on the certificate chain generated by the embodiment of the application on the basis of the existing TBBR verification process so as to realize compatibility with the existing TBBR verification standard.

In a second aspect, an embodiment of the present application provides a method for verifying firmware data, applied to an encryption/decryption chip, where the method includes obtaining a certificate chain to be verified, and verifying the certificate chain, where the certificate chain includes a multi-stage certificate, an encrypted firmware, and an encrypted field of the encrypted firmware, the encrypted field of the encrypted firmware includes an encryption algorithm, an initialization parameter of the encryption algorithm, and a key derivation parameter, determining a second hash value based on the encrypted firmware and the encrypted field of the encrypted firmware when the multi-stage certificate passes the verification, determining a decryption key of the encrypted firmware based on a root key and the key derivation parameter of the encrypted firmware when the second hash value is equal to a first hash value corresponding to the encrypted field of the encrypted firmware in a leaf certificate of the multi-stage certificate, and decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameter of the encryption algorithm, to obtain the decrypted firmware.

In the embodiment of the application, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the first computing device, so that the verification process can be executed on the certificate chain generated by the embodiment of the application on the basis of the existing TBBR verification process, and the compatibility with the existing TBBR verification standard is realized. Further, by constructing a flow of ensuring that the encrypted firmware can be securely and reliably decrypted, it is possible to ensure that the decrypted firmware obtained by decryption is tamper-free firmware data.

In some embodiments, the encryption firmware is obtained by encrypting the unencrypted firmware by the encryption algorithm based on an encryption key of the unencrypted firmware and an initialization parameter of the encryption algorithm, the encryption key of the unencrypted firmware is determined based on the root key and a key derivative parameter of the encrypted firmware, and the key derivative parameter of the encrypted firmware and the root key are randomly generated data sequences.

In the embodiment of the application, the corresponding key derivative data is randomly generated for different unencrypted firmware, so that different encryption keys can be generated for each unencrypted firmware based on the root key, and the encryption keys of the root key and other firmware can be ensured to be safe even if the encryption key of the unencrypted firmware A is cracked. In addition, by encrypting the unencrypted firmware based on the firmware encryption key and the initialization parameters of the encryption algorithm, it is possible to ensure that even when the same firmware is encrypted again, the resulting encrypted firmware is completely different because the initialization parameters of the encryption algorithm are random, and thus replay attacks and pattern analysis attacks can be avoided.

In some embodiments, the decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameter of the encryption algorithm to obtain the decrypted firmware includes determining whether the encryption algorithm is a preset encryption algorithm supported by the encryption/decryption chip, and decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameter of the encryption algorithm to obtain the decrypted firmware if the encryption algorithm is the preset encryption algorithm supported by the encryption/decryption chip.

In the embodiment of the application, by checking whether the encryption algorithm obtained in the encryption field is a preset security algorithm, an attacker can be effectively prevented from tamper the encryption algorithm in the encryption field into a weak algorithm which is already cracked, so that the hardware security module can decrypt by using the weak algorithm to enhance the anti-attack capability. In addition, the problem of decryption failure due to the use of an unsupported or unsafe algorithm can be avoided, and the stability of decryption of firmware can be ensured.

In some embodiments, the multi-stage certificate includes a root certificate, an intermediate certificate as a next stage certificate of the root certificate, and a leaf certificate as a next stage certificate of the intermediate certificate, each stage certificate of the multi-stage certificate includes a public key of each stage certificate and a signature of each stage certificate, the verifying the certificate chain includes obtaining a hash value of a root public key and verifying a public key of the root certificate based on the hash value of the root public key, verifying a signature of the root certificate based on the public key of the root certificate in case that the public key of the root certificate is verified, verifying a signature of the intermediate certificate and a signature of the leaf certificate in case that the signature of the root certificate is verified, and determining that the multi-stage certificate is verified in case that both the signature of the intermediate certificate and the signature of the leaf certificate are verified.

In the embodiment of the application, the trust is built step by combining the hash value verification comparison and the signature verification from the hardware trust root (namely the hash value of the root public key in the one-time programmable memory OTP), so that the security intensity of the certificate chain can be enhanced through the double verification mechanism.

In some embodiments, each of the plurality of stages of certificates further includes a public key hash value of a next stage of certificate corresponding to the each stage of certificate, and the verifying the signature of the intermediate certificate and the signature of the leaf certificate when the signature of the root certificate passes the verification includes verifying the public key of the intermediate certificate based on the public key hash value of the intermediate certificate when the signature of the root certificate passes the verification, verifying the signature of the intermediate certificate based on the public key of the intermediate certificate when the public key of the intermediate certificate passes the verification, verifying the public key of the leaf certificate based on the public key hash value of the leaf certificate in the intermediate certificate when the signature of the intermediate certificate passes the verification, and verifying the signature of the leaf certificate based on the public key of the leaf certificate when the public key of the leaf certificate passes the verification.

In the embodiment of the application, the authenticity of the public key of the next-stage certificate is verified through the public key hash value of the next-stage certificate stored in the previous-stage certificate, and then the signature of the next-stage certificate is verified by using the public key of the next-stage certificate, so that a stricter trust verification flow is formed, and the security of a certificate chain can be further improved.

In some embodiments, the method further comprises starting the decryption firmware if the decryption firmware is obtained, and refusing to start the decryption firmware if any one of the multi-stage certificates fails to pass the verification or the first hash value is not equal to the second hash value.

In the embodiment of the application, the decrypted firmware is started after the encrypted firmware is successfully decrypted to obtain the decrypted firmware, and the encrypted firmware can be ensured to enter a safe state (refused to start) when any verification link fails, but not to continue to run in an unsafe state, thereby avoiding potential security threat.

In a third aspect, an embodiment of the present application provides an encryption/decryption chip, where the chip includes a hardware security module and a one-time programmable memory, where the one-time programmable memory is configured to store a root key, the hardware security module is configured to obtain a certificate chain to be verified and verify the certificate chain, where the certificate chain includes a multi-stage certificate, an encryption firmware, and an encryption field of the encryption firmware, the encryption field of the encryption firmware includes an encryption algorithm, an initialization parameter of the encryption algorithm, and a key derivation parameter, and determine, based on the encryption firmware and the encryption field of the encryption firmware, a second hash value if the multi-stage certificate passes the verification, and determine, based on the encryption key of the encryption firmware and the encryption algorithm, a decryption key of the encryption firmware if the second hash value is equal to a first hash value corresponding to the encryption field of the encryption firmware and the encryption firmware in a leaf of the multi-stage certificate, and decrypt, based on the decryption key of the encryption firmware and the key derivation parameter of the encryption firmware, and decrypt, to obtain the encryption firmware.

In some embodiments, the hardware security module is specifically configured to determine whether the encryption algorithm is a preset encryption algorithm supported by the encryption/decryption chip, and decrypt the encrypted firmware by the encryption algorithm based on a decryption key of the encrypted firmware and an initialization parameter of the encryption algorithm to obtain the decrypted firmware when the encryption algorithm is the preset encryption algorithm supported by the encryption/decryption chip.

In some embodiments, the multi-stage certificate comprises a root certificate, an intermediate certificate serving as a next-stage certificate of the root certificate, and a leaf certificate serving as a next-stage certificate of the intermediate certificate, each stage of certificate in the multi-stage certificate comprises a public key of each stage of certificate and a signature of each stage of certificate, the hardware security module is specifically configured to take a hash value of the root public key and verify the public key of the root certificate based on the hash value of the root public key, verify the signature of the root certificate based on the public key of the root certificate if the public key of the root certificate is verified, verify the signature of the intermediate certificate and the signature of the leaf certificate if the signature of the root certificate is verified, and determine that the multi-stage certificate is verified if both the signature of the intermediate certificate and the signature of the leaf certificate are verified.

In some embodiments, each level of the multi-level certificate further comprises a public key hash value of a next level of the corresponding level of the certificate, and the hardware security module is specifically configured to verify the public key of the intermediate certificate based on the public key hash value of the intermediate certificate in the root certificate if the signature of the root certificate passes the verification, verify the signature of the intermediate certificate based on the public key of the intermediate certificate if the public key of the intermediate certificate passes the verification, verify the public key of the leaf certificate based on the public key hash value of the leaf certificate in the intermediate certificate if the signature of the intermediate certificate passes the verification, and verify the signature of the leaf certificate based on the public key of the leaf certificate if the public key of the leaf certificate passes the verification.

In some embodiments, the encryption and decryption chip further comprises a processor core, wherein the hardware security module is specifically configured to send information that the firmware passes the verification and the decryption firmware to the processor core, and the processor core is configured to start the decryption firmware when receiving the information that the firmware passes the verification.

In a fourth aspect, an embodiment of the present application provides an encryption and decryption system, where the system includes a first computing device, a second computing device, and a third computing device, where the second computing device is disposed with an encryption and decryption chip, where the encryption and decryption chip includes a hardware security module, where the first computing device is configured to implement part or all of the steps in the method in the first aspect, the encryption and decryption chip is configured to implement part or all of the steps in the method in the second aspect, and the third computing device is configured to generate a root key, and burn the root key into a one-time programmable memory of the hardware security module.

In a fifth aspect, an embodiment of the present application provides a computer device, including a memory and an encryption/decryption chip, where the memory stores a computer program that can run on the encryption/decryption chip, and when the encryption/decryption chip executes the program, part or all of the steps in the above method are implemented.

In a sixth aspect, an embodiment of the present application provides a computer readable storage medium, on which a computer program is stored, where the computer program, when executed by an encryption/decryption chip, implements some or all of the steps in the above method.

In a seventh aspect, an embodiment of the present application provides a program product, where the program product includes a computer program or instructions, and when the computer program or instructions are executed by an encryption/decryption chip, implement some or all of the steps in the above method.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

FIG. 1 is a schematic diagram of an encryption and decryption system according to an embodiment of the present application;

Fig. 2 is a schematic structural diagram of a certificate chain according to an embodiment of the present application;

FIG. 3 is a schematic diagram of firmware certificate data according to an embodiment of the present application;

fig. 4 is a schematic implementation flow chart of an encryption method for firmware data according to an embodiment of the present application;

fig. 5 is a schematic implementation flow chart of a method for verifying firmware data according to an embodiment of the present application;

FIG. 6 is a schematic diagram illustrating an implementation flow of another method for verifying firmware data according to an embodiment of the present application;

Fig. 7 is a schematic implementation flow chart of a verification method of firmware data according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a composition structure of an encryption/decryption chip according to an embodiment of the present application;

Fig. 9 is a schematic diagram of a hardware entity of a computer device according to an embodiment of the present application.

It should be noted that the above "first" and "second" are only used to distinguish between different schemes, and do not represent the degree of preference or priority in implementation.

Detailed Description

The technical solution of the present application will be further elaborated with reference to the accompanying drawings and examples, which should not be construed as limiting the application, but all other embodiments which can be obtained by one skilled in the art without making inventive efforts are within the scope of protection of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with one another without conflict. The term "first/second/third" is merely to distinguish similar objects and does not represent a particular ordering of objects, it being understood that the "first/second/third" may be interchanged with a particular order or precedence, as allowed, to enable embodiments of the application described herein to be implemented in other than those illustrated or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing the application only and is not intended to be limiting of the application.

In the related art, although the existing TBBR scheme provides integrity verification of firmware, the firmware in the certificate chain is stored in a plaintext form in a storage medium, and thus confidentiality protection of the firmware is lacking. Therefore, once an attacker acquires the chip, the attacker can directly extract the complete firmware data and carry out reverse engineering processing on the firmware data so as to analyze the information of key algorithms, security logic, loopholes and the like. Even an attacker can directly replicate intellectual property, resulting in core technology leakage, which brings great economic loss and competitive disadvantages to product developers. In addition, in the application scenario with high security requirements such as financial payment, identity authentication, automobile electronics, etc., the firmware itself may contain sensitive data such as keys, certificates, personal identity information, etc. Therefore, the existing TBBR scheme cannot effectively avoid the extraction of the sensitive information along with the firmware data, so that the strict requirement of such a scene on data confidentiality cannot be met. In addition, the existing TBBR scheme can only detect that the firmware data is tampered and refused to start, but cannot prevent an attacker from analyzing the plaintext firmware and repackaging after malicious code is implanted. Once an attacker finds the vulnerability and constructs effective malicious firmware, the verification process can be bypassed, thereby seriously threatening the system security. Therefore, there is a need for a method of encrypting firmware data that improves firmware security to ensure the integrity and confidentiality of the firmware.

Based on the technical problems, the embodiment of the application provides an encryption method, a verification method, an encryption and decryption chip and a system for firmware data, which can realize confidentiality protection of the firmware data, thereby improving the security of the firmware.

Fig. 1 is a schematic structural diagram of an encryption and decryption system according to an embodiment of the present application, as shown in fig. 1, the encryption and decryption system 100 includes a first computing device 110, a second computing device 120, and a third computing device 130, where an encryption and decryption chip 121 is disposed in the second computing device 120. The encryption and decryption chip 121 includes a hardware security module (Hardware Security Module, HSM) 1201 and a processor core 1203, and the hardware security module 1201 includes a one-time programmable memory 1202. It should be noted that, the first computing device 110 and the third computing device 130 may be the same computing device or may be different computing devices, which is not limited in the embodiment of the present application.

The encryption and decryption Chip 121 may be a System on Chip (SoC), a central processing unit (Central Processing Unit, CPU), a microprocessor (Microprocessor Unit, MPU), a digital signal Processor (DIGITAL SIGNAL Processor, DSP), a field programmable gate array (Field Programmable GATE ARRAY, FPGA), or the like, and the specific type of the encryption and decryption Chip 121 is not limited in the embodiment of the present application. The second computing device 120 for deploying the encryption and decryption chip 121 may be a computer device with data processing capability, such as a vehicle-mounted terminal, a server, a notebook computer, a tablet computer, a desktop computer, a smart television, a set-top box, a mobile device (for example, a mobile phone, a portable video player, a personal digital assistant, a dedicated messaging device, and a portable game device), and the specific type of the second computing device 120 is not limited in the embodiments of the present application.

The third computing device 130 is configured to generate a random Root Key (Root Key) through a random number generator in the third computing device 130 during the production process of the encryption/decryption chip 121, and burn the hash value of the Root public Key and the Root Key into the one-time programmable memory 1202 of the hardware security module 1201 through the third computing device 130. In addition, the third computing device 130 may establish a mapping relationship between the encryption and decryption chip 121 and the root keys thereof, and store the mapping relationship to obtain a key set, that is, the key set includes the root keys corresponding to the encryption and decryption chips. It can be understood that the root keys corresponding to different encryption and decryption chips are different from each other. The embodiment of the application does not limit the specific length of the root key, and it can be understood that the higher the bit number of the used random data sequence is, the more different the root keys corresponding to different encryption and decryption chips can be ensured. Since the contents in the otp memory 1202 cannot be read through any external interface and have a physical tamper-proof protection mechanism, in addition, the content that is burned cannot be modified, so that the hash value of the root public key and the security of the root key can be ensured.

The first computing device 110 is configured to generate a certificate chain, and send the certificate chain to the encryption and decryption chip 121, so that the encryption and decryption chip 121 verifies the certificate chain through the hardware security module 1201 to determine whether the firmware therein can be started. Wherein the certificate chain includes a multi-level certificate and firmware certificate data. The multi-level certificate includes a root certificate, an intermediate certificate, and a leaf certificate. Referring to a schematic structure of a Certificate chain shown in fig. 2, as shown in fig. 2, the Certificate chain includes a Root Certificate (Root Certificate), an intermediate Certificate (INTERMEDIATE CERTIFICATES), a leaf Certificate (LEAF CERTIFICATE), and firmware Certificate data (FIRMWARE DATA). The root certificate includes a root public key, a signature, and a public key hash (hash) value of a next-stage certificate (e.g., certificate 1), the hash value of the root public key is burned in the one-time programmable memory 1202, the intermediate certificate may include multiple stages of certificates (e.g., certificate 1, certificate 2.. The first hash value is used for authenticating the encrypted firmware), each stage of intermediate certificate includes a public key of each stage of intermediate certificate, a signature, and a public key hash value of a corresponding next-stage certificate thereof, e.g., certificate 1 includes a public key of certificate 1, a signature, and a public key hash value of certificate 2, certificate N includes a public key of certificate N, a signature, and a public key hash value of a leaf certificate, the leaf certificate is a last-stage certificate in the certificate chain including a public key of the leaf certificate, the signature, and a hash value (hereinafter referred to as a first hash value) corresponding to encrypted firmware and an encrypted field of encrypted firmware, and the first hash value is determined based on the encrypted firmware and the encrypted field of encrypted firmware. The firmware certificate data includes encrypted firmware and encrypted fields of the encrypted firmware, the encrypted fields of the encrypted firmware including an encryption algorithm, initialization parameters (Initialization Vector, IV) for the encryption algorithm, and key derivation parameters (Key Derivation Data).

Illustratively, the encryption algorithm field is used to determine a symmetric encryption algorithm used in encrypting and decrypting the firmware, such as an advanced encryption standard (Advanced Encryption Standard, AES) algorithm (e.g., AES-128-CBC, AES-256-GCM), a block cipher algorithm (e.g., SM4-CBC, SM 4-GCM), and so forth.

The initialization parameter field of the encryption algorithm may be an initialization vector required for the encryption algorithm or an arbitrary or non-repeated random Number (Nonce) value that is used only once. The IV value of the encryption algorithm may be a random data sequence generated by the first computing device 110. For example, the IV value for the AES algorithm may be a 16 byte random data sequence.

The key derivation parameter field is used to generate, in conjunction with the root key, a firmware encryption key for encrypting the unencrypted firmware. Wherein the key derivation parameter may be a random data sequence generated by the first computing device 110, e.g., the key derivation parameter may be 32 bytes in length. The specific length of the key derivation parameter is not limited in the embodiment of the present application.

The key derivation algorithm may include, among others, an HMAC (key based message authentication code algorithm, hash-based Message Authentication Code) based key derivation function (HMAC-based Key Derivation Function, HKDF), a Password based key derivation function (Password-Based Key Derivation Function, pbkdf 2), and the like. The key derivation algorithm is used to convert an initial key (such as a root key) into a plurality of security keys, so as to improve the security of the root key. For example, HKDF can extract-expand a two-step derivative of the root key, and PBKDF2 can resist brute force cracking of the root key by hashing the salt multiple times. Illustratively, the first computing device 110 may obtain the root key of the encryption and decryption chip 121 from the above-mentioned key set, and process the root key and the key derivation parameters through a key derivation algorithm to obtain a root key with enhanced security, so as to determine it as a firmware encryption key for encrypting the current unencrypted firmware data. I.e., firmware encryption key=kdf (root_key, key_derivative_data). By randomly generating corresponding key derivative data for different unencrypted firmware, different encryption keys can be generated for each unencrypted firmware based on the root key, so that even if the encryption key of the unencrypted firmware A is cracked, the root key and the encryption keys of other firmware can be ensured to be safe, and flexible key rotation and version management can be realized.

Next, the first computing device 110 may encrypt the unencrypted firmware by the encryption algorithm in the encryption field based on the firmware encryption key and the IV value of the encryption algorithm to obtain the encrypted firmware, and calculate a hash value of the encrypted firmware (hereinafter referred to as a first hash value of the encrypted firmware). By encrypting the unencrypted firmware based on the firmware encryption key and the IV value of the encryption algorithm, it is possible to ensure that even when the same firmware is encrypted again, the obtained encrypted firmware is completely different because the IV value of the encryption algorithm is random, and thus replay attacks and pattern analysis attacks can be avoided.

Reference is made to a schematic diagram of firmware certificate data as shown in fig. 3. As shown in fig. 3, the first computing device 110 may write the encrypted firmware and the encrypted fields of the encrypted firmware into a certificate chain to obtain firmware certificate data and write the first hash value into a leaf certificate, and then digitally sign the certificate chain based on TBBR flow to generate an image of the complete certificate chain.

Illustratively, after obtaining the image file of the certificate chain, the first computing device 110 may send the image file of the certificate chain to the encryption/decryption chip 121 in the second computing device 120. After receiving the image file of the certificate chain, the encryption/decryption chip 121 may transmit the image file of the certificate chain to the hardware security module 1201 by starting up a Read-Only Memory (BootROM).

The hardware security module 1201 is configured to verify a received certificate chain to be verified. For example, the hardware security module 1201 may first read the hash value of the root public key from the otp memory 1202 and verify the multi-level certificate in the certificate chain based on the hash value of the root public key. In the case that the multi-level certificates in the certificate chain pass the verification, the hardware security module 1201 may obtain the first hash value of the encrypted firmware from the leaf certificate, and calculate the second hash value corresponding to the encrypted firmware and the encrypted field thereof in the firmware certificate data. Wherein, in the case that the leaf certificate passes the verification, it means that the encrypted firmware and the first hash value corresponding to the encrypted field thereof are data that have not been tampered with. The hardware security module 1201 may then determine whether the second hash value corresponding to the encrypted firmware and its encrypted field is equal to the first hash value corresponding to the encrypted firmware and its encrypted field that has passed the verification. If the first hash value is equal to the second hash value, the encrypted firmware and the encrypted field thereof are data which are not tampered, namely the second hash value corresponding to the encrypted firmware and the encrypted field thereof passes the verification.

Then, in the case where the encrypted firmware and the second hash value corresponding to the encrypted field thereof pass the verification, the hardware security module 1201 may acquire the encrypted field of the encrypted firmware in the firmware certificate data, and read the root key from the otp memory 1202. And then, the root key and the key derivative parameters of the encrypted firmware in the encrypted field are processed through a key derivative algorithm to obtain the decryption key of the encrypted firmware. I.e., decryption Key of encrypted firmware = KDF (root_key, key_decryption_data). Wherein the encryption key of the encryption firmware and the key derivation algorithm used in generating the decryption key of the encryption firmware are the same algorithm.

The hardware security module 1201 may then decrypt the encrypted firmware based on the decryption key of the encrypted firmware and the IV value of the encryption algorithm by the encryption algorithm in the encryption field to obtain decrypted firmware. Wherein the encryption algorithm used in generating the encryption firmware and decrypting the firmware is the same algorithm.

Illustratively, the hardware security module 1201 may then send the decrypted firmware and information that the decrypted firmware passed the verification to the processor core 1203 of the cryptographic chip 121. After the processor core 1203 receives the decrypted firmware and the information that the decrypted firmware passes the verification, the decrypted firmware is started.

For example, if any one of the certificates in the certificate chain fails to pass the verification, or if the second hash value corresponding to the encrypted firmware and the encrypted field thereof fails to pass the verification, the hardware security module 1201 may send information that the firmware fails to pass the verification to the processor core 1203 of the encryption/decryption chip 121. After the processor core 1203 receives the information that the firmware fails verification, execution of the boot up of the firmware may be denied to enter a secure state.

In the embodiment of the application, the potential safety hazard of the firmware plaintext storage in the existing TBBR scheme can be solved by replacing the apparent Wen Gujian data in the existing TBBR certificate chain with the encrypted firmware and the encrypted field of the encrypted firmware, reverse engineering and malicious analysis can be effectively prevented by encrypting the firmware by using a symmetric encryption algorithm, and in addition, even if an attacker acquires a certificate chain mirror image, the encrypted firmware cannot be cracked and sensitive codes and algorithm realization in the firmware can not be read, so that the dual protection of the integrity and confidentiality of the firmware can be realized. Moreover, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the embodiment of the application, so that the verification process can be executed on the certificate chain generated by the embodiment of the application by slightly modifying the existing TBBR verification tool, thereby realizing the compatibility with the existing TBBR verification standard.

Fig. 4 is a schematic flow chart of an implementation of a firmware data encryption method according to an embodiment of the present application, where the method may be executed by a computer device (e.g., a first computing device). As shown in fig. 4, the method includes S401 to S404:

s401, generating random key derivation parameters, and calculating the key derivation parameters and the root key based on a key derivation algorithm to obtain an encryption key of the unencrypted firmware.

In some implementations, the first computing device may process the root key and key derivation parameters corresponding to the unencrypted firmware by a key derivation algorithm to obtain a firmware encryption key for encrypting the unencrypted firmware. The key derivation parameters are random data sequences randomly generated by the first computing device, and the key derivation parameters corresponding to different unencrypted firmware are different. It will be appreciated that the specific implementation of S401 may refer to the embodiment shown in fig. 1, and will not be described herein.

S402, the encryption algorithm is used for carrying out encryption processing on the unencrypted firmware based on the encryption key of the unencrypted firmware and the initialization parameters of the encryption algorithm, so as to obtain the encrypted firmware.

In some implementations, the first computing device may encrypt the unencrypted firmware by an encryption algorithm in the encryption field based on a firmware encryption key of the unencrypted firmware and an IV value of the encryption algorithm to obtain the encrypted firmware.

It will be appreciated that the specific implementation of S402 may refer to the embodiment shown in fig. 1, and will not be described herein.

S403, determining a first hash value based on the encrypted firmware and the encrypted field of the encrypted firmware.

In some implementations, the first computing device may calculate a first hash value corresponding to the encrypted firmware and its encrypted field. It will be appreciated that the specific implementation of S403 may refer to the embodiment shown in fig. 1, and will not be described herein.

S404, generating a certificate chain based on the encrypted firmware, the first hash value, the encrypted field of the encrypted firmware and the multi-stage certificate.

In some implementations, the first computing device can sign-authenticate the encrypted firmware, the first hash value, and the encrypted field of the encrypted firmware described above based on TBBR flows to generate the certificate chain. And, the first computing device may send the image file of the certificate chain to the computing device (e.g., the second computing device) where the encryption and decryption chip is disposed, so that the encryption and decryption chip in the second computing device may determine whether the firmware data therein can be started by performing a verification procedure on the certificate chain. It can be appreciated that the specific implementation of S404 may refer to the embodiment shown in fig. 1, and will not be described herein.

In the embodiment of the application, the unencrypted firmware is encrypted based on the root key and the encryption parameter, and the visible Wen Gujian data in the existing TBBR certificate chain is replaced by the encrypted firmware and the encryption field of the encrypted firmware, so that the potential safety hazard of the clear text storage of the firmware in the existing TBBR scheme can be solved, the confidentiality protection of the firmware data is realized, and the firmware data can be further prevented from being threatened by security. In addition, even if an attacker acquires a certificate chain mirror image, the encrypted firmware cannot be cracked and sensitive codes and algorithm implementation in the firmware can not be read, so that the integrity and confidentiality of the firmware can be doubly protected. Moreover, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the embodiment of the application, so that the compatibility with the existing TBBR verification standard can be ensured.

Fig. 5 is a schematic implementation flow chart of a method for verifying firmware data according to an embodiment of the present application, where the method may be executed by an encryption/decryption chip in a computer device (e.g., a second computing device). As shown in fig. 5, the method includes S501 to S504:

S501, acquiring a certificate chain to be verified, and verifying the certificate chain.

In some implementations, the first computing device sends an image of the certificate chain to the encryption and decryption chip after generating the encryption firmware based on the root key and the encryption field and signing each level of certificates using the private key to obtain the certificate chain. After receiving the image file of the certificate chain, the encryption and decryption chip verifies the certificate chain in the image file through a hardware security module HSM. It can be appreciated that the specific implementation of S501 may refer to the embodiment shown in fig. 1, and will not be described herein.

S502, determining a second hash value based on the encrypted firmware and the encrypted field of the encrypted firmware when the multi-stage certificates pass verification.

It can be appreciated that the specific implementation of S502 may refer to the embodiment shown in fig. 1, and will not be described herein.

S503, determining a decryption key of the encrypted firmware based on the root key and the key derivative parameter of the encrypted firmware when the second hash value is equal to the first hash value corresponding to the encrypted field of the encrypted firmware and the encrypted firmware in the leaf certificate of the multi-stage certificate.

In some embodiments, if the multi-level certificates in the certificate chain are all verified, and the hash value of the encrypted firmware and its encrypted field is also verified, it indicates that the certificate chain is authentic, i.e., the encrypted firmware and its encrypted field in the certificate chain have not been tampered with. The hardware security module HSM may obtain the encrypted field of the encrypted firmware and decrypt the encrypted firmware based on the encrypted field of the encrypted firmware to obtain decrypted firmware. For example, the hardware security module HSM may first determine a decryption key for the encrypted firmware based on the root key and a key derivative parameter for the encrypted firmware in the encryption field. It can be appreciated that the specific implementation of S503 may refer to the embodiment shown in fig. 1, and will not be described herein.

S504, decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameters of the encryption algorithm to obtain decrypted firmware.

In some embodiments, after determining the decryption key of the encrypted firmware, the hardware security module HSM may decrypt the encrypted firmware by the encryption algorithm in the encryption field based on the determined decryption key of the encrypted firmware and the IV value of the encryption algorithm in the encryption field to obtain the decrypted firmware. It will be appreciated that the specific implementation of S504 may refer to the embodiment shown in fig. 1, and will not be described herein.

In the embodiment of the application, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the first computing device, so that the verification process can be executed on the certificate chain generated by the embodiment of the application by slightly modifying the existing TBBR verification tool, thereby realizing the compatibility with the existing TBBR verification standard. In addition, the embodiment of the application ensures that the decrypted firmware obtained by decryption is the untampered firmware data by constructing a flow for ensuring that the encrypted firmware can be decrypted safely and credibly.

In some embodiments, the step S504 may include determining whether the encryption algorithm is a preset encryption algorithm supported by the encryption/decryption chip, and decrypting the encrypted firmware by the encryption algorithm based on a decryption key of the encrypted firmware and an initialization parameter of the encryption algorithm to obtain decrypted firmware if the encryption algorithm is the preset encryption algorithm supported by the encryption/decryption chip.

For example, after acquiring the encryption algorithm in the encryption field of the encrypted firmware, the hardware security module HSM may first determine whether the encryption algorithm is a preset encryption algorithm supported by the hardware security module HSM. For example, the hardware security module HSM may store the supported preset encryption algorithm in the form of a list to determine that the obtained encryption algorithm is the preset encryption algorithm supported by the hardware security module HSM in the case that the obtained encryption algorithm is the preset encryption algorithm in the list. The encrypted firmware is then decrypted by the encryption algorithm based on the decryption key of the encrypted firmware and the IV value of the encryption algorithm to obtain decrypted firmware.

In the embodiment of the application, by checking whether the encryption algorithm obtained in the encryption field is a preset security algorithm, an attacker can be effectively prevented from tamper the encryption algorithm in the encryption field into a weak algorithm which is already cracked, so that the hardware security module HSM uses the weak algorithm to decrypt, and the anti-attack capability is enhanced. In addition, the problem of decryption failure due to the use of an unsupported or unsafe algorithm can be avoided, and the stability of decryption of firmware can be ensured.

Fig. 6 is a schematic flow chart of another implementation of a method for verifying firmware data according to an embodiment of the present application, where the method may be performed by an encryption/decryption chip in a computer device (e.g., a second computing device). Based on fig. 5, S501 "verify certificate chain" in fig. 5 may be updated to S601 to S604, and the steps shown in fig. 6 will be described.

S601, obtaining a hash value of the root public key, and checking the public key of the root certificate based on the hash value of the root public key.

In some embodiments, after receiving the image file of the certificate chain, the hardware security module HSM may first read the hash value of the pre-recorded root public key from the OTP, calculate the current hash value of the public key stored in the current certificate, and then verify the current hash value of the public key based on the verified hash value of the public key corresponding to the current certificate.

For example, in the case where the current certificate is a root certificate, the current hash value of the root public key of the root certificate may be calculated first, and the current hash value of the root public key may be compared with the hash value of the root public key (i.e., the verified public key hash value) stored in the OTP to verify the root public key hash value of the root certificate.

S602, in a case where the public key of the root certificate passes the verification, the signature of the root certificate is verified based on the public key of the root certificate.

In some embodiments, if the current hash value of the root public key is equal to the hash value of the root public key stored in the one-time programmable memory OTP, it indicates that the root public key hash value of the root certificate passes the verification, and if the current hash value of the root public key is not equal to the hash value of the root public key stored in the one-time programmable memory OTP, it indicates that the root public key hash value of the root certificate does not pass the verification.

In some embodiments, if the public key hash value of the current certificate passes the verification, the hardware security module HSM obtains the public key of the current certificate and verifies the signature of the current certificate based on the public key of the current certificate. Illustratively, if the root public key hash value of the root certificate passes the verification, the root public key of the root certificate is obtained and the signature of the root certificate is verified based on the root public key of the root certificate.

S603, in the case where the signature of the root certificate passes the verification, the signature of the intermediate certificate and the signature of the leaf certificate are verified.

In some embodiments, if the signature of the current certificate passes the verification, the hardware security module HSM may determine whether the currently verified certificate is a leaf certificate, i.e. determine whether to verify to the last stage certificate. If the last-stage certificate is not checked, the hardware security module HSM acquires the public key hash value of the next-stage certificate in the current certificate, and determines the next-stage certificate as the current certificate. Illustratively, if the root certificate is currently checked, the hardware security module HSM proceeds to check the signature of the intermediate certificate and the signature of the leaf certificate in sequence.

S604, in the case where the signature of the intermediate certificate and the signature of the leaf certificate are both verified, it is determined that the multi-level certificate is both verified.

In some embodiments, where the signature of the intermediate certificate and the signature of the leaf certificate are both verified, it is indicative that the root certificate, the intermediate certificate, and the leaf certificate in the chain of certificates are all verified. After the last-stage certificate (i.e. the leaf certificate) passes the verification, the hardware security module HSM may read the encrypted firmware and the first hash value corresponding to the encrypted field thereof from the leaf certificate, so as to verify the encrypted firmware and the first hash value corresponding to the encrypted field thereof.

In some embodiments, the step S603 may include verifying the public key of the intermediate certificate based on the public key hash value of the intermediate certificate in the root certificate if the signature of the root certificate passes the verification, verifying the signature of the intermediate certificate based on the public key of the intermediate certificate if the public key of the intermediate certificate passes the verification, verifying the public key of the leaf certificate based on the public key hash value of the leaf certificate in the intermediate certificate if the signature of the intermediate certificate passes the verification, and verifying the signature of the leaf certificate based on the public key of the leaf certificate if the public key of the leaf certificate passes the verification.

In some embodiments, in the event that the signature of the root certificate passes the verification, the public key of the intermediate certificate is verified based on the public key hash value of the intermediate certificate in the root certificate. For example, in the case where the current certificate is the intermediate certificate 1, the current hash value of the public key 1 of the intermediate certificate 1 may be calculated first, and the current hash value of the public key 1 may be compared with the hash value of the public key 1 stored in the root certificate (i.e., the verified public key hash value) to verify the public key 1 hash value of the intermediate certificate 1. If the current hash value of the public key of the intermediate certificate is equal to the hash value of the public key stored in the previous-stage certificate, the public key hash value of the intermediate certificate is verified, and if the current hash value of the public key of the intermediate certificate is not equal to the hash value of the public key stored in the previous-stage certificate, the public key hash value of the intermediate certificate is not verified. If the public key hash value of the intermediate certificate passes the verification (i.e., the public key of the intermediate certificate passes the verification), the public key of the intermediate certificate is obtained and its signature is verified based on the public key of the intermediate certificate. And if all the signatures of the intermediate certificates pass the verification, the verification of the leaf certificates is continued.

In the case that the current certificate is a leaf certificate, the current hash value of the public key of the leaf certificate may be calculated first, and the current hash value of the public key of the leaf certificate may be compared with the hash value of the public key (i.e., the verified public key hash value) stored in the intermediate certificate of the previous stage (e.g., the intermediate certificate N) to verify the public key hash value of the leaf certificate. If the current hash value of the public key of the leaf certificate is equal to the hash value of the public key stored in the intermediate certificate of the last stage, the public key hash value of the leaf certificate passes the verification, and if the current hash value of the public key of the leaf certificate is not equal to the hash value of the public key of the intermediate certificate of the last stage, the public key hash value of the leaf certificate does not pass the verification. If the public key hash value of the leaf certificate passes the verification, the public key of the leaf certificate is obtained, and the signature of the leaf certificate is verified based on the public key of the leaf certificate.

Fig. 7 is a schematic implementation flow chart of a method for verifying firmware data according to an embodiment of the present application, as shown in fig. 7, the method includes S701 to S715. The method for verifying firmware data provided by the embodiment of the application is summarized as follows.

S701, a hardware security module HSM acquires a certificate chain to be verified.

It will be appreciated that the implementation of S701 may refer to the embodiment shown in fig. 1 and the description of S501, which are not repeated herein.

S702, the hardware security module HSM reads the hash value of the root public key from the one-time readable memory OTP.

It is to be understood that the implementation of S702 may refer to the description of S701, which is not repeated herein.

S703, the hardware security module HSM verifies the public key hash value of the current certificate.

It can be appreciated that the implementation of S703 may refer to the embodiment shown in fig. 1 and the description of S601, which are not described herein.

S704, the hardware security module HSM determines whether the public key hash value of the current certificate passes the verification.

Illustratively, the hardware security module HSM performs S705 if the public key hash value of the current certificate is verified, and performs S714 if the public key hash value of the current certificate is verified.

And S705, if the public key hash value of the current certificate passes the verification, the hardware security module HSM acquires the public key of the current certificate and verifies the signature of the current certificate based on the public key of the current certificate.

It is to be understood that the implementation of S705 may refer to the descriptions of S602 and S603, and will not be described herein.

S706, the hardware security module HSM determines whether the signature of the current certificate passes the verification.

Illustratively, if the signature of the current certificate is verified, the hardware security module HSM performs S707, and if the signature of the current certificate is not verified, the hardware security module HSM performs S714.

S707, if the signature of the current certificate passes the verification, the hardware security module HSM determines whether to verify to the last-stage certificate.

Illustratively, if the signature of the current certificate passes the verification, the hardware security module HSM determines whether the currently verified certificate is a leaf certificate, i.e. whether to verify to the last stage certificate. If the last-stage certificate is not verified, the hardware security module HSM performs S708, and if the last-stage certificate is verified, the hardware security module HSM performs S709.

If the last-stage certificate is not verified, the hardware security module HSM obtains the public key hash value of the next-stage certificate in the current certificate, and determines the next-stage certificate as the current certificate.

For example, if the last-stage certificate is not verified, the hardware security module HSM reads the public key hash value of the next-stage certificate corresponding to the current certificate from the current certificate, and determines the next-stage certificate as the current certificate. For example, if the currently verified certificate is a root certificate, the public key hash value of the next intermediate certificate (e.g., certificate 1) is read from the root certificate and the intermediate certificate is determined to be the current certificate. If the currently verified certificate is an intermediate certificate, the next level certificate (e.g., certificate 2 certificate 3....the public key hash value of certificate N, or leaf certificate), and determines the next-level certificate as the current certificate.

And S709, if the last-stage certificate is checked, the hardware security module HSM acquires the encryption field of the encryption firmware and the hash value corresponding to the encryption firmware and the encryption field in the current certificate, and checks the hash value corresponding to the encryption firmware and the encryption field.

Illustratively, if the last-stage certificate (i.e., the leaf certificate) is checked, the hardware security module HSM reads the encrypted firmware and the first hash value corresponding to the encrypted field thereof from the leaf certificate, and reads the encrypted firmware and the encrypted field thereof from the firmware certificate data to calculate the second hash value corresponding to the encrypted firmware and the encrypted field thereof, thereby checking the hash value corresponding to the encrypted firmware and the encrypted field thereof.

S710, the hardware security module HSM determines whether the hash value corresponding to the encrypted firmware and the encrypted field passes the verification.

In some embodiments, if the second hash value of the encrypted firmware and its encrypted field is not equal to the first hash value that has been verified in the leaf certificate, indicating that the hash value corresponding to the encrypted firmware and its encrypted field has not been verified, the hardware security module HSM performs S714, and if the second hash value of the encrypted firmware and its encrypted field is equal to the first hash value, indicating that the hash value corresponding to the encrypted firmware and its encrypted field has been verified, the hardware security module HSM performs S711.

S711, if the hash value corresponding to the encrypted firmware and the encrypted field thereof passes the verification, the hardware security module HSM reads the root key from the one-time readable memory OTP.

It is to be understood that the implementation of S711 may refer to the description of the embodiment shown in fig. 1, and will not be repeated herein.

S712, the hardware security module HSM determines a decryption key of the encrypted firmware based on the root key and the key derivative parameter of the encrypted firmware.

It will be appreciated that the implementation of S712 may refer to the embodiment shown in fig. 1 and the description of S503, which are not repeated herein.

S713, the hardware security module HSM decrypts the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameters of the encryption algorithm to obtain decrypted firmware.

It will be appreciated that the implementation of S713 may refer to the embodiment shown in fig. 1 and the description of S504, and will not be repeated here.

S714, if the public key hash value of the current certificate fails to pass the verification, or the signature of the current certificate fails to pass the verification, or the hash value corresponding to the encrypted firmware and the encrypted field thereof fails to pass the verification, the processor core refuses to start the firmware.

It is to be understood that the implementation of S714 may refer to the description of the embodiment shown in fig. 1, and will not be repeated herein.

S715, if the hash value of the encrypted firmware passes the verification, the processor core starts the firmware.

It is to be understood that the implementation of S715 may refer to the description of the embodiment shown in fig. 1, and will not be described herein.

The encryption method, the verification method, the encryption and decryption chip and the system for the firmware data can provide hardware-level security protection for the root key based on the characteristics of the one-time programmable memory by burning the root key into the one-time programmable memory, the security is far higher than that of software storage, the one-time programmable memory is a hardware module in a hardware security module, therefore, no additional hardware cost is needed, and the root key can share the same storage area with the hash value of the original root public key. Moreover, by replacing the explicit Wen Gujian data in the existing TBBR certificate chain with encrypted firmware and the encrypted field of the encrypted firmware, the potential safety hazard of the clear text storage of the firmware in the existing TBBR scheme can be solved, so that the dual protection of the integrity and confidentiality of the firmware can be realized. In the embodiment of the application, the encryption field is generated and the firmware is encrypted based on the encryption field, so that double guarantees of confidentiality protection and integrity check can be simultaneously provided for the firmware data, multiple symmetrical encryption algorithms can be used during encryption, so that different security level requirements can be met, and the key derivation process for generating the firmware decryption key is completed in the hardware security module, so that key leakage can be avoided. In addition, the structure of the original certificate chain of the existing TBBR is not changed by the certificate chain generated by the embodiment of the application, so that the verification process can be executed on the certificate chain generated by the embodiment of the application by slightly modifying the existing TBBR verification tool, thereby realizing the compatibility with the existing TBBR verification standard.

Fig. 8 is a schematic diagram of a composition structure of an encryption/decryption chip according to an embodiment of the present application, as shown in fig. 8, the encryption/decryption chip 800 includes a one-time programmable memory 810 and a hardware security module 820, wherein:

the one-time programmable memory 810 is used to store the root key.

The hardware security module 820 is configured to obtain a certificate chain to be verified and verify the certificate chain, where the certificate chain includes a multi-stage certificate, an encrypted firmware, and an encrypted field of the encrypted firmware, the encrypted field of the encrypted firmware includes an encryption algorithm, an initialization parameter of the encryption algorithm, and a key derivation parameter, and

Determining a second hash value based on the encrypted firmware and the encrypted field of the encrypted firmware in the event that the multi-level certificate passes the verification, and

Determining a decryption key of the encrypted firmware based on the root key and a key derivation parameter of the encrypted firmware, in the case where the second hash value is equal to a first hash value corresponding to the encrypted firmware and an encryption field of the encrypted firmware in a leaf certificate of the multi-stage certificate, and

And decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameter of the encryption algorithm to obtain the decrypted firmware.

In some embodiments, the encryption firmware is obtained by encrypting the unencrypted firmware through an encryption algorithm based on an encryption key of the unencrypted firmware and an initialization parameter of the encryption algorithm, the encryption key of the unencrypted firmware is determined based on a root key and a key derivative parameter of the encrypted firmware, and the key derivative parameter of the encrypted firmware and the root key are randomly generated data sequences.

In some embodiments, the hardware security module 820 is specifically configured to determine whether the encryption algorithm is a preset encryption algorithm supported by the encryption/decryption chip, and decrypt the encrypted firmware by the encryption algorithm based on a decryption key of the encrypted firmware and an initialization parameter of the encryption algorithm to obtain decrypted firmware if the encryption algorithm is the preset encryption algorithm supported by the encryption/decryption chip.

In some embodiments, the multi-stage certificate includes a root certificate, an intermediate certificate that is a next stage certificate of the root certificate, and a leaf certificate that is a next stage certificate of the intermediate certificate, each stage of the multi-stage certificate includes a public key of each stage of certificate and a signature of each stage of certificate, the hardware security module 820 is specifically configured to obtain a hash value of the root public key and verify the public key of the root certificate based on the hash value of the root public key, verify the signature of the root certificate based on the public key of the root certificate if the public key of the root certificate is verified, verify the signature of the intermediate certificate and the signature of the leaf certificate if the signature of the root certificate is verified, and determine that the multi-stage certificate is verified if both the signature of the intermediate certificate and the signature of the leaf certificate are verified.

In some embodiments, each level of the multi-level certificate further comprises a public key hash value of a next level of the certificate corresponding to each level of the certificate, the hardware security module 820 is specifically configured to verify the public key of the intermediate certificate based on the public key hash value of the intermediate certificate in the root certificate if the signature of the root certificate passes the verification, verify the signature of the intermediate certificate based on the public key of the intermediate certificate if the public key of the intermediate certificate passes the verification, verify the public key of the leaf certificate based on the public key hash value of the leaf certificate in the intermediate certificate if the signature of the intermediate certificate passes the verification, and verify the signature of the leaf certificate based on the public key of the leaf certificate if the public key of the leaf certificate passes the verification.

As shown in fig. 8, the encryption/decryption chip 800 further includes a processor core 830.

In some embodiments, hardware security module 820 is specifically configured to send firmware-passing verification information and decryption firmware to processor core, and processor core 830 is configured to initiate decryption of firmware if the firmware-passing verification information is received.

The description of the apparatus embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. In some embodiments, the functions or modules included in the apparatus provided by the embodiments of the present application may be used to perform the methods described in the foregoing method embodiments, and for technical details that are not disclosed in the embodiments of the apparatus of the present application, reference should be made to the description of the embodiments of the method of the present application.

It should be noted that, in the embodiment of the present application, if the above-mentioned verification method of firmware data is implemented in the form of a software functional module, and sold or used as a separate product, the verification method may also be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or some of contributing to the related art may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the methods described in the embodiments of the present application. The storage medium includes various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

The embodiment of the application provides a computer device, which comprises a memory and an encryption and decryption chip, wherein the memory stores a computer program which can run on the encryption and decryption chip, and the encryption and decryption chip realizes part or all of the steps in the method when executing the program.

The embodiment of the application provides a computer readable storage medium, on which a computer program is stored, which when executed by an encryption and decryption chip, implements part or all of the steps of the method. The computer readable storage medium may be transitory or non-transitory.

The embodiment of the application provides a computer program, which comprises computer readable codes, wherein when the computer readable codes run in computer equipment, an encryption and decryption chip in the computer equipment executes part or all of the steps for realizing the method.

Embodiments of the present application provide a computer program product comprising a non-transitory computer-readable storage medium storing a computer program which, when read and executed by a computer, performs some or all of the steps of the above-described method. The computer program product may be realized in particular by means of hardware, software or a combination thereof. In some embodiments, the computer program product is embodied as a computer storage medium, and in other embodiments, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

It should be noted herein that the above description of various embodiments is intended to emphasize the differences between the various embodiments, and that the same or similar features may be referred to each other. The above description of apparatus, storage medium, computer program and computer program product embodiments is similar to that of method embodiments described above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus, the storage medium, the computer program and the computer program product of the present application, reference should be made to the description of the embodiments of the method of the present application.

Fig. 9 is a schematic diagram of a hardware entity of a computer device according to an embodiment of the present application, where, as shown in fig. 9, the hardware entity of the computer device 900 includes an encryption/decryption chip 901, a communication interface 902, and a memory 903, where:

The encryption/decryption chip 901 performs the steps of the method for verifying the firmware data described above when executing the program. The encryption and decryption chip 901 generally controls the overall operation of the computer device 900.

The communication interface 902 may enable the computer device to communicate with other terminals or servers over a network.

The memory 903 is configured to store instructions and applications executable by the encryption and decryption chip 901, and may also cache data (e.g., image data, audio data, voice communication data, and video communication data) to be processed or processed by each module in the chip 901 to be encrypted and decrypted and the computer device 900, and may be implemented by a FLASH memory (FLASH) or a random access memory (Random Access Memory, RAM). Data transmission can be performed among the encryption and decryption chip 901, the communication interface 902 and the memory 903 through the bus 904.

The embodiment of the application provides a computer storage medium, which stores one or more programs, and the one or more programs can be executed by one or more encryption and decryption chips to realize the steps of the method for verifying firmware data in any embodiment.

It should be noted here that the description of the storage medium and the device embodiments above is similar to the description of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and the apparatus of the present application, please refer to the description of the method embodiments of the present application.

The encryption and decryption chip may be at least one of an Application SPECIFIC INTEGRATED Circuit (ASIC), a digital signal encryption and decryption chip (DIGITAL SIGNAL Processor, DSP), a digital signal processing device (DIGITAL SIGNAL Processing Device, DSPD), a programmable logic device (Programmable Logic Device, PLD), a field programmable gate array (Field Programmable GATE ARRAY, FPGA), a central encryption and decryption chip (Central Processing Unit, CPU), a controller, a microcontroller, and a micro-encryption and decryption chip. It is understood that the electronic device for implementing the encryption and decryption chip function may be other electronic devices, and the embodiment of the application is not limited specifically.

The computer storage medium/Memory may be a Read Only Memory (ROM), a programmable Read Only Memory (Programmable Read-Only Memory, PROM), an erasable programmable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), an electrically erasable programmable Read Only Memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ-Only Memory, EEPROM), a magnetic random access Memory (Ferromagnetic Random Access Memory, FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a compact disk Read Only Memory (Compact Disc Read-Only Memory, CD-ROM), or any combination thereof, and may be any terminal including one or more of the above, such as a mobile phone, a computer, a tablet device, a personal digital assistant, or the like.

The foregoing is merely an embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application.

Claims

1. A method of encrypting firmware data for application to a first computing device, the method comprising:

generating random key derivative parameters, and calculating the key derivative parameters and a root key based on a key derivative algorithm to obtain an encryption key of unencrypted firmware;

Encrypting the unencrypted firmware by an encryption algorithm based on an encryption key of the unencrypted firmware and an initialization parameter of the encryption algorithm to obtain encrypted firmware;

Determining a first hash value based on the encrypted firmware and an encrypted field of the encrypted firmware;

And generating a certificate chain based on the encryption firmware, the first hash value, an encryption field of the encryption firmware and the multi-stage certificate, wherein the encryption field of the encryption firmware comprises the encryption algorithm, an initialization parameter of the encryption algorithm and the key derivation parameter.

2. The method according to claim 1, wherein the method further comprises:

And sending the certificate chain to an encryption and decryption chip in the second computing equipment, wherein the encryption and decryption chip is used for checking and decrypting the encryption firmware in the certificate chain based on the first hash value and the encryption field of the encryption firmware and obtaining decryption firmware.

3. The verification method of the firmware data is characterized by being applied to an encryption and decryption chip, and comprises the following steps:

The method comprises the steps of obtaining a certificate chain to be verified and verifying the certificate chain, wherein the certificate chain comprises a multi-stage certificate, encryption firmware and encryption fields of the encryption firmware, and the encryption fields of the encryption firmware comprise an encryption algorithm, initialization parameters of the encryption algorithm and key derivation parameters;

Determining a second hash value based on the encrypted firmware and an encrypted field of the encrypted firmware if the multi-level certificate passes the verification;

Determining a decryption key of the encrypted firmware based on a root key and a key derivation parameter of the encrypted firmware when the second hash value is equal to a first hash value corresponding to the encrypted firmware and an encryption field of the encrypted firmware in a leaf certificate of the multi-stage certificate;

and decrypting the encrypted firmware by the encryption algorithm based on the decryption key of the encrypted firmware and the initialization parameter of the encryption algorithm to obtain decrypted firmware.

4. A method according to claim 3, wherein the encryption firmware is obtained by encrypting the unencrypted firmware by the encryption algorithm based on an encryption key of the unencrypted firmware and an initialization parameter of the encryption algorithm;

the encryption key of the unencrypted firmware is determined based on the root key and key derivation parameters of the encrypted firmware;

the key derivation parameters of the encryption firmware and the root key are randomly generated data sequences.

5. A method according to claim 3, wherein decrypting the encrypted firmware by the encryption algorithm based on a decryption key of the encrypted firmware and an initialization parameter of the encryption algorithm to obtain decrypted firmware comprises:

determining whether the encryption algorithm is a preset encryption algorithm supported by the encryption and decryption chip;

And under the condition that the encryption algorithm is a preset encryption algorithm supported by the encryption and decryption chip, decrypting the encryption firmware by the encryption algorithm based on a decryption key of the encryption firmware and an initialization parameter of the encryption algorithm to obtain the decryption firmware.

6. The method of any of claims 3 to 5, wherein the multi-level certificate comprises a root certificate, an intermediate certificate that is a next level certificate to the root certificate, and a leaf certificate that is a next level certificate to the intermediate certificate;

The verifying the certificate chain comprises the following steps:

Obtaining a hash value of a root public key, and verifying the public key of the root certificate based on the hash value of the root public key;

under the condition that the public key of the root certificate passes the verification, verifying the signature of the root certificate based on the public key of the root certificate;

Under the condition that the signature of the root certificate passes the verification, verifying the signature of the intermediate certificate and the signature of the leaf certificate;

And determining that the multi-stage certificates pass the verification under the condition that the signatures of the intermediate certificates and the signatures of the leaf certificates pass the verification.

7. The method of claim 6, wherein each level of the multi-level certificate further comprises a public key hash value of a next level of certificate corresponding to the each level of certificate, wherein verifying the signature of the intermediate certificate and the signature of the leaf certificate if the signature of the root certificate passes the verification comprises:

Under the condition that the signature of the root certificate passes the verification, verifying the public key of the intermediate certificate based on the public key hash value of the intermediate certificate in the root certificate;

Under the condition that the public key of the intermediate certificate passes the verification, verifying the signature of the intermediate certificate based on the public key of the intermediate certificate;

Under the condition that the signature of the intermediate certificate passes the verification, verifying the public key of the leaf certificate based on the public key hash value of the leaf certificate in the intermediate certificate;

In the event that the public key of the leaf certificate passes verification, the signature of the leaf certificate is verified based on the public key of the leaf certificate.

8. The method according to any one of claims 3 to 5, further comprising:

starting the decryption firmware under the condition that the decryption firmware is obtained;

and refusing to start the decryption firmware under the condition that any one of the multi-stage certificates is not checked or the first hash value is not equal to the second hash value.

9. The encryption and decryption chip is characterized by comprising a hardware security module and a one-time programmable memory, wherein the one-time programmable memory is used for storing a root key, and the hardware security module is used for realizing the steps in the method according to any one of claims 3 to 8 based on the root key.

10. An encryption and decryption system is characterized by comprising a first computing device, a second computing device and a third computing device, wherein an encryption and decryption chip is arranged in the second computing device, the encryption and decryption chip comprises a hardware security module,

The first computing device is configured to implement the steps of the method of claim 1 or 2, and the encryption/decryption chip is configured to implement the steps of the method of any one of claims 3 to 8;

the third computing device is used for generating a root key and burning the root key into the one-time programmable memory of the hardware security module.