Security chip firmware downloading method and system

By integrating AES self-generating technology and RSA public key/private key signature verification mechanism in the security boot program of the security chip, the problem of difficult firmware security is solved when mass production of security chips is produced, and automatic generation of AES keys and efficient and secure download of firmware is achieved.

CN119788322AActive Publication Date: 2025-04-08BEIJING ZHAOXUN HENGDA TECH CO LTD
View PDF 10 Cites 0 Cited by

Patent Information

Application Number
CN202411769495.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-04
Publication Date
2025-04-08
Estimated Expiration
2044-12-04

AI Technical Summary

Technical Problem

In the mass production of safety chips, it is difficult to ensure that firmware remains secure throughout the production and supply chain process, and reliance on external HSM security modules increases dependence on external security.

Method used

By integrating AES autogenerating technology in the security boot program, the AES key is automatically generated using the injected seed data and internal data for complex operations, avoiding dependence on the HSM security module, and signing and verifying the firmware through the RSA public and private keys to ensure the integrity and security of the firmware.

Benefits of technology

It realizes that the user and the factory generate the same AES key for the same security chip, reduces external security dependence, enhances the confidentiality and uniqueness of the key, and improves the security of the firmware download and decryption process.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119788322A_ABST
    Figure CN119788322A_ABST
Patent Text Reader

Abstract

The invention discloses a secure chip firmware downloading method and a secure chip firmware downloading system. The secure chip firmware downloading method comprises the following steps of: firstly, injecting an RSA public key and seed data to generate an AES (Advanced Encryption Standard) key; downloading the encrypted firmware into a memory, and decrypting the encrypted firmware by using an AES (Advanced Encryption Standard) key; after downloading is completed, the security chip is reset; then checking whether an AES key is automatically generated, if so, copying the key to a global variable and setting the key to be unreadable and writable, and reading and verifying firmware; and if not, directly reading and checking the firmware. After the signature verification is passed, if no self-generated AES secret key exists, plaintext firmware is directly started; if yes, the AES key global variable is cleared, and the firmware is enabled to be started after being decrypted. According to the method, the self-generation AES algorithm is utilized, so that the security of firmware downloading of the security chip is effectively enhanced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention relates to a security chip firmware downloading method and also to a corresponding security chip firmware downloading system, belonging to the technical field of security chips. Background Art

[0002] Security chips (referred to as chips) play an increasingly important role in daily life. They are widely used in scenarios such as bank cards, mobile phone SIM cards, ID cards, and online banking USB keys. With the development of emerging technologies such as artificial intelligence, the Internet of Things (IoT), and the Internet of Vehicles, the application of security chips has become more extensive. The main function of these chips is to establish a trusted environment for the entire system. Through a combination of secure boot, trusted boot, encrypted boot, etc., combined with communication and storage-related functional requirements, a trusted system is established together.

[0003] Among the many applications of security chips, secure firmware installation (SFI) technology is particularly important. SFI technology can protect user binary files from malicious attacks, especially when users must rely on third-party factories to assemble the final product. This technology can reduce the risk of firmware theft by unlawful employees or hackers in third-party factories. Encrypted firmware and decryption keys may be exposed in multiple links, increasing the risk of key leakage, which may cause the firmware to be illegally tampered with or copied, posing a threat to device security and data security.

