Chip safe starting method and device, chip and electronic equipment

Abstract

The invention discloses a chip safe starting method and device, a chip and electronic equipment, and the method comprises the steps: determining a first hash value of a public key in a self-signature certificate, carrying out the consistency judgment of the first hash value and a pre-stored second hash value of the public key, and determining the validity of the public key; then verifying the validity of the self-signature certificate, that is, performing hash operation on the received self-signature certificate, determining a second digest value, and performing consistency judgment according to a first digest value and the second digest value obtained by decrypting ciphertext digest information, so as to determine the validity of the self-signature certificate; verifying the validity of the chip program, namely determining a third hash value of the chip program, performing consistency judgment on the third hash value and a pre-stored fourth hash value of the chip program, and determining the validity of the chip program; and finally, when the validity of the public key, the validity of the self-signature certificate and the validity of the chip program are all valid, executing a chip starting function. And the starting safety of the chip is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and particularly relates to a chip security starting method and device, a chip and an electronic device. BACKGROUND

[0002] The chip security starting technology of Internet of Things (IoT) products, also known as secure boot, is a technology that ensures that IoT devices are not affected by malicious software during the startup process. The main goal of this technology is to protect the integrity and confidentiality of the device during the startup process, preventing unauthorized modifications and tampering.

[0003] The secure boot of IoT devices usually relies on embedded security elements (such as Trusted Platform Module (TPM) or Secure Element) and secure boot firmware. These elements and firmware can verify the integrity and confidentiality of the device's hardware and software during the startup process. For example, they can check the device's bootloader, operating system and applications to ensure that they are all signed by a trusted entity.

[0004] With the increasing number of IoT devices and the expansion of application fields, the importance of secure boot technology is increasingly prominent. In many industries, such as smart home, industrial Internet of Things and medical Internet of Things, this technology is actively adopted to protect their devices and data. The secure boot technology of IoT products is a rapidly developing field, which plays a crucial role in protecting the security of IoT devices.

[0005] In the related art, the security of the system public key is generally verified by means of hash operation, but there is a risk that the program is maliciously read to find software and hardware vulnerabilities. Therefore, the existing chip security starting scheme still has the problem of poor security. SUMMARY

[0006] The present application provides a chip security starting method, device, chip and electronic device, to solve the problem of poor security of the existing chip security starting scheme.

[0007] In a first aspect, the present application provides a chip security starting method, which comprises:

[0008] Hashing the public key in the self-signed certificate to determine a first hash value; determining the validity of the public key by performing consistency judgment on the first hash value and a second hash value of the public key previously saved;

[0009] decrypt the received ciphertext digest information using the public key to obtain a first digest value; perform a hash operation on the received self-signed certificate to determine a second digest value; determine the validity of the self-signed certificate by performing consistency checking on the first digest value and the second digest value; wherein the ciphertext digest information is obtained by performing a hash operation on the self-signed certificate by a sending end to determine a first digest value, and encrypting the first digest value using a private key corresponding to the public key;

[0010] perform a hash operation on the chip program to determine a third hash value; determine the validity of the chip program by performing consistency checking on the third hash value and a fourth hash value of the chip program that is pre-stored;

[0011] If the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid, execute a chip start function, otherwise do not execute the chip start function.

[0012] In a second aspect, the present application provides a chip security start device, the device comprising:

[0013] a first determination module configured to perform a hash operation on a public key in a self-signed certificate to determine a first hash value; determine the validity of the public key by performing consistency checking on the first hash value and a second hash value of the public key that is pre-stored;

[0014] a second determination module configured to decrypt the received ciphertext digest information using the public key to obtain a first digest value; perform a hash operation on the received self-signed certificate to determine a second digest value; determine the validity of the self-signed certificate by performing consistency checking on the first digest value and the second digest value; wherein the ciphertext digest information is obtained by performing a hash operation on the self-signed certificate by a sending end to determine a first digest value, and encrypting the first digest value using a private key corresponding to the public key;

[0015] a third determination module configured to perform a hash operation on a chip program to determine a third hash value; determine the validity of the chip program by performing consistency checking on the third hash value and a fourth hash value of the chip program that is pre-stored;

[0016] a security start module configured to execute a chip start function if the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid, otherwise do not execute the chip start function.

[0017] In a third aspect, the present application provides a chip comprising: a processor configured to execute the method steps after the chip is powered on.

[0018] In a fourth aspect, the present application provides an electronic device, comprising: the chip; and at least one of the following devices connected with the chip: an external device for storage, a transmission device enabling the chip to communicate with one or more computing devices, and a terminal device enabling the chip to interact with a user.

[0019] The present application provides a chip security starting method and device, a chip and an electronic device. The method comprises: performing a hash operation on a public key in a self-signed certificate to determine a first hash value; determining the validity of the public key by performing consistency checking on the first hash value and a second hash value of the public key previously saved; decrypting received ciphertext digest information using the public key to obtain a first digest value; performing a hash operation on the received self-signed certificate to determine a second digest value; determining the validity of the self-signed certificate by performing consistency checking on the first digest value and the second digest value; wherein the ciphertext digest information is obtained by performing a hash operation on the self-signed certificate by a sending end to determine a first digest value, and encrypting the first digest value using a private key corresponding to the public key; performing a hash operation on a chip program to determine a third hash value; determining the validity of the chip program by performing consistency checking on the third hash value and a fourth hash value of the chip program previously saved; and if the validity of the public key, the validity of the self-signed certificate and the validity of the chip program are all valid, executing a chip starting function, otherwise not executing the chip starting function.

[0020] The above technical solution has the following advantages or beneficial effects:

[0021] In the present application, firstly, the validity of the public key in the self-signed certificate is verified, that is, the first hash value of the public key in the self-signed certificate is determined, the first hash value and the second hash value of the public key pre-stored are compared for consistency, and the validity of the public key is determined; then the validity of the self-signed certificate is verified, that is, the second digest value is determined by performing a hash operation on the received self-signed certificate, and the first digest value obtained by decrypting the ciphertext digest information and the second digest value are compared for consistency, and the validity of the self-signed certificate is determined; further, the validity of the chip program is verified, that is, the third hash value of the chip program is determined, and the third hash value and the fourth hash value of the chip program pre-stored are compared for consistency, and the validity of the chip program is determined; finally, when the validity of the public key, the validity of the self-signed certificate and the validity of the chip program are all valid, the chip startup function is executed, and if any of the above validities is invalid, the chip startup function is not executed. The chip security startup provided in the present application verifies the security of the public key, the security of the self-signed certificate and the security of the chip program, and then executes the chip startup function. Compared with the scheme of related art which only verifies the security of the system public key, the dimension of security verification is increased, the problem of risk of existence of program being maliciously read and then finding software and hardware vulnerabilities is avoided, and the security of chip startup is improved. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creating laborious work.

