CN108021812B - Method and device for safe booting of a chip - Google Patents

Abstract

The invention discloses a safe starting method and a safe starting device of a chip, wherein the safe starting method comprises the following steps: determining a safe starting type; reading a first type key corresponding to the safety starting type from the electric fuse; processing security verification corresponding to the security starting type by using the first type of secret key in the process of starting a chip; the effect of customizing the personalized security chip for the target user through EFUSE curing is achieved, the development cost of the chip is saved, and the universality of the chip is improved.

Description

Method and device for safe booting of a chip

technical field

The invention relates to a chip safe booting technology, in particular to a chip safe booting method and device.

Background technique

The embedded chip is the core of the embedded system and is the hardware unit that controls and assists the operation of the system. The secure startup of the embedded chip is the premise to ensure the subsequent work of the entire chip. For this reason, a safe way to start the chip is required.

At present, only a single secure boot solution is supported for the same chip in design, so different chips need to be designed to support the corresponding secure boot solution for different secure boot requirements. .

SUMMARY OF THE INVENTION

In order to solve the above technical problems, embodiments of the present invention provide a method and device for safely booting a chip.

The secure booting method of the chip provided by the embodiment of the present invention includes:

Determine the type of secure boot;

read the first type key corresponding to the secure boot type from the electrical fuse;

In the process of booting the chip, the first type of key is used to process the security verification corresponding to the secure boot type.

In this embodiment of the present invention, before determining the secure boot type, the method further includes:

solidifying the first type of keys corresponding to different security activation types in the electric fuse;

Wherein, the first type of key is stored in the electric fuse in a plaintext manner or in a hash manner according to the corresponding secure boot type.

In the embodiment of the present invention, in the process of booting the chip, the first type of key is used to process the security verification corresponding to the secure boot type, including:

When the chip is powered on, the instructions are executed sequentially from the code solidified in the read-only memory;

In the process of executing the instruction, the second-level boot (BOOT) is checked by using the first-type key;

After the verification is passed, the second level BOOT is executed.

In the embodiment of the present invention, the method further includes:

Use the first type of key to verify the image header information of the secondary BOOT, and determine whether the secondary BOOT code is decrypted after the verification is successful;

When the secondary BOOT code is not decrypted, the secondary BOOT code is decrypted according to the obtained second type key.

In the embodiment of the present invention, the method further includes:

According to the preset address, the second type key is read from the electric fuse.

The secure boot device for a chip provided by the embodiment of the present invention includes:

Type determination module, used to determine the type of secure boot;

A data reading module for reading the first type key corresponding to the security boot type from the electric fuse

The security verification module is configured to use the first type of key to process security verification corresponding to the secure boot type in the process of booting the chip.

In the embodiment of the present invention, the device further includes:

A data curing module for curing first type keys corresponding to different security boot types in the electric fuse; wherein the first type keys are stored in the electric fuse according to the corresponding security boot types It is stored in plaintext or stored in hash.

In the embodiment of the present invention, the security verification module is specifically used to: after the chip is powered on, execute instructions sequentially from the code solidified in the read-only memory; in the process of executing the instructions, use the first type of key Verify the second-level BOOT; after the verification is passed, execute the second-level BOOT.

In the embodiment of the present invention, the security verification module is specifically configured to: verify the image header information of the secondary BOOT by using the first type key, and determine whether the secondary BOOT code is decrypted after the verification is successful; When the secondary BOOT code is not decrypted, decrypt the secondary BOOT code according to the obtained second type key.

In the embodiment of the present invention, the data reading module is further configured to read the second type key from the electric fuse according to a preset address.

In the technical solution of the embodiment of the present invention, the secure boot type is determined; the first type key corresponding to the secure boot type is read from the electric fuse; in the process of starting the chip, the first type key is used The key handles the security verification corresponding to the secure boot type. By adopting the technical solutions of the embodiments of the present invention, after the security requirements of the chip market are determined, the required security solutions are solidified into the electric fuse (EFUSE). After the chip is started, the security scheme will be judged step by step according to the solidified value of EFUSE, and corresponding operations such as signature verification and decryption will be performed according to the security scheme. It achieves the effect of customizing a personalized security chip for target users through EFUSE curing, saving the development cost of the chip and improving the versatility of the chip.

Description of drawings