[0004] To address these challenges, SFI technology downloads the encrypted firmware to a memory device (such as Flash). The user uses an AES (Advanced Encryption Standard) symmetric key to encrypt the firmware, and then batch burns the encrypted firmware (i.e., ciphertext firmware) into the memory of the terminal device. When the device starts, the firmware in the memory needs to be decrypted to obtain the plaintext firmware and start and run it. In the STM32 Trust system, the STM32 HSM (hardware security module) security module is used to store the AES key of the encrypted firmware in the HSM security module, and then the encrypted firmware and the HSM security module are sent to the factory together to perform the firmware download. In this way, even in a third-party factory environment, the security and integrity of the firmware can be ensured to prevent unauthorized access and tampering. According to the AN4992 document officially provided by STM32, the STM32 HSM factory security chip firmware download process is as follows Figure 1As shown, the user uses the STM32 Trusted Package Creator tool (host software running under Windows) to encrypt the firmware (firmware) and parameters (option bytes) provided by the user with the AES key provided by the user to generate an encrypted firmware Image file①. Insert the HSM into the smart card reader, use the STM32 Trusted Package Creator tool to program the HSM, inject the AES key and parameters such as the maximum device download count②. Then send the HSM and the encrypted firmware Image file to the factory. The factory connects the HSM and the STM32 chip through the Secure boot program part2. The STM32 chip sends the pre-stored RSA public key (public key) in the STM32 chip to the HSM④. The HSM uses the public key to encrypt the AES key⑤, and then sends it back to the STM32 chip⑥. The STM32 chip uses the pre-stored RSA private key (private key) to decrypt and obtain the AES key⑦. After that, the factory uses the download tool to download the ciphertext firmware, and the chip uses the AES key to decrypt and download the plaintext to the internal Flash⑧. If it is to be downloaded to the external Flash, the firmware is encrypted again and the ciphertext is stored in the external Flash.

[0005] Therefore, for mass-produced security chips, a more secure firmware protection method needs to be found to ensure that the security of the firmware is not threatened throughout the production and supply chain process. Summary of the invention

[0006] The primary technical problem to be solved by the present invention is to provide a method for downloading firmware of a security chip.

[0007] Another technical problem to be solved by the present invention is to provide a security chip firmware download system.

[0008] In order to achieve the above technical objectives, the present invention adopts the following technical solutions:

[0009] According to a first aspect of an embodiment of the present invention, a method for downloading firmware of a security chip is provided, comprising the following steps:

[0010] Step S1: Inject RSA public key;

[0011] Step S2: inject seed data and request to generate AES key;

[0012] Step S3: Download the encrypted firmware to the memory, and use the AES key to decrypt the encrypted firmware;

[0013] Step S4: After the download is completed, the security chip is reset;

[0014] Step S5: Check whether there is a self-generated AES key, if so, proceed to step S6; if not, proceed to step S7;

[0015] Step S6: If there is a valid AES key, the firmware decryption is disabled, the AES key is copied to the global variable, and then the AES key area is set to a non-readable and non-writable state, the firmware is read and the signature is verified, and then step S8 is entered;

[0016] Step S7: If there is no valid AES key, directly read the firmware and verify the signature, and then proceed to step S8;

[0017] Step S8: After the signature verification is passed, it is determined again whether there is a self-generated AES key. If not, it means that the downloaded firmware is a plaintext firmware and can be started directly; if it exists, go to step S9;

[0018] Step S9: After clearing the AES key global variable in the secure boot program, enable firmware decryption and finally start the firmware.

[0019] According to a second aspect of an embodiment of the present invention, another method for downloading firmware of a security chip is provided, comprising the following steps:

[0020] Step S1: The security chip uses the internal RSA private key to decrypt the ciphertext seed data to obtain the original seed data;

[0021] Step S2: Generate an AES key based on the original seed data;

[0022] Step S3: Download the encrypted firmware to the memory, and use the AES key to decrypt the encrypted firmware;

[0023] Step S4: After the download is completed, the security chip is reset;

[0024] Step S5: Check whether there is a self-generated AES key, if so, proceed to step S6; if not, proceed to step S7;

[0025] Step S6: If there is a valid AES key, the firmware decryption is disabled, the AES key is copied to the global variable, and then the AES key area is set to a non-readable and non-writable state, the firmware is read and the signature is verified, and then step S8 is entered;

[0026] Step S7: If there is no valid AES key, directly read the firmware and verify the signature, and then proceed to step S8;

[0027] Step S8: After the signature verification is passed, it is determined again whether there is a self-generated AES key. If not, it means that the downloaded firmware is a plaintext firmware and can be started directly; if it exists, go to step S9;

[0028] Step S9: After clearing the AES key global variable in the secure boot program, enable firmware decryption and finally start the firmware.

[0029] According to a third aspect of an embodiment of the present invention, a secure chip firmware downloading system is provided, comprising a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, and when the computer program is executed by the processor, the processor implements the above-mentioned secure chip firmware downloading method.