[0023] Figure 1 A digital signature and signature verification process diagram provided by the present application;

[0024] Figure 2 A chip security startup process diagram provided by the present application;

[0025] Figure 3 Another chip security startup process diagram provided by the present application;

[0026] Figure 4 A ROM security startup chain authentication flowchart provided by the present application;

[0027] Figure 5 A process diagram for decrypting a chip program provided by the present application;

[0028] Figure 6 A three-level key management diagram provided by the present application;

[0029] Figure 7 A ROM exclusive program area protection diagram provided by the present application;

[0030] Figure 8 An EFUSE life cycle transition process diagram is provided for the present application;

[0031] Figure 9 A hardware cryptography algorithm engine top-level block diagram is provided for the present application;

[0032] Figure 10 A chip security boot device structure diagram is provided for the present application;

[0033] Figure 11 A chip structure diagram is provided for the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose and implementation of the present application more clear, the following will combine the drawings in the exemplary embodiments of the present application to clearly and completely describe the exemplary embodiments of the present application. Obviously, the described exemplary embodiments are only a part of the embodiments of the present application, but not all the embodiments of the present application.

[0035] It should be noted that the brief description of the terms in the present application is only for the convenience of understanding the following described embodiments, and is not intended to limit the embodiments of the present application. Unless otherwise specified, these terms should be understood according to their ordinary and general meanings.

[0036] The terms "first", "second", "third" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit the specific order or sequence, unless otherwise specified. It should be understood that the terms used in this way can be interchanged under appropriate circumstances.

[0037] The terms "include" and "have" and any variations thereof are intended to cover but not exclusive inclusion, for example, a product or device including a series of components does not necessarily limit to all the components clearly listed, but can include other components not clearly listed or inherent to these products or devices.

[0038] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic or combination of hardware or / and software code capable of performing functions associated with that element.

[0039] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0040] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0041] Before introducing the secure chip boot method provided in the embodiments of this application, the technical background of the embodiments of this application will be described in detail below for ease of understanding. Secure chip boot technology, also known as secure boot, is a technology to ensure that IoT devices are not affected by malicious software during the boot process. The main goal of this technology is to protect the integrity and confidentiality of the device during the boot process and prevent unauthorized modification and tampering.

[0042] Secure boot technology involves the secure boot process of read-only memory (ROM). ROM secure boot is a technique that ensures a device is protected from malware during the boot process. Its primary goal is to protect the integrity and confidentiality of the device during boot, preventing unauthorized modification and tampering.

[0043] The basic principle of secure boot from ROM is as follows:

[0044] When a device boots up, the first thing executed is the boot loader stored in the ROM. This boot loader is called the first-stage boot loader, or Boot ROM.

[0045] The boot ROM verifies the integrity and confidentiality of the second-stage bootloader. The second-stage bootloader is typically stored in flash memory or another type of writable memory. This is usually achieved by comparing the digital signature of the second-stage bootloader with a signature pre-stored in some storage medium (such as EFUSE). Figure 1 A diagram illustrating the digital signature and verification process provided for this application. Figure 1As shown, the signing process is as follows: A hash operation is performed on the program to be signed to obtain a reference hash value; an asymmetric cryptographic algorithm signature is performed based on the reference hash value and the private key; the program signature and the program to be signed are stored in flash memory. The verification process is as follows: The program to be certified and the program signature are retrieved from the flash memory; a hash operation is performed on the program to be certified to obtain a program hash value; an asymmetric cryptographic algorithm signature verification is performed based on the program signature and the public key to obtain a reference hash value; the program hash value and the reference hash value are compared for consistency; if the comparison is successful, the program is certified; if the comparison fails, the program is not certified.

[0046] If the program's hash value matches the reference hash value, the Boot ROM loads and executes the second-stage bootloader. The signing and verification processes use asymmetric cryptography, also known as public-key cryptography, a method that uses two keys for encryption and decryption. These two keys are called the public key and the private key. The public key is used to encrypt data, and the private key is used to decrypt it. The public key can be publicly distributed, while the private key must be kept secret.

[0047] The main advantage of asymmetric cryptography is that it solves the key distribution problem because public keys can be distributed publicly without the need for a secure channel. Furthermore, asymmetric cryptography can also be used for digital signatures to verify the integrity and origin of data.

[0048] However, the main drawback of asymmetric cryptographic algorithms is their high computational cost and slow speed, making them unsuitable for encrypting and decrypting large amounts of data.

[0049] Common asymmetric cryptography algorithms include RSA, ElGamal, and ECC (Elliptic Curve Cryptography). RSA is the earliest and most widely used asymmetric cryptography algorithm. Its security is based on the difficulty of factoring large numbers. ECC, on the other hand, is based on the difficulty of the elliptic curve discrete logarithm problem. It can provide the same level of security with a shorter key length than RSA, and therefore is widely used in mobile and embedded devices.

[0050] The second-stage bootloader continues to verify the subsequent boot process, including the integrity and confidentiality of the operating system kernel and other critical system components.

[0051] The advantage of secure boot from a ROM is that, because the Boot ROM is stored in read-only memory, it cannot be modified, providing a fixed and trustworthy boot point for the device. However, this also means that if vulnerabilities exist in the code within the Boot ROM, those vulnerabilities cannot be fixed.

[0052] Based on the above considerations, this application provides a chip secure boot scheme with relatively good security. In this application, the validity of the public key in the self-signed certificate is first verified by determining the first hash value of the public key in the self-signed certificate, and then comparing the first hash value with the pre-saved second hash value of the public key to determine the validity of the public key. Next, the validity of the self-signed certificate is verified by performing a hash operation on the received self-signed certificate to determine the second digest value, and then comparing the first digest value obtained from the decrypted ciphertext digest information with the second digest value to determine the validity of the self-signed certificate. Then, the validity of the chip program is verified by determining the third hash value of the chip program, and then comparing the third hash value with the pre-saved fourth hash value of the chip program to determine the validity of the chip program. Finally, when the validity of the public key, the self-signed certificate, and the chip program are all valid, the chip boot function is executed; if any of the above validitys are invalid, the chip boot function is not executed. The chip secure boot provided in this application verifies the security of the public key, the security of the self-signed certificate, and the security of the chip program before executing the chip boot function. Compared with related technologies that only verify the security of the system public key, this adds a dimension of security verification, avoids the risk of the program being maliciously read and used to find software and hardware vulnerabilities, and improves the security of chip secure boot.