FIG. 1 is a schematic flowchart 1 of a method for safely booting a chip;

2 is a second schematic flowchart of a method for safely booting a chip according to an embodiment of the present invention;

FIG. 3 is a third schematic flowchart of a method for safely booting a chip according to an embodiment of the present invention;

FIG. 4 is a schematic structural diagram of a secure boot device for a chip according to an embodiment of the present invention.

Detailed ways

In order to understand the features and technical contents of the embodiments of the present invention in more detail, the implementation of the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

The secure booting of the chip generally includes the steps shown in Figure 1. Referring to Figure 1, the secure booting process of the chip includes the following steps:

Step 101: Solidify the RSA key in EFUSE.

In the embodiment of the present invention, the RSA key is referred to as the first type of key, and the Advanced Encryption Standard (AES, Advanced Encryption Standard) or Data Encryption Standard (DES, Data Encryption Standard) key is referred to as the second type of key.

Here, solidifying data in EFUSE means: programming the fuse in EFUSE by blowing, so as to write data in EFUSE by hardware. EFUSE Electromigration properties can be used to create much smaller fuse structures compared to older laser fusing techniques, using the on-chip voltage of the I/O circuit (typically 2.5V), a 10 mA for 200 microseconds A DC pulse is enough to program a single fuse.

Based on this, solidifying the RSA key in EFUSE means: writing the RSA key in EFUSE by means of hardware.

Step 102: After the chip is powered on, the M0 core starts to execute the instructions in sequence from the code solidified in the read-only memory (ROM, Read-Only Memory); reads the RSA key from EFUSE, performs second-level BOOT verification, and checks Execute secondary BOOT after passing.

Here, there is no AES or DES decryption for the secondary BOOT code. This is because AES or DES decryption needs to be implemented through software, which leads to low security of the preset key in the solidified BOOT code, and increases the amount of code and prolongs the Start Time.

Step 103 : After the M0 core starts the second-level BOOT, the following programs (such as m0_os, bl31, bl32, uboot) are verified using the RSA key; and AES or DES is decrypted by software.

Here, the AES or DES key needs to be saved by software, so it is possible for hackers to obtain the key through the source file of m0_os. For example, the code is developed by user A, and user A can find the place that may be the key by analyzing the image file , try to attack.

Step 104: After the A53 core is started, it starts executing instructions from bl31, starts bl32, and finally jumps to uboot.

Here, when the chip is not A53, it actually jumps directly to uboot from m0_os, without the process of bl31 and bl32.

Step 105: After uboot is started, use the RSA key to verify the Android image.

In the technical solutions of the embodiments of the present invention, after the security requirements of the chip market are determined, the required security solutions are solidified into EFUSE. After the chip is started, the security scheme will be judged step by step according to the solidified value of EFUSE, and corresponding operations such as signature verification and decryption will be performed according to the security scheme. It achieves the effect of customizing a personalized security chip for target users through EFUSE curing, saving the development cost of the chip and improving the versatility of the chip.

FIG. 2 is a second schematic flowchart of a secure booting method for a chip according to an embodiment of the present invention. As shown in FIG. 2 , the secure booting method for a chip includes the following steps:

Step 201: Determine the secure boot type.

In the embodiment of the present invention, before determining the secure boot type, the method further includes: solidifying the first type of keys corresponding to different secure boot types in the electric fuse;

Wherein, the first type of key is stored in the electric fuse in a plaintext manner or in a hash manner according to the corresponding secure boot type.

In the above solution, the first type of key may be an RSA key.

Step 202: Read the first type key corresponding to the secure boot type from the electrical fuse.

In the embodiment of the present invention, instead of simply reading the RSA key from the electrical fuse, the RSA key corresponding to the safe booting type is read from the electrical fuse according to the safe booting type. In addition, whether the RSA key is stored in plaintext or in hash (HASH) can be preset according to the type of secure boot.

Step 203: In the process of starting the chip, use the first type of key to process the security verification corresponding to the secure boot type.

In the embodiment of the present invention, in the process of booting the chip, the first type of key is used to process the security verification corresponding to the secure boot type, including:

When the chip is powered on, the instructions are executed sequentially from the code solidified in the read-only memory;

In the process of executing the instruction, the second-level boot BOOT is verified by using the first-type key;

After the verification is passed, the second level BOOT is executed.