[0030] Compared with the prior art, the present invention has the following technical effects: First, by integrating the AES self-generation technology in the secure boot program, the user and the factory end can generate the same AES key for the same security chip, thereby avoiding the need to use the HSM security module to protect the AES key, reducing the external security dependence and enhancing the confidentiality of the key. Secondly, the AES key is automatically generated by injecting the complex operation of seed data and the internal data of the secure boot program (such as SN number, magic number), ensuring the uniqueness of the AES key of each chip, increasing the difficulty of cracking, and improving security. In addition, the present invention supports the download and startup of ciphertext firmware and plaintext firmware, providing users with flexible choices. During the firmware download process, the firmware is signed and verified using the RSA public key and private key, further ensuring the integrity of the firmware and that it has not been tampered with. After the download is completed, the security chip is reset and the existence of the AES key is checked to ensure the security of the firmware download and decryption process. Finally, the present invention simplifies the firmware download process, eliminates the HSM security module required in the traditional solution, improves production efficiency, and supports the implementation of multiple devices, with broad application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a schematic diagram of the firmware download process of a security chip based on STM32 HSM in the prior art;

[0032] Figure 2A A logical framework diagram of a security chip firmware download method provided by an embodiment of the present invention;

[0033] Figure 2B This is a schematic diagram of the generation process of ciphertext firmware in an embodiment of the present invention;

[0034] Figure 3 This is a schematic diagram of the structure of a security chip;

[0035] Figure 4 This is a schematic diagram of a flow chart of a method for downloading firmware of a security chip in a first embodiment of the present invention;

[0036] Figure 5This is a flow chart of a method for downloading firmware of a security chip in a second embodiment of the present invention;

[0037] Figure 6 FIG. 4 is a schematic diagram of the structure of a security chip firmware download system in the third embodiment of the present invention. DETAILED DESCRIPTION

[0038] The technical content of the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0039] First embodiment

[0040] like Figure 2A and Figure 2B As shown, the first embodiment of the present invention provides an encryption method for preventing firmware leakage, which at least includes the following steps:

[0041] Step S1: Inject RSA public key.

[0042] RSA is an asymmetric encryption algorithm that uses public and private keys to encrypt or decrypt data, respectively. Injecting the RSA public key into the security chip can provide a secure mechanism for the security chip, ensuring that only devices with the corresponding private key (such as STM32 SFI device) can decrypt and access sensitive data in the security chip, preventing the data from being intercepted and tampered with during transmission. Specifically, RSA has two functions: the first function is to encrypt and decrypt data to prevent data leakage. The RSA in the STM32 SFI device is used to encrypt and decrypt AES keys; the second function is to sign and verify the firmware to prevent the firmware from being tampered with. Step S1 means that after the RSA public key is injected, the RSA private key will be used to sign the firmware when the firmware is downloaded subsequently, and the RSA public key will be used to verify the signature when the firmware is started. The firmware can only be started after the signature verification passes.

[0043] Step S2: Inject seed data and request to generate an AES key.

[0044] like Figure 4As shown in the figure, the factory receives the ciphertext firmware and seed data provided by the user, and injects the seed data into the secure boot program. Since the secure boot program integrates the AES self-generation technology, the AES key can be generated for each chip through the injected seed data and the internal data of the secure boot program (SN number, magic number). It should be noted that the magic number is a set of specific fixed values ​​or digital sequences embedded in the boot program, which is read and verified by the boot program during the startup process to ensure the integrity and security of the firmware. This set of data will be cleared after the boot program is executed, so that it cannot be obtained from the outside. The main function of the magic number is to verify the legitimacy of the firmware when the device is started, prevent malware from tampering with the firmware, and ensure that the device only runs verified software. Since the secure boot program used by the factory and the secure boot program used by the user have the same encryption algorithm, the same magic number, and the same SN number of the security chip, the AES key generated by the secure boot program on the factory side is exactly the same as the AES key generated on the user side. The SN number is stored in the OTP area inside the chip and can be read by the boot program. The SN number here is not sensitive information, is not directly involved in AES key generation, and can be read externally.