[0053] Figure 2 The schematic diagram of the secure boot process of the chip provided in this application includes the following steps:

[0054] S101: Perform a hash operation on the public key in the self-signed certificate to determine a first hash value; determine the validity of the public key by comparing the first hash value with a pre-saved second hash value of the public key;

[0055] S102: Decrypt the received ciphertext digest information using the public key to obtain a first digest value; perform a hash operation on the received self-signed certificate to determine a second digest value; determine the validity of the self-signed certificate by comparing the first digest value and the second digest value; wherein, the ciphertext digest information is obtained by the sending end performing a hash operation on the self-signed certificate to determine the first digest value, and encrypting the first digest value using the private key corresponding to the public key;

[0056] S103: Perform a hash operation on the chip program to determine a third hash value; determine the validity of the chip program by comparing the third hash value with the pre-saved fourth hash value of the chip program.

[0057] S104: If the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid, execute the chip boot function; otherwise, do not execute the chip boot function.

[0058] The secure boot method for chips provided in this application is executed by the on-chip processor, which runs the current-stage software after the chip is powered on. Figure 2 The steps are shown.

[0059] This application provides a scheme for secure chip booting via chained authentication, which significantly increases boot security and robustness. Chained authentication is a method for verifying digital self-signed certificates. Its basic principle is to verify the target certificate or program step by step through a series of trust relationships, starting from a known trusted entity (such as a certificate authority).

[0060] Chain authentication includes verifying the validity of the public key in the self-signed certificate, verifying the validity of the self-signed certificate itself, and verifying the validity of the chip program. Optionally, the verification process for the public key in the self-signed certificate is performed first. If the public key verification passes, the verification process for the self-signed certificate itself is performed. If the self-signed certificate verification passes, the verification process for the chip program itself is performed. If the chip program verification passes, the chip boot function is executed. If any of the above verifications fails, the chip boot function is not executed. The order of these verifications is not specified.

[0061] Specifically, the process of authenticating the public key in a self-signed certificate is as follows: A hash operation is performed on the public key in the self-signed certificate to determine the first hash value; the validity of the public key is determined by comparing the first hash value with a pre-saved second hash value of the public key. During chip startup, a hash operation is performed on the public key in the self-signed certificate, and the resulting hash value is used as the first hash value. The hash value of the pre-saved public key in the self-signed certificate is also retrieved, and this pre-saved hash value is used as the second hash value. The second hash value can be stored in a one-time programmable memory (EFUSE). A consistency check is performed on the first and second hash values ​​to determine the validity of the public key. That is, the first hash value and the second hash value are compared. If they are the same, the public key is considered valid, meaning the public key validity authentication has passed. If they are different, the public key is considered invalid, meaning the public key validity authentication has failed.

[0062] The validity authentication process for a self-signed certificate is as follows: The sending end performs a hash operation on the self-signed certificate to determine a first digest value. It then encrypts the first digest value using the private key corresponding to the public key in the self-signed certificate to obtain a ciphertext digest. This ciphertext digest and the self-signed certificate are sent to the receiving end. Upon receiving the ciphertext digest and the self-signed certificate, the receiving end decrypts the received ciphertext digest using the public key in the self-signed certificate to obtain the first digest value. It then performs a hash operation on the received self-signed certificate to determine a second digest value. The validity of the self-signed certificate is determined by comparing the first and second digest values. Specifically, if the first and second digest values ​​are the same, the self-signed certificate is considered valid, meaning the validity authentication has passed. If they are different, the self-signed certificate is considered invalid, meaning the validity authentication has failed.

[0063] The chip program validity authentication process is as follows: A hash operation is performed on the chip program to determine a third hash value; the validity of the chip program is determined by comparing the third hash value with a pre-saved fourth hash value. The chip program can be stored in flash memory. During chip startup, a hash operation is performed on the chip program, and the resulting hash value is used as the third hash value. The pre-saved hash value of the chip program is also retrieved and used as the fourth hash value. The fourth hash value can be stored in a self-signed certificate. A consistency check is performed between the third and fourth hash values ​​to determine the validity of the chip program. That is, the third and fourth hash values ​​are compared. If they are the same, the chip program is considered valid, meaning the chip program validity authentication has passed. If they are different, the chip program is considered invalid, meaning the chip program validity authentication has failed.

[0064] If the public key of the self-signed certificate, the self-signed certificate, and the chip program are all valid, the chip boot function is executed; otherwise, the chip boot function is not executed.

[0065] A self-signed certificate mainly contains the following information:

[0066] 1. Public information about the certificate owner: including name, email address, organization name, etc.

[0067] 2. Public Key: This is the certificate owner's public key, used to verify signatures and encrypt data.

[0068] 3. Validity period: The start and end dates of the certificate's validity.

[0069] 4. Serial number: A unique identifier for the certificate.

[0070] 5. Signature Algorithm: An identifier for the algorithm used to create a digital signature.

[0071] 6. Issuer information: In self-signed certificates, this is usually the same as the certificate owner's information.

[0072] 7. Digital signature: This is created using the certificate owner's private key and can be used to verify the authenticity and integrity of the certificate.

[0073] During secure boot, self-signed certificates are primarily used to verify the authenticity of the bootloader and operating system, ensuring that they have not been tampered with.

[0074] The ROM secure boot chain authentication process is as follows:

[0075] First, the validity of the self-signed certificate public key is verified. During the chip startup process, the public key hash value pre-stored in EFUSE is read, and the hash algorithm is used to calculate the public key hash value stored in the self-signed certificate. The two are compared to see if they are consistent, ensuring the integrity and validity of the public key.

[0076] The self-signed certificate is verified using verified public key information. This process uses asymmetric cryptographic algorithms to perform digital signature verification, ensuring the validity of the certificate content.

[0077] The chip program image stored in external Flash is decrypted using a symmetric cryptographic algorithm; the hash value of the decrypted image is calculated using a hash algorithm and compared with the image hash value stored in the self-signed certificate to ensure the integrity and validity of the chip program image.