In the embodiment of the present invention, in the process of booting the chip, using the first type of key to process the security verification corresponding to the secure boot type, further comprising:

Use the first type of key to verify the image header information of the secondary BOOT, and determine whether the secondary BOOT code is decrypted after the verification is successful;

When the secondary BOOT code is not decrypted, the secondary BOOT code is decrypted according to the obtained second type key.

Here, the second type of key may be an AES key or a DES key.

Based on the above solutions, the embodiments of the present invention support AES decryption or DES decryption of the BOOT code. Specifically, the information on whether to decrypt is obtained through the secondary BOOT image header information. Since this header information needs to be verified by RSA, the header information cannot be tampered with by hackers.

In addition, the second type of key is read through the following operation: according to a preset address, the second type of key is read from the electric fuse. It can be seen that the AES key or DES key is directly read by the hardware module to the preset address in EFUSE according to the preset scheme, and the software can only notify the hardware to decrypt, but cannot obtain the key, so that no one can Obtain AES key or DES key through software channel.

In this embodiment of the present invention, AES decryption or DES decryption is implemented by hardware, which saves the amount of BOOT code and thus saves costs (here, because the cost of software-hardened code is higher than the cost of hardware modules). Also, the startup speed can be improved by hardware implementation.

In addition, in the embodiment of the present invention, each piece of hardware can be protected by a joint test work (JTAG, JointTestAction Group), and the protection means set by the hardware cannot be cracked by software, which further increases security. Furthermore, the HASH algorithm is implemented by hardware, which improves the startup speed of the chip while saving costs.

In the above-mentioned scheme of the embodiment of the present invention, the AES key and the DES key are stored by hardware, and the difference between hardware storage and software storage is as follows:

In the case of software preservation, since m0_os itself is encrypted by code, the key cannot be obtained by analyzing the source file. Because the encrypted files are full of garbled characters and cannot be analyzed. But theoretically there is still a possibility of cracking.

In the case of hardware storage, the software can set the hardware path to read the key parsing from the EFUSE address. In this way, the software only knows what address the key is in EFUSE, but does not know what the key is.

In the above solution of the embodiment of the present invention, the first type of key may be different from the first type of key, so as to meet the requirement of mastering different keys in different development stages. Typically, the customer market (such as an operator) controls the second type of keys. In this way, even the chip provider cannot crack the customer's chip, or put other market chips into the customer's market without the customer's knowledge.

FIG. 3 is a schematic flow chart 3 of a method for safely booting a chip according to an embodiment of the present invention. As shown in FIG. 3 , the method for securely booting a chip includes the following steps:

Step 301: EFUSE is cured.

Step 302: The chip is powered on.

Step 303: The M0 core executes the instruction from the ROM.

Step 304: Judging the secure boot type, and reading the corresponding key from EFUSE according to the judgment result.

Step 305: Use the key to verify the signature of the secondary BOOT. If the signature verification fails, the startup is stopped; if the signature verification succeeds, step 306 is executed.

Step 306: Second-level BOOT execution.

Step 307: Judging the secure boot type, and reading the corresponding key from EFUSE according to the judgment result.

Step 308: Use the key to verify the signatures of the four mirror images. If the signature verification fails, the startup is stopped; if the signature verification succeeds, step 309 is executed.

Step 309: Release A53 for execution.

Step 310: The execution and startup of m0_os are completed.

In the above scheme, step 309 specifically includes:

Step 3091: A53 is executed from bl31.

Step 3092: Execute bl32.

Step 3093: Execute uboot.

Step 3094: Judging the secure boot type, and reading the corresponding key from EFUSE according to the judgment result.

Step 3095: Use the key to verify the signature of the Android image. If the signature verification fails, the startup will be stopped; if the signature verification is successful, step 3096 will be executed.

Step 3096: The execution of the kernel execution is completed.

In the above scheme, m0_os, bl31, bl32, and uboot all refer to the name of the program.

FIG. 4 is a schematic diagram of the structure and composition of a secure boot device for a chip according to an embodiment of the present invention. As shown in FIG. 4 , the device includes:

a type determination module 41, used to determine a secure boot type;

The data reading module 42 is used to read the first type key corresponding to the security boot type from the electric fuse

The security verification module 43 is configured to use the first type of key to process security verification corresponding to the secure boot type in the process of booting the chip.

In the embodiment of the present invention, the device further includes:

The data solidification module 44 is used to solidify the first type of keys corresponding to different security startup types in the electric fuse; wherein, the first type of keys are stored in the electric fuse according to the corresponding security startup type. The wire is stored in plaintext or stored in hash.

In the embodiment of the present invention, the security verification module 43 is specifically configured to: when the chip is powered on, execute the instructions sequentially from the solidified code in the read-only memory; in the process of executing the instructions, use the first type of password The key is used to verify the secondary BOOT; after the verification is passed, the secondary BOOT is executed.

In the embodiment of the present invention, the security verification module 43 is specifically configured to: use the first type key to verify the image header information of the secondary BOOT, and determine whether the secondary BOOT code is decrypted after the verification is successful; When the secondary BOOT code is not decrypted, the secondary BOOT code is decrypted according to the obtained second type key.

In the embodiment of the present invention, the data reading module 42 is further configured to read the second type key from the electric fuse according to a preset address.

Those skilled in the art should understand that the implementation function of each unit in the secure boot device of the chip shown in FIG. 4 can be understood by referring to the relevant description of the secure boot method of the chip. The function of each unit in the secure boot device of the chip shown in FIG. 4 can be realized by a program running on the processor, or can be realized by a specific logic circuit.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the invention may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied therein, including but not limited to disk storage, optical storage, and the like.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block in the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce Means for implementing the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions The apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams.

The above descriptions are merely preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention.

Claims (10)

1. A method for safely booting a chip, wherein the method comprises: Determine the type of secure boot; Read the first type key corresponding to the secure boot type from the electric fuse, wherein the first type key corresponding to different secure boot types is solidified in the electric fuse; In the process of booting the chip, the first type of key is used to process the security verification corresponding to the secure boot type. 2. The method for secure booting of a chip according to claim 1, wherein before determining the secure booting type, the method further comprises: solidifying the first type of keys corresponding to different security activation types in the electric fuse; Wherein, the first type of key is stored in the electric fuse in a plaintext manner or in a hash manner according to the corresponding secure boot type. 3 . The method for secure booting of a chip according to claim 1 , wherein, in the process of booting the chip, the first type of key is used to process the security verification corresponding to the secure boot type, comprising: 3 . : When the chip is powered on, the instructions are executed sequentially from the code solidified in the read-only memory; In the process of executing the instruction, the second-level boot BOOT is verified by using the first-type key; After the verification is passed, the second level BOOT is executed. 4. The method for safely booting a chip according to claim 3, wherein the method further comprises: Use the first type of key to verify the image header information of the secondary BOOT, and determine whether the secondary BOOT code is decrypted after the verification is successful; When the secondary BOOT code is not decrypted, the secondary BOOT code is decrypted according to the obtained second type key. 5. The method for safely booting a chip according to claim 4, wherein the method further comprises: According to the preset address, the second type key is read from the electric fuse. 6. A device for safe booting of a chip, wherein the device comprises: Type determination module, used to determine the type of secure boot; A data reading module, used to read the first type key corresponding to the safe boot type from the electrical fuse, wherein the electrical fuse is solidified with the first key corresponding to the different safe boot type respectively class key; The security verification module is configured to use the first type of key to process security verification corresponding to the secure boot type in the process of booting the chip. 7. The secure boot device for a chip according to claim 6, wherein the device further comprises: A data curing module for curing first type keys corresponding to different security boot types in the electric fuse; wherein the first type keys are stored in the electric fuse according to the corresponding security boot types It is stored in plaintext or stored in hash. 8. The safe booting device of a chip according to claim 6, wherein the safety verification module is specifically used for: when the chip is powered on, start executing instructions sequentially from the solidified code in the read-only memory; During the instruction process, the second-level BOOT is verified by using the first-type key; after the verification is passed, the second-level BOOT is executed. 9. The secure boot device of a chip according to claim 8, wherein the security verification module is specifically used for: using the first type key to verify the mirror header information of the secondary BOOT, verifying the After the verification is successful, it is determined whether the secondary BOOT code is decrypted; when the secondary BOOT code is not decrypted, the secondary BOOT code is decrypted according to the obtained second type key. 10 . The secure boot device for a chip according to claim 9 , wherein the data reading module is further configured to read the second type of password from the electric fuse according to a preset address. 11 . key.

Images