[0045] The process of generating AES keys is as follows: In addition to the unique SN number, the security chip obtained by the user also has a batch number (pre-saved in the OTP area). The batch number is defined by the starting serial number (SN) and the ending serial number (SN) of a batch of chips with consecutive numbers. The unique SN number of the chip must be within the batch number range, otherwise the factory security download function cannot be executed. In addition, in addition to the unique serial number of the chip, the SN number also contains parameters such as chip packaging information, model, version information, and these parameters are the same for the same batch of chips. The boot program performs an operation on the starting SN number and the ending SN number of the batch of chips to obtain a set of data A, and then performs another operation on the data A and the part that is the same as the SN number of each batch (such as chip packaging information, model, version information, etc.) to generate data B. Then the boot program performs multiple complex operations (such as addition, shift, XOR, etc.) on the seed data, magic number, ROM fixed data, and data B according to a predetermined algorithm, and finally generates a set of 128-bit AES keys. In this way, the AES keys of all chips in the same batch are guaranteed to be the same.

[0046] Here, the process of generating the AES key after the bootloader obtains the seed data is all completed inside the chip without any external communication. Since no information can be obtained from the outside, the correct AES key cannot be generated, thus improving security.

[0047] Step S3: Download the encrypted firmware to the memory, and use the AES key to decrypt the encrypted firmware.

[0048] The ciphertext firmware is generated by encrypting the target firmware using the AES key. Figure 2B As shown, the steps for generating the ciphertext firmware include:

[0049] 1) Connect the security chip to the download tool through the secure boot program (system boot loader), then inject the seed data and request the security chip to generate the AES key;

[0050] 2) The secure boot program generates a unique and fixed AES key based on the security chip's SN, seed data, and magic number in the secure boot program, and saves it in the secure storage area of ​​the security chip (see Figure 3 ). In other words, the AES key corresponds to the security chip one by one and is generated inside the security chip.

[0051] The secure storage area is a special storage area of ​​the security chip, which exists in the ROM of the security chip and is used to store sensitive data, such as secure boot code. The secure storage area can be accessed after power-on reset, and can be made inaccessible at a later time through software settings, thereby protecting the sensitive data therein from being read or tampered with externally.

[0052] 3) Disable JTAG and set the secure storage area to a non-readable and non-writable state to prevent external reading or tampering.

[0053] JTAG (Join Test Act Group) is an international standard test interface, mainly used for testing, debugging and programming electronic circuits. It allows manufacturers to test and configure chips on integrated circuits (ICs) or entire printed circuit boards (PCBs). The JTAG interface supports observation and control of the internal state of the chip. Therefore, disabling JTAG can prevent unauthorized access and tampering with the firmware or data of the microcontroller. In the STM32 microcontroller, the secure storage area can be made inaccessible by setting a specific option byte. Therefore, disabling JTAG and setting the secure storage area to a non-readable and non-writable state improves security.

[0054] 4) Select the target firmware, the secure boot program encrypts the target firmware using the AES key and generates a ciphertext firmware, which is saved to the application area of ​​the security chip (see Figure 3 ).

[0055] In this step, the AES key is used to decrypt the ciphertext firmware. Since AES (Advanced Encryption Standard) is a symmetric encryption algorithm, the same key is used to encrypt and decrypt data. Therefore, the factory can use the AES key generated by the secure boot program to decrypt the ciphertext firmware. In this way, the user does not need to provide the AES key to the factory, and there is no need to use the HSM smart card.

[0056] Step S4: After the download is completed, the security chip is reset.

[0057] A security check is performed after reset to ensure that the security of the chip has not been compromised.

[0058] Step S5: Check whether there is a self-generated AES key. If so, proceed to step S6; if not, proceed to step S7.

[0059] The reset operation will not clear the area where the AES key is located. The AES key is stored in the OTP area inside the chip.

[0060] Step S6: If there is a valid AES key, firmware decryption is not enabled, the AES key is copied to the global variable, and then the AES key area is set to a non-readable and non-writable state, the firmware is read and the signature is verified, and then step S8 is entered.

[0061] Copy the generated AES key to the global variable for subsequent use, set the AES key area to a non-readable and non-writable state, and then read the firmware and verify the signature.