[0078] In this application, the validity of the public key in the self-signed certificate is first verified by determining the first hash value of the public key in the self-signed certificate and comparing it with the second hash value of the pre-saved public key to determine the validity of the public key. Then, the validity of the self-signed certificate is verified by performing a hash operation on the received self-signed certificate to determine the second digest value and comparing it with the first digest value obtained from the decrypted ciphertext digest information to determine the validity of the self-signed certificate. Next, the validity of the chip program is verified by determining the third hash value of the chip program and comparing it with the fourth hash value of the pre-saved chip program to determine the validity of the chip program. Finally, if the validity of the public key, the self-signed certificate, and the chip program are all valid, the chip boot function is executed; if any of the above validitys are invalid, the chip boot function is not executed. The chip secure boot provided in this application verifies the security of the public key, the security of the self-signed certificate, and the security of the chip program before executing the chip boot function. Compared with related technologies that only verify the security of the system public key, this adds a dimension of security verification, avoids the risk of the program being maliciously read and used to find software and hardware vulnerabilities, and improves the security of chip boot.

[0079] Considering the risk of attackers exploiting vulnerabilities in older versions to compromise the system, this application proposes a software version rollback prevention check strategy to further enhance chip boot security. Specifically, if the validity of the public key, the self-signed certificate, and the chip program are all valid, before executing the chip boot function, the method further includes:

[0080] When an installation request for the system software within the chip is received, the version identification information carried in the installation request is obtained. Based on the version identification information and the saved version identification information of each installed version of the system software, it is determined whether the version identification information carried in the installation request is the version identification information of an old version of the system software. If not, the system software installation package carried in the installation request is obtained and the installation process is executed, and the chip boot function is executed. If yes, the installation process is not executed, and the chip boot function is not executed.

[0081] During chip startup, when an installation request for the on-chip system software is received, the version identifier information carried in the installation request is obtained, and the version identifier information of each installed version of the system software can be saved in EFUSE. Based on the version identifier information carried in the installation request and the saved version identifier information of each installed version of the system software, it is determined whether the version to be installed is an older version. Optionally, the version identifier information of each installed version of the system software is saved in EFUSE, and the corresponding installation time is recorded. For example, the version identifier information of the system installed on May 1st is version 1, the version identifier information of the system installed on May 5th is version 2, and the version identifier information of the system installed on May 10th is version 3. If the version identifier information carried in the current on-chip system software installation request is version 1 or version 2, then it is determined that the version identifier information carried in the installation request is the version identifier information of an older version of the system software. If the version identifier information carried in the current on-chip system software installation request is version 3 or version 4, etc., then it is determined that the version identifier information carried in the installation request is not the version identifier information of an older version of the system software.

[0082] If the version identifier information carried in the installation request is not that of an older version of the system software, the system software installation package carried in the installation request is obtained and the installation process is executed, along with the chip boot function. If the version identifier information carried in the installation request is that of an older version of the system software, the installation process is not executed, and the chip boot function is not executed. This avoids the risk of attackers exploiting vulnerabilities in older versions to attack the system.

[0083] Optionally, software version rollback prevention checks are implemented by maintaining a version counter in the EFUSE chip. This counter increments whenever the system software is upgraded to a new version. When the system attempts to install an older version of software, it checks the version counter. If the installed software version is lower than the counter's value, the system will refuse installation, preventing attackers from exploiting vulnerabilities in older versions to compromise the system.

[0084] Figure 3 Another schematic diagram of a secure chip boot process provided in this application includes the following steps:

[0085] S201: Perform a hash operation on the public key in the self-signed certificate to determine a first hash value; determine the validity of the public key by comparing the first hash value with a pre-saved second hash value of the public key;

[0086] S202: Decrypt the received ciphertext digest information using the public key to obtain a first digest value; perform a hash operation on the received self-signed certificate to determine a second digest value; determine the validity of the self-signed certificate by comparing the first digest value and the second digest value; wherein, the ciphertext digest information is obtained by the sending end performing a hash operation on the self-signed certificate to determine the first digest value, and encrypting the first digest value using the private key corresponding to the public key;

[0087] S203: Perform a hash operation on the chip program to determine a third hash value; determine the validity of the chip program by comparing the third hash value with a pre-saved fourth hash value of the chip program.

[0088] S204: When an installation request for the system software within the chip is received, the version identification information carried in the installation request is obtained; and the saved version identification information of each installed version of the system software is obtained.

[0089] S205: If the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid, and based on the version identification information carried in the installation request and the version identification information of each installed version of the system software stored, it is determined that the version identification information carried in the installation request is not the version identification information of the old version of the system software, the system software installation package carried in the installation request is obtained and the installation process is executed, and the chip boot function is executed; otherwise, the chip boot function is not executed.

[0090] The above method establishes a unique ROM secure boot trust chain, from the self-signed certificate all the way to the chip program. Only when all certificates, programs and software version checks are verified is the secure boot process considered valid. If any link has a problem, the chip cannot boot normally.

[0091] The process described above for calculating the hash value uses a hash algorithm, which is an algorithm that transforms an input of arbitrary length (also called a message) into a fixed-length output. The output is typically called a hash value or hash code. The main characteristics of a hash algorithm are: for the same input, it always produces the same output; for different inputs, it produces different outputs whenever possible.

[0092] Hash algorithms have wide applications in computer science and cryptography, including data retrieval, data integrity checking, cryptographic storage, and digital signatures. A key characteristic of hash algorithms is collision resistance, meaning it is computationally infeasible to find two distinct inputs that produce the same hash value. This property is crucial for cryptographic applications.

[0093] Figure 4The ROM secure boot chain authentication flowchart provided in this application includes the following steps:

[0094] S301: Chip power-on reset.

[0095] S302: Read the contents of EFUSE and obtain the public key hash value pubkey_hash_1 that is pre-stored in EFUSE.

[0096] S303: Calculate the hash value of the public key contained in the self-signed certificate using a hash algorithm to obtain pubkey_hash_2. Compare whether pubkey_hash_1 and pubkey_hash_2 are consistent. If they are, proceed to S304; otherwise, proceed to S308.

[0097] S304: Calculate the hash value of the self-signed certificate to obtain manifest_hash_1; verify the signature value with the public key to obtain manifest_hash_2; compare whether manifest_hash_1 and manifest_hash_2 are consistent. If they are, proceed to S305; otherwise, proceed to S308.