[0062] Step S7: If there is no valid AES key, directly read the firmware and verify the signature, and then go to step S8.

[0063] Step S8: After the signature verification is passed, it is determined again whether there is a self-generated AES key. If not, it means that the downloaded firmware is a plaintext firmware and can be started directly; if it exists, go to step S9.

[0064] If the AES key exists, it means that the current firmware is encrypted. You need to enable the AES decryption function inside the security chip to decrypt the firmware.

[0065] Step S9: After clearing the AES key global variable in the secure boot program, enable firmware decryption and finally start the firmware.

[0066] In one embodiment of the present invention, by embedding a self-generated AES algorithm in the boot program, integrity verification is performed in the following key steps to ensure the security of the firmware during download and installation, prevent tampering and unauthorized access, and thus ensure the security and reliability of security chip firmware downloads (for example, in a third-party factory). The specific reasons are analyzed as follows:

[0067] 1) Since the RSA private key is used to sign the firmware when it is downloaded, the RSA public key needs to be used to verify the firmware before it is started. The firmware can be started only after the verification is passed. This step can prevent the firmware from being tampered with.

[0068] 2) Embed a self-generated AES algorithm in the bootloader, inject a seed and request the generation of an AES key, based on the seed data (provided by the user and the same seed data used by the user to encrypt the firmware), request the generation of an AES key, and ensure that the encryption key used each time the firmware is downloaded is unique. This increases the difficulty of cracking, because even if the seed data is leaked, the attacker cannot obtain the AES key generation algorithm and cannot generate the correct AES key, which fundamentally improves security.

[0069] 3) The downloaded firmware is encrypted. Since the firmware is downloaded in encrypted form, even if it is intercepted during transmission, the firmware content cannot be read without the correct key.

[0070] 4) Chip reset ensures that any potential malware or tampering is cleared during the firmware download and decryption process.

[0071] 5) Check the OTP (One Time Programming) area where the AES is located inside the chip. If AES exists, it means it is safe because the AES key is generated inside the security chip instead of being obtained from the outside, which can prevent the key from being intercepted during transmission.

[0072] 6) After the firmware is downloaded, the integrity and origin of the firmware can be ensured by verifying the signature. If the firmware has been tampered with during transmission, the signature will not match and the device will refuse to install the firmware.

[0073] 7) Once the firmware passes the signature verification, it can be decrypted using the AES key, because at this point it can be confident that the firmware has not been tampered with.

[0074] Second embodiment

[0075] The second embodiment of the present invention provides another method for downloading firmware of a security chip, which can ensure the security of seed data.

[0076] Since the seed data injected by the factory in the first embodiment is open to the public, although the AES key generated by the chip will not be directly cracked, if the relevant parameters in the secure boot program and the complex calculations for generating the AES key are leaked (generally, this situation occurs due to the leakage of the source code of the secure boot program), the generated AES key will be leaked. In view of this extremely low probability possibility, the method for downloading the firmware of the secure chip is improved.

[0077] Before the user injects the seed data, he obtains the RSA public key provided inside the chip, uses the RSA public key to encrypt the original seed data to obtain the ciphertext seed data, and then injects the ciphertext seed data into the security chip.

[0078] like Figure 5 As shown, when factory operation is required, the encrypted seed data (ciphertext seed data) and encrypted firmware are received from the user to execute the download process, including the following steps:

[0079] Step S1: The security chip uses the internal RSA private key to decrypt the ciphertext seed data to obtain the original seed data;

[0080] Step S2: Generate an AES key based on the original seed data.

[0081] In this way, the seed data will not be open to the outside world, thus avoiding the above risks.

[0082] Steps S3 to S9 after the AES key is generated are the same as steps S3 to S9 in the first embodiment and are not described in detail here.

[0083] In summary, the security chip firmware download method provided by each embodiment of the present invention integrates the AES self-generation technology in the secure boot program, and can generate the same AES key for the same security chip both at the user and the factory based on the injected seed data and the internal data of the boot program. Therefore, there is no need to use the HSM security module to ensure the security of the AES key.