[0098] S305: Uses a symmetric cryptographic algorithm with 3-level key management to decrypt the encrypted chip program image.bin stored in Flash.

[0099] S306: Decrypt the encrypted chip program image.bin stored in Flash, calculate the hash value of image.bin to obtain image.bin_hash_1; obtain the pre-saved hash value image.bin_hash_2 from the self-signed certificate; compare image.bin_hash_1 and image.bin_hash_2 to see if they are consistent. If they are, proceed to S307; otherwise, proceed to S308.

[0100] S307: Add a software rollback prevention mechanism, which determines the size of the current software version image.version and the version efuse.version stored in EFUSE; if image.version ≥ efuse.version, modify efuse.version to match image.version and proceed to S309; ​​otherwise, proceed to S308.

[0101] S308: Secure boot authentication failed, image refused to execute.

[0102] S309: ROM proprietary program area protection function is enabled.

[0103] S310: Chip security boot authentication successful, chip program image executes normally.

[0104] In this application, to ensure the security of the chip program, the chip program is encrypted and stored in flash memory. The step of performing a hash operation on the chip program to determine the third hash value includes:

[0105] Obtain the encrypted chip program from the flash memory, decrypt the encrypted chip program using a symmetric cryptographic algorithm to obtain the decrypted chip program, and perform a hash operation on the decrypted chip program to determine a third hash value.

[0106] To ensure the security of key management and thus further guarantee the security of the chip program, in this application, the decryption of the encrypted chip program using a symmetric cryptographic algorithm includes:

[0107] Obtain the root key stored in the one-time programmable memory EFUSE, the first key stored in the read-only memory ROM, and the second and third keys stored in the self-signed certificate;

[0108] The root key, the first key, the second key, and the third key are encrypted using an encryption algorithm to obtain the target key;

[0109] The target key is used to decrypt the encrypted chip program using a symmetric cryptographic algorithm in Crypto Engines.

[0110] This application stores a root key in a one-time programmable memory (EFUSE). The root key is the core of the entire key management system and does not directly participate in the encryption and decryption of data or programs. A first key is stored in a read-only memory (ROM), and a second and third key are stored in a self-signed certificate. An encryption algorithm is used to encrypt the root key, the first key, the second key, and the third key to obtain the target key. Optionally, an advanced encryption standard (AES) or the Chinese national cryptographic algorithm (SM4) can be used to encrypt the root key, the first key, the second key, and the third key to obtain the target key. Then, the target key is used to decrypt the encrypted chip program using a symmetric cryptographic algorithm in the Crypto Engines hardware cryptographic algorithm engine to obtain the decrypted chip program; a hash operation is then performed on the decrypted chip program to determine the third hash value.

[0111] Figure 5 The schematic diagram of the chip program decryption process provided in this application includes the following steps:

[0112] S401: Obtain the root key stored in the one-time programmable memory EFUSE, the first key stored in the read-only memory ROM, and the second and third keys stored in the self-signed certificate;

[0113] S402: Encrypt the root key, the first key, the second key, and the third key using an encryption algorithm to obtain the target key;

[0114] S403: The target key is used to decrypt the encrypted chip program using a symmetric cryptographic algorithm in Crypto Engines.

[0115] To further ensure the security of key management, this application proposes a three-level key management scheme. Specifically, the root key, the first key, the second key, and the third key are encrypted using an encryption algorithm to obtain the target key, which includes:

[0116] The root key and the first key are encrypted using the encryption algorithm described above to obtain the first candidate key;

[0117] The first candidate key and the second key are encrypted using the encryption algorithm to obtain the second candidate key;

[0118] The second candidate key and the third key are encrypted using the encryption algorithm to obtain the target key.

[0119] Figure 6 A diagram illustrating the three-level key management system provided in this application is shown below. Figure 6 As shown, the root key and the first key are first encrypted using an encryption algorithm such as AES or SM4 to obtain the first candidate key. Then, the first and second candidate keys are encrypted using the same algorithm to obtain the second candidate key. Finally, the second and third candidate keys are encrypted using the same algorithm to obtain the target key. The target key is then used to decrypt the encrypted chip program using a symmetric cryptographic algorithm from Crypto Engines.

[0120] This refers to the symmetric cryptographic algorithm used for decrypting the chip program image during the secure boot process. It is a cryptographic method that uses the same key for both encryption and decryption. Symmetric cryptographic algorithms are mainly divided into two categories:

[0121] 1. Stream Cipher: A stream cipher is a method of encrypting a data stream bit by bit or byte by byte. The advantage of stream ciphers is their speed; however, using the same key to encrypt multiple messages can lead to security issues. Common stream cipher algorithms include RC4.

[0122] 2. Block Ciphers: Block ciphers are a method of dividing data into fixed-size blocks and then encrypting each block. The advantage of block ciphers is high security, but the encryption speed is relatively slow. Common block cipher algorithms include DES (Data Encryption Standard), 3DES (Triple Data Encryption), AES (Advanced Encryption Standard), and SM4 (Chinese national cryptographic algorithm).

[0123] Symmetric cryptography algorithms have applications in many scenarios, such as protecting data confidentiality in network communications or encrypting data in storage devices. Its main advantages are speed and low computational cost, making it suitable for encrypting and decrypting large amounts of data. However, its main disadvantage is the difficulty in key management and distribution, as the key needs to be securely shared between the communicating parties.

[0124] To address the difficulties in key management and distribution, this application proposes a three-level key management mechanism to increase key security and complexity.

[0125] The three-level key management system mainly includes EFUSE Init KEY, EK3, EK2, and EK1. Init KEY is the root key, EK3 is the first key, EK2 is the second key, and EK1 is the third key.

[0126] 1. Init KEY: Also known as the root key, it is the core of the entire key management system. It is stored in the secure EFUSE and does not directly participate in the encryption and decryption of data or programs.

[0127] 2. EK3\2\1: EK3 is stored in the ROM space, and EK2\1 is stored in the self-signed certificate. The lifespan of EK2\1 is usually shorter than that of the root key and needs to be replaced periodically.

[0128] 3. The Init KEY and EK3\2\1 use the AES / SM4 encryption algorithm in the hardware to generate the Final Key as the target key for program or data encryption and decryption. This Final Key is not visible in the software.

[0129] 4. The generated Final Key uses symmetric cryptography algorithms in Crypto Engines to encrypt and decrypt the data.

[0130] The advantage of Level 3 key management is that it can effectively protect the security of keys and prevent security risks caused by the leakage of the root key.