[0084] Moreover, the secure boot program in the secure chip at the factory end will perform complex operations on the injected seed data and its own internal data to generate an AES key. Even if the seed data is open to the public, the generated AES key will not be deciphered. Furthermore, the original seed data can also be encrypted to obtain ciphertext seed data to improve security.

[0085] In each embodiment of the present invention, the secure boot program not only supports the download and startup function of the ciphertext firmware, but also supports the download and startup of the plaintext firmware, which is convenient for users to choose according to different needs.

[0086] In addition, when the factory downloads encrypted firmware, the HSM security module is omitted compared to traditional solutions, which simplifies the operation process and improves production efficiency.

[0087] Third embodiment

[0088] This embodiment provides a security chip firmware download system. Figure 6As shown, the security chip firmware downloading system includes a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program. When the computer program is executed by the processor, the processor implements the above-mentioned security chip firmware downloading method.

[0089] Among them, the processor is used to control the overall operation of the security chip firmware download system to complete all or part of the steps of the above-mentioned security chip firmware download method. The processor can be a central processing unit (CPU), a graphics processing unit (GPU), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a digital signal processing (DSP) chip, etc. The memory is used to store various types of data to support the operation of the security chip firmware download system, and these data may include, for example, instructions for any application or method for operating on the security chip firmware download system, and application-related data. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, etc.

[0090] In an exemplary embodiment, the secure chip firmware download system can be implemented by a computer or entity, or by a product with a certain function, for executing the secure chip firmware download method and achieving the same technical effect as the secure chip firmware download method. Specifically, the computer can be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0091] In another exemplary embodiment, the present invention further provides a computer-readable storage medium including program instructions, which, when executed by a processor, implements the steps of the method for downloading the firmware of a secure chip in any of the above embodiments. For example, the computer-readable storage medium may be the above-mentioned memory including program instructions, and the above-mentioned program instructions may be executed by a processor of a system to complete the above-mentioned method for downloading the firmware of a secure chip, and achieve the same technical effect as the above-mentioned method.

[0092] It should be noted that the above multiple embodiments are only examples. The technical solutions of various embodiments can be combined, and the order of various steps can be changed, all within the scope of protection of this patent.

[0093] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0094] The above is a detailed description of the security chip firmware download method and system provided by the present invention. For those skilled in the art, any obvious changes made to it without departing from the essence of the present invention will constitute an infringement of the patent right of the present invention and will bear corresponding legal responsibilities.

Claims

1. A method for downloading firmware of a security chip, characterized in that The following steps are involved: Step S1: Inject RSA public key; Step S2: inject seed data and request to generate AES key; Step S3: Download the encrypted firmware to the memory, and use the AES key to decrypt the encrypted firmware; Step S4: After the download is completed, the security chip is reset; Step S5: Check whether there is a self-generated AES key, if so, proceed to step S6; if not, proceed to step S7; Step S6: If there is a valid AES key, the firmware decryption is disabled, the AES key is copied to the global variable, and then the AES key area is set to a non-readable and non-writable state, the firmware is read and the signature is verified, and then step S8 is entered; Step S7: If there is no valid AES key, directly read the firmware and verify the signature, and then proceed to step S8; Step S8: After the signature verification is passed, it is determined again whether there is a self-generated AES key. If not, it means that the downloaded firmware is a plaintext firmware and can be started directly; if it exists, go to step S9; Step S9: After clearing the AES key global variable in the secure boot program, enable firmware decryption and finally start the firmware.

2. The method for downloading firmware of a security chip according to claim 1, characterized in that: The AES key generated in step S2 corresponds one-to-one to the security chip, is generated inside the security chip, and is stored in the OTP area of ​​the security chip.

3. The method for downloading firmware of a security chip according to claim 1, wherein: The security chip has a unique SN number and batch number, both of which are stored in the OTP area; wherein the batch number is composed of the starting SN number and the ending SN number of a batch of chips with consecutive numbers; the SN number contains the unique serial number and parameters of the chip, and the parameters of the chips in the same batch are the same; The boot program calculates the starting SN number and the ending SN number of the security chip to obtain a set of data A, and then calculates the data A and the parameters again to generate data B; then, the boot program calculates the seed data, magic number, ROM fixed data, and data B according to a predetermined encryption algorithm, and finally generates a set of AES keys.