[0131] AES (Advanced Encryption Standard) is a symmetric encryption algorithm used to replace the original DES (Data Encryption Standard).

[0132] The characteristics of the AES algorithm are as follows:

[0133] 1. Symmetric encryption: AES is a symmetric encryption algorithm, which means that the same key is used for encryption and decryption.

[0134] 2. Key length: AES supports key lengths of 128, 192 and 256 bits.

[0135] 3. Encryption block size: The data block size of AES is fixed at 128 bits.

[0136] 4. Encryption process: The AES encryption process includes four steps: byte substitution (SubBytes), row shifting (ShiftRows), column mixing (MixColumns), and key addition (AddRoundKey). These four steps are performed in multiple rounds (the number of rounds depends on the key length).

[0137] 5. Security: The AES algorithm is extremely secure and has not been effectively cracked to date.

[0138] AES is widely used in various situations requiring data encryption, such as wireless network security, mobile payment, and secure communication.

[0139] The SM4 algorithm, officially known as the National Commercial Cryptographic Algorithm, is a symmetric encryption algorithm independently developed in my country and designed by the my country Institute of Cryptography. It is my country's national commercial cryptographic standard and a crucial infrastructure for the country's cryptographic industry. The SM4 algorithm is designed to prevent differential and linear attacks.

[0140] The basic characteristics of the SM4 algorithm are as follows:

[0141] 1. Key length: 128 bits.

[0142] 2. Group length: 128 bits.

[0143] 3. Encryption method: Block cipher, using block concatenation.

[0144] 4. Number of encryption rounds: 32 rounds.

[0145] 5. Encryption speed: Relatively slow, but highly secure.

[0146] The main application areas of the SM4 algorithm include: finance, e-commerce, wireless LAN, mobile communications, e-government, and network security.

[0147] The AES / SM4 algorithm has several modes, including the following:

[0148] 1. ECB (Electronic Codebook) mode: This is the simplest encryption mode. Each block is encrypted independently without complex operations. However, the disadvantage of this mode is that the same plaintext block will be encrypted into the same ciphertext block, which may be exploited by attackers.

[0149] 2. CBC (Cipher Block Chaining) mode: In this mode, each plaintext block is XORed with the previous ciphertext block before being encrypted. This avoids the problems of ECB mode, but if a block is lost during transmission, all subsequent blocks will be unable to be decrypted correctly.

[0150] 3. CFB (Cipher Feedback) mode: This is a self-synchronizing encryption mode. It divides the plaintext into blocks and then XORs each block with the previously encrypted ciphertext block.

[0151] 4. OFB (Output Feedback) mode: This is a streaming mode that transforms the algorithm into a streaming cipher that can generate a stream of keys.

[0152] 5. CTR (Counter) Mode: In this mode, an incrementing counter is encrypted, and the encrypted result of the counter is XORed with the plaintext to obtain the ciphertext. The advantage of this mode is that encryption and decryption can be performed in parallel, and errors in a single block will not affect other blocks.

[0153] Each mode has its own characteristics and applicable scenarios. Which mode to use depends on your specific needs.

[0154] In this application, to improve the security of the read-only memory (ROM), a proprietary program area protection scheme for the ROM is proposed. Specifically, a secure user storage area is defined in the ROM. After power-on reset, the software program in the secure user storage area is run. The protection function of the secure user storage area is enabled by setting the register flag bit configured in the software program, and the access address of the secure user storage area is stored in the one-time programmable memory (EFUSE).

[0155] In this application, a secure user storage area is defined in the read-only memory (ROM), and the access address of the secure user storage area is stored in the one-time programmable memory (EFUSE), thereby ensuring the security of the access address of the secure user storage area. Furthermore, after power-on reset, the software program in the secure user storage area is executed, and the function of setting register flags is written into the software program in the secure user storage area. Running the software program in the secure user storage area enables the protection function of the secure user storage area by setting the register flags configured in the software program. Optionally, the register flags can only be set once after power-on reset. For example, a register flag of 0 indicates that any access is allowed, and a register flag of 1 indicates that any access is not allowed. Therefore, after power-on reset, running the software program in the secure user storage area and setting the register flags to 1 enables the protection function of the secure user storage area.

[0156] If vulnerabilities exist in the code of the Boot ROM, these vulnerabilities cannot be fixed. Based on this potential risk, this application designs a protection scheme for the ROM's proprietary program area.

[0157] ROM access protection defines a secure user storage area in the ROM that is accessible after power-on reset. Software can enable protection for this area by setting the flag bit in the rom_jump_flag register. Once protection is enabled, the area becomes completely inaccessible. This protection is effective throughout the entire power-on time and cannot be revoked until the next reset.

[0158] The address space of the protected secure memory area is set via the chip's EFUSE function. This is a static setting that takes effect automatically upon power-on and requires no software configuration. Enabling the protection requires dynamic software enabling. A typical use of the secure memory area is to store code and data that run only once per power-on, such as secure boot code. Before jumping to the normal application area, the protection of the secure memory area can be enabled. After the jump, the secure boot code and the data it uses on Flash (such as keys) become completely invisible, thus completely isolating the boot code from the application and preventing the application from accessing any sensitive code and data used during the boot phase.

[0159] Figure 7 This application provides a schematic diagram of ROM proprietary program area protection, such as... Figure 7As shown, a secure user memory area is defined in the ROM at the address rom_prot_start / end_addr. The ROM program configures the register flag rom_jump_flag, which can only be configured once after power-on reset. rom_jump_flag = 0 means any access is allowed, and rom_jump_flag = 1 means any access is not allowed. The secure user memory area address rom_prot_start / end_addr is stored in EFUSE. All access to the remaining space in the ROM, excluding the secure user memory area, is permitted.

[0160] In addition, to facilitate the protection of data stored in the one-time programmable memory EFUSE, the method further includes:

[0161] The lifecycle of the one-time programmable memory EFUSE is divided into chip manufacturing stage, equipment production stage, equipment deployment stage, and equipment recycling / destruction stage; corresponding protection permissions are configured for the execution functions of each stage of the lifecycle.

[0162] The EFUSE (or electronic fuse) mentioned in this application is a technology used in integrated circuits to store small amounts of data. This data typically includes device configuration information, security keys, etc. A key feature of EFUSE is that once data is written, it cannot be changed or deleted; therefore, it is often used to store data requiring long-term protection. To address the high security requirements of EFUSE-stored data, this application defines four EFUSE lifecycle states, protecting keys and confidential data according to different lifecycle stages. Figure 8 The EFUSE lifecycle transition process diagram provided in this application is as follows: Figure 8 As shown, the four lifecycles are described below:

[0163] 1. Chip Manufacturing (CM) stage.

[0164] This status indicates that the chip is with the chip manufacturer and has not been transferred to the equipment manufacturer. All debugging and testing functions are enabled, including sensitive information sections of the chip.

[0165] 2. Equipment Manufacturing (DM) stage.

[0166] In this state, the chip is on the device manufacturer's (OEM) production line. Internal chip testing functions (internal scan, mbist) should be disabled. However, chip interface and external testing functions should be provided to the OEM. The OEM is responsible for providing all security information, including the secure boot public key hash, secure debug public key hash, device ID, and device root key. Before transitioning to the next phase, the OEM should complete all OEM information writes (including the device ID, device root key, and sensitive information stored in the secure area) and update the lifecycle to the DD phase.

[0167] 3. Device Deployment (DD) phase.

[0168] In this state, the device is in normal operation. All security features should be enabled. EFUSE disables write access to some secure areas. Secure boot and secure debugging are mandatory; only limited debugging functionality is enabled.

[0169] 4. Device Revocation (DR) stage.

[0170] This status indicates that the chip has been sent back to the manufacturer for fault analysis. Secure boot and secure debugging are mandatory at this stage. To protect device manufacturer information and device keys, user-defined security data in EFUSE must be erased, making it inaccessible to anyone. The lifecycle transition should be unidirectional and irreversible.

[0171] Table 1 lists the access permissions for EFUSE keys and confidential information at different lifecycle stages, as follows:

[0172]

[0173] N-: Non-secure master can perform operations, meaning that an insecure host can perform operations.

[0174] S-: Secure master can perform operations, meaning that a secure host can perform operations;

[0175] RW: Write and read operation;

[0176] RO: Read only operation, refers to read-only operation;

[0177] INV: Invalidate the data, means to invalidate the data;

[0178] N / A: Not accessible to any master means that it cannot be operated on by any host.

[0179] Figure 9 The top-level block diagram of the hardware cryptographic algorithm engine provided in this application is as follows: Figure 9 As shown, the cryptographic algorithm engines mentioned in this application are described as follows:

[0180] Crypto Engine: Hardware Cryptographic Algorithm Engine

[0181] The symmetric cryptography algorithms, asymmetric cryptography algorithms, and hash algorithms mentioned in this application are all implemented through a proprietary hardware cryptographic algorithm engine in the chip, which is crucial for the chip's secure boot process.

[0182] Crypto Engine, as a security component of the system, specifically includes the following functions:

[0183] 1. Symmetric cryptography algorithms: AES-ECB / CBC / CTR / CBC-MAC / CMAC / CCM / GCM (key size 128-bit, 192-bit and 256-bit);

[0184] 2. Symmetric cryptographic algorithms: SM4-ECB / CBC / CTR / CBC-MAC / CMAC / CCM / GCM;

[0185] 3. Asymmetric cryptographic algorithms: RSA 1024 / 2048 / 3072 / 4096 and ECCP 192 / 224 / 256 / 384 / 512 / 521;

[0186] 4. Asymmetric cryptographic algorithm: SM2;

[0187] 5. Digest algorithms: SHA1 / 224 / 256.

[0188] 6. Digest Algorithm: SM3;

[0189] 7. True random number generator TRNG;

[0190] 8. AES KEY Level 3 Key Management.

[0191] Figure 10 The schematic diagram of the chip secure boot device provided in this application includes:

[0192] The first determining module 501 is used to perform a hash operation on the public key in the self-signed certificate to determine a first hash value; and to determine the validity of the public key by performing a consistency judgment on the first hash value and a pre-saved second hash value of the public key.

[0193] The second determining module 502 is used to decrypt the received ciphertext digest information using the public key to obtain a first digest value; perform a hash operation on the received self-signed certificate to determine a second digest value; and determine the validity of the self-signed certificate by performing a consistency judgment on the first digest value and the second digest value; wherein, the ciphertext digest information is obtained by the sending end performing a hash operation on the self-signed certificate to determine the first digest value, and encrypting the first digest value using the private key corresponding to the public key;

[0194] The third determining module 503 is used to perform a hash operation on the chip program to determine a third hash value; and to determine the validity of the chip program by performing a consistency check between the third hash value and the pre-saved fourth hash value of the chip program.

[0195] The secure boot module 504 is used to execute the chip boot function if the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid; otherwise, the chip boot function is not executed.

[0196] The device further includes:

[0197] The software rollback prevention module 505 is used to, when receiving an installation request for the system software within the chip, obtain the version identification information carried in the installation request; based on the version identification information and the stored version identification information of each installed version of the system software, determine whether the version identification information carried in the installation request is the version identification information of an old version of the system software; if not, obtain the system software installation package carried in the installation request and execute the installation process, and execute the chip boot function; if yes, do not execute the installation process and do not execute the chip boot function.

[0198] The third determining module 503 is specifically used to obtain the encrypted chip program in the flash memory, decrypt the encrypted chip program using a symmetric cryptographic algorithm to obtain the decrypted chip program, and perform a hash operation on the decrypted chip program to determine the third hash value.

[0199] The third determining module 503 is further configured to obtain the root key stored in the one-time programmable memory EFUSE, the first key stored in the read-only memory ROM, and the second and third keys stored in the self-signed certificate; encrypt the root key, the first key, the second key, and the third key using an encryption algorithm to obtain the target key; and decrypt the encrypted chip program using the target key using a symmetric cryptographic algorithm in the hardware cryptographic algorithm engine Crypto Engines.

[0200] The third determining module 503 is further configured to encrypt the root key and the first key using the encryption algorithm to obtain a first candidate key; encrypt the first candidate key and the second key using the encryption algorithm to obtain a second candidate key; and encrypt the second candidate key and the third key using the encryption algorithm to obtain the target key.

[0201] The secure boot module 504 is also used to define a secure user storage area in the read-only memory ROM, run the software program in the secure user storage area after power-on reset, enable the protection function of the secure user storage area by setting the register flag bit configured in the software program, and store the access address of the secure user storage area in the one-time programmable memory EFUSE.