4. The method for downloading firmware of a security chip according to any one of claims 1 to 3, characterized in that In step S3, the step of generating the ciphertext firmware includes: Connect the security chip to the download tool through the secure boot program, then inject the seed data and request the security chip to generate an AES key; The secure boot program generates a unique and fixed AES key based on the SN number of the security chip, the seed data, and the magic number in the secure boot program, and saves it in the secure storage area of ​​the security chip; Disable JTAG and set the secure storage area to a non-readable and non-writable state; Select the target firmware, and the secure boot program encrypts the target firmware using the AES key to generate ciphertext firmware, which is saved in the application area of ​​the security chip.

5. A method for downloading firmware of a security chip, characterized in that The following steps are involved: Step S1: The security chip uses the internal RSA private key to decrypt the ciphertext seed data to obtain the original seed data; Step S2: Generate an AES key based on the original seed data; Step S3: Download the encrypted firmware to the memory, and use the AES key to decrypt the encrypted firmware; Step S4: After the download is completed, the security chip is reset; Step S5: Check whether there is a self-generated AES key, if so, proceed to step S6; if not, proceed to step S7; Step S6: If there is a valid AES key, the firmware decryption is disabled, the AES key is copied to the global variable, and then the AES key area is set to a non-readable and non-writable state, the firmware is read and the signature is verified, and then step S8 is entered; Step S7: If there is no valid AES key, directly read the firmware and verify the signature, and then proceed to step S8; Step S8: After the signature verification is passed, it is determined again whether there is a self-generated AES key. If not, it means that the downloaded firmware is a plaintext firmware and can be started directly; if it exists, go to step S9; Step S9: After clearing the AES key global variable in the secure boot program, enable firmware decryption and finally start the firmware.

6. The method for downloading firmware of a security chip according to claim 5, characterized in that: The AES key generated in step S2 corresponds one-to-one to the security chip, is generated inside the security chip, and is stored in the OTP area of ​​the security chip.

7. The method for downloading firmware of a security chip according to claim 6, characterized in that: The secure boot program used when generating the AES key in step 2 has the same encryption algorithm, the same magic number, and the same SN number of the security chip as the secure boot program used when generating the ciphertext firmware, so as to generate the same AES key.

8. The method for downloading firmware of a security chip as claimed in claim 5, characterized in that: The security chip has a unique SN number and batch number, both of which are stored in the OTP area; wherein the batch number is composed of the starting SN number and the ending SN number of a batch of chips with consecutive numbers; the SN number contains the unique serial number and parameters of the chip, and the parameters of the chips in the same batch are the same; The boot program calculates the starting SN number and the ending SN number of the security chip to obtain a set of data A, and then calculates the data A and the parameters again to generate data B; then, the boot program calculates the seed data, magic number, ROM fixed data, and data B according to a predetermined encryption algorithm, and finally generates a set of AES keys.

9. The method for downloading firmware of a security chip according to any one of claims 5 to 8, characterized in that In step S3, the step of generating the ciphertext firmware includes: Connect the security chip to the download tool through the secure boot program, then inject the seed data and request the security chip to generate an AES key; The secure boot program generates a unique and fixed AES key based on the SN number of the security chip, the seed data, and the magic number in the secure boot program, and saves it in the secure storage area of ​​the security chip; Disable JTAG and set the secure storage area to set the AES key area to a non-readable and non-writable state; Select the target firmware, and the secure boot program encrypts the target firmware using the AES key to generate ciphertext firmware, which is saved in the application area of ​​the security chip.

10. A security chip firmware download system, characterized in that It comprises a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, and when the computer program is executed by the processor, the processor implements the security chip firmware downloading method according to any one of claims 1 to 9.

Citation Information

Patent Citations

  • Embedded software authorization method, embedded software authentication method and electronic equipment

    CN113343215A

  • Chip security starting method, security chip and receiver thereof

    CN113343245A

  • Multi-terminal verification security chip firmware updating method and device

    CN114662087A

  • Mass production method of encrypted mobile SSD (Solid State Disk)

    CN114664357A

  • Firmware downloading method and device and computer readable storage medium

    CN116662939A