[0202] The secure boot module 504 is also used to divide the lifecycle of the one-time programmable memory EFUSE into a chip manufacturing stage, a device production stage, a device deployment stage, and a device recycling / destruction stage; and to configure corresponding protection permissions for the execution functions of each stage of the lifecycle.

[0203] In accordance with the chip secure boot method provided above, this application also provides a chip. Figure 11 The diagram shown is an exemplary structural schematic of a chip provided in this application. (Refer to...) Figure 11 Chip 800 includes processor 810. After the chip is powered on, processor 810 runs the current stage software to execute the steps in the chip safe boot method described above, thereby ensuring the security of chip boot.

[0204] Chip 800 may also include at least one storage unit 820 and a bus 830 connecting different system components (including storage unit 820 and processor 810). Storage unit 820 may include a readable medium in the form of volatile memory cells, such as random access memory (RAM) 8201 and / or cache memory 8202 for storing a bootloader, and may further include read-only memory (ROM) 8203 for storing a boot program. Storage unit 820 may also include dynamic random access memory / tightly coupled memory 8204 storing a set of program modules 8205, including but not limited to: one or more application programs and program data.

[0205] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0206] Chip 800 can also communicate with one or more external devices 700 (e.g., off-chip flash memory for storage), one or more terminal devices (e.g., displays) that enable users to interact with chip 800, and / or any transmission device (e.g., a universal asynchronous receiver / transmitter) that enables chip 800 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 850, which is connected to bus 830. I / O interface 850 can be the chip's master interface and / or slave interface. Furthermore, chip 800 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 860 connected to bus 830. These various communication methods, in some examples, enable chip 800 to have multiple loading methods for the bootloader.

[0207] Corresponding to the chip provided above, embodiments of the present invention also provide an electronic device, the electronic device comprising: the chip provided above; and at least one of the following devices connected to the chip: an external device for storage (e.g., a security digital card), a transmission device (e.g., a universal asynchronous receiver / transmitter) enabling the chip to communicate with one or more computing devices, and a terminal device (e.g., a display) enabling the chip to interact with a user.

[0208] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0209] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for securely booting a chip, the method comprising: The method comprises: hashing the public key in the self-signed certificate to determine a first hash value; determining the validity of the public key by consistency checking the first hash value and a second hash value of the public key previously saved; decrypting the received ciphertext digest information using the public key to obtain a first digest value; hashing the received self-signed certificate to determine a second digest value; determining the validity of the self-signed certificate by consistency checking the first digest value and the second digest value; wherein the ciphertext digest information is obtained by hashing the self-signed certificate at the sending end to determine a first digest value, and encrypting the first digest value using a private key corresponding to the public key; hashing the chip program to determine a third hash value; determining the validity of the chip program by consistency checking the third hash value and a fourth hash value of the chip program previously saved; if the validity of the public key, the validity of the self-signed certificate and the validity of the chip program are all valid, executing the chip startup function, otherwise not executing the chip startup function.

2. The method of claim 1, wherein, If the validity of the public key, the validity of the self-signed certificate and the validity of the chip program are all valid, before executing the chip startup function, the method further comprises: when receiving an installation request of a chip internal system software, obtaining version identification information carried by the installation request; determining whether the version identification information carried by the installation request is version identification information of an old version system software according to the version identification information and saved version identification information of each installed version of the system software, if not, obtaining a system software installation package carried by the installation request and executing an installation process, and executing the chip startup function, if yes, not executing the installation process and not executing the chip startup function.

3. The method of claim 1, wherein, The hashing the chip program to determine a third hash value comprises: obtaining the encrypted chip program in the flash memory, decrypting the encrypted chip program using a symmetric cryptography algorithm to obtain a decrypted chip program; hashing the decrypted chip program to determine a third hash value.

4. The method of claim 3, wherein, The decrypting the encrypted chip program using a symmetric cryptography algorithm comprises: obtaining a root key saved in the EFUSE, a first key saved in the ROM, a second key and a third key saved in the self-signed certificate; encrypting the root key, the first key, the second key and the third key using an encryption algorithm to obtain a target key; The target key decrypts the encrypted chip program using a symmetric cryptography algorithm in the Crypto Engines.

5. The method of claim 4, wherein, The encrypting the root key, the first key, the second key and the third key using an encryption algorithm to obtain a target key comprises: encrypting the root key and the first key using the encryption algorithm to obtain a first candidate key; The first candidate key and the second key are encrypted by using the encryption algorithm to obtain a second candidate key; The second candidate key and the third key are encrypted by using the encryption algorithm to obtain the target key.

6. The method of claim 4, wherein, The method further comprises: Defining a secure user storage area in the read-only memory (ROM), running a software program in the secure user storage area after power-on reset, enabling the protection function of the secure user storage area by setting a register flag bit configured in the software program, and storing the access address of the secure user storage area in the one-time programmable memory (EFUSE).

7. The method of claim 4, wherein, The method further comprises: Dividing the life cycle of the one-time programmable memory (EFUSE) into a chip manufacturing stage, a device production stage, a device deployment stage, and a device recycling / destroying stage; configuring corresponding protection permissions for each stage of the life cycle according to the execution functions of each stage.

8. A chip security booting apparatus, characterized by comprising: The device comprises: A first determination module configured to perform a hash operation on a public key in a self-signed certificate to determine a first hash value, and determine the validity of the public key by performing consistency checking on the first hash value and a second hash value of the public key previously saved; A second determination module configured to decrypt received ciphertext digest information using the public key to obtain a first digest value, perform a hash operation on the received self-signed certificate to determine a second digest value, and determine the validity of the self-signed certificate by performing consistency checking on the first digest value and the second digest value; wherein the ciphertext digest information is obtained by performing a hash operation on a self-signed certificate by a sending end to determine a first digest value, and encrypting the first digest value using a private key corresponding to the public key; A third determination module configured to perform a hash operation on a chip program to determine a third hash value, and determine the validity of the chip program by performing consistency checking on the third hash value and a fourth hash value of the chip program previously saved; A secure startup module configured to execute a chip startup function if the validity of the public key, the validity of the self-signed certificate, and the validity of the chip program are all valid, and not to execute the chip startup function otherwise.

9. A chip, characterized by The method comprises: A processor configured to execute the method steps of any one of claims 1-7 after the chip is powered on.

10. An electronic device, comprising: The chip comprises: The chip of claim 9; and at least one of the following devices connected to the chip: an external device for storage, a transmission device enabling the chip to communicate with one or more computing devices, and a terminal device enabling the chip to interact with a user. ​

Images