A secure chip firmware download method and system

Abstract

This invention discloses a method and system for downloading firmware to a secure chip. The security of firmware download is ensured through the following steps: First, an RSA public key and seed data are injected to generate an AES key; then, the encrypted firmware is downloaded to the memory and decrypted using the AES key; after downloading, the secure chip is reset; then, it is checked whether a self-generated AES key exists. If it exists, the key is copied to a global variable and set to unreadable and writable, and the firmware is read and verified; if it does not exist, the firmware is directly read and verified. After successful verification, if no self-generated AES key exists, the plaintext firmware is directly started; if it exists, the AES key global variable is cleared, enabling the firmware to be decrypted and started. This invention utilizes a self-generated AES algorithm, effectively enhancing the security of firmware downloading to a secure chip.

Description

Technical Field

[0001] This invention relates to a method for downloading firmware for a secure chip, and also to a corresponding system for downloading firmware for a secure chip, belonging to the field of secure chip technology. Background Technology

[0002] Security chips (simply referred to as chips) play an increasingly important role in daily life, and 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 even more widespread. The main function of these chips is to establish a trusted environment for the entire system. Through combinations of secure boot, trusted boot, and encrypted boot, combined with communication and storage-related functional requirements, they work together to establish a trusted system.

[0003] Among the many applications of security chips, Secure Firmware Installation (SFI) technology is particularly important. SFI technology protects user binaries from malicious attacks, especially when users rely on third-party factories to assemble the final product. This technology reduces the risk of firmware theft due to unscrupulous employees or hackers at these third-party factories. Encrypted firmware and decryption keys can be accessed at multiple stages, increasing the risk of key leakage. This can lead to unauthorized modification or copying of the firmware, posing a threat to device and data security.

[0004] To address these challenges, SFI technology downloads encrypted firmware to memory (such as Flash). Users encrypt the firmware using an AES (Advanced Encryption Standard) symmetric key, and then batch-program the encrypted firmware (i.e., ciphertext firmware) into the terminal device's memory. When the device boots up, it needs to decrypt the firmware in memory to obtain the plaintext firmware and then boot and run. In the STM32 Trust system, the STM32 HSM (hardware security module) security module is used. The AES key for the encrypted firmware is stored in the HSM security module, and then the encrypted firmware and the HSM security module are sent to the factory for firmware download. This ensures firmware security and integrity even in third-party factory environments, preventing unauthorized access and tampering. According to the STM32 official AN4992 document, the STM32 HSM factory security chip firmware download process is as follows: Figure 1As shown, the user uses the STM32 Trusted Package Creator tool (a host computer software running under Windows) to encrypt the user-provided firmware and options bytes using the user-provided AES key, generating an encrypted firmware image file①. The HSM is inserted into the smart card reader, and the STM32 Trusted Package Creator tool is used to program the HSM, injecting parameters such as the AES key and the maximum download count for the device②. Then, the HSM and the encrypted firmware image file are sent to the factory. The factory connects the HSM and the STM32 chip via Secure Bootloader Part 2. The STM32 chip sends its pre-stored RSA public key④ 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 its pre-stored RSA private key to decrypt and obtain the AES key⑦. The factory then uses a download tool to download the encrypted firmware, and the chip uses an AES key to decrypt and download the plaintext to the internal Flash memory. If the firmware needs to be downloaded to external Flash memory, it is encrypted again, and the encrypted text is stored in the external Flash memory.

[0005] Therefore, for mass-produced security chips, it is necessary to find a more secure firmware protection method to ensure that the firmware security is not compromised throughout the production and supply chain process. Summary of the Invention

[0006] The primary technical problem to be solved by this invention is to provide a method for downloading firmware for a secure chip.

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

[0008] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution:

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

[0010] Step S1: Inject the RSA public key;

[0011] Step S2: Inject seed data and request the generation of an AES key;

[0012] Step S3: Download the encrypted firmware to the storage and decrypt the encrypted firmware using the AES key;

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

[0014] Step S5: Check if a self-generated AES key exists. If it exists, proceed to step S6; otherwise, proceed to step S7.

[0015] Step S6: If a valid AES key exists, then firmware decryption is disabled. The AES key is copied to a global variable. Then, the AES key area is set to an unreadable and unwritable state. The firmware is read and the signature is verified. Proceed to step S8.

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

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

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

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

[0020] Step S1: The security chip uses its 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 storage and decrypt the encrypted firmware using the AES key;

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

[0024] Step S5: Check if a self-generated AES key exists. If it exists, proceed to step S6; otherwise, proceed to step S7.

[0025] Step S6: If a valid AES key exists, then firmware decryption is disabled. The AES key is copied to a global variable. Then, the AES key area is set to an unreadable and unwritable state. The firmware is read and the signature is verified. Proceed to step S8.

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

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

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

[0029] According to a third aspect of the present invention, a secure chip firmware download system is provided, including a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, which, when executed by the processor, enables the processor to implement the aforementioned secure chip firmware download method.

[0030] Compared with existing technologies, this invention has the following technical advantages: First, by integrating AES self-generation technology into the secure bootloader, the same AES key is generated for the same secure chip by both the user and the factory, thus avoiding the need for an HSM security module to protect the AES key, reducing reliance on external security and enhancing key confidentiality. Second, by automatically generating the AES key through complex calculations involving seed data and internal data of the secure bootloader (such as serial number and magic number), the uniqueness of the AES key for each chip is ensured, increasing the difficulty of cracking and improving security. Furthermore, this invention supports the download and booting of both encrypted and plaintext firmware, providing users with flexible options. During firmware download, the firmware is signed and verified using RSA public and private keys, further ensuring the integrity and tamper-proof nature of the firmware. After downloading, the security chip is reset and the existence of the AES key is checked, ensuring the security of the firmware download and decryption process. Finally, this invention simplifies the firmware download process, eliminates the HSM security module required in traditional solutions, improves production efficiency, and supports implementation on multiple devices, showing broad application prospects. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the firmware download process for a security chip based on STM32 HSM in the existing technology;

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

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

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

[0035] Figure 4 This is a flowchart illustrating the security chip firmware download method in the first embodiment of the present invention;

[0036] Figure 5This is a flowchart illustrating the security chip firmware download method in the second embodiment of the present invention;

[0037] Figure 6 This is a schematic diagram of the security chip firmware download system in the third embodiment of the present invention. Detailed Implementation

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

[0039] First Embodiment

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

[0041] Step S1: Inject the RSA public key.

[0042] RSA is an asymmetric encryption algorithm that uses a public key and a private key, used for encrypting or decrypting data respectively. Injecting an RSA public key into a security chip provides a secure mechanism, ensuring that only devices with the corresponding private key (such as the STM32 SFI device) can decrypt and access sensitive data within the chip, preventing data interception and tampering during transmission. Specifically, RSA has two functions: first, it's used for data encryption and decryption to prevent data leakage. In the STM32 SFI device, RSA is used to encrypt and decrypt AES keys; second, it's used for firmware signing and verification to prevent firmware tampering. Step S1 refers to the process where, after injecting the RSA public key, subsequent firmware downloads will use the RSA private key to sign the firmware, and firmware startup will use the RSA public key to verify the signature. Only after successful verification can the firmware be started.

[0043] Step S2: Inject seed data and request the generation of an AES key.

[0044] like Figure 4As shown, the factory receives encrypted firmware and seed data provided by the user and injects the seed data into the secure bootloader. Because the secure bootloader integrates AES self-generation technology, it can generate an AES key for each chip using the injected seed data and internal data (SN number, magic number). It's important to note that the magic number is a specific set of fixed values ​​or numerical sequences embedded in the bootloader. It is read and verified by the bootloader during startup to ensure the integrity and security of the firmware. This data is cleared after the bootloader execution is complete, making it inaccessible externally. The main function of the magic number is to verify the legitimacy of the firmware during device startup, prevent malicious software from tampering with the firmware, and ensure that the device only runs verified software. Since the secure bootloader used by the factory has the same encryption algorithm, the same magic number, and the same secure chip SN number as the user's secure bootloader, the AES key generated by the secure bootloader at the factory is exactly the same as the AES key generated by the user. The SN number is stored in the OTP area inside the chip, which the bootloader can read. The serial number (SN) here is not sensitive information, does not directly participate in AES key generation, and can be read externally.

[0045] The process of generating an AES key is as follows: In addition to a unique serial number (SN), the security chip obtained by the user also has a batch number (pre-stored in the OTP area). The batch number is defined by the start and end serial numbers (SN) of a consecutively numbered batch of chips. The chip's unique SN must be within the batch number range; otherwise, the factory secure download function cannot be executed. Furthermore, besides containing the chip's unique serial number, the SN also includes parameters such as chip packaging information, model, and version information, and these parameters are identical for chips within the same batch. The bootloader performs an operation on the start and end SNs of the batch of chips to obtain a set of data A. Then, it performs another operation on data A with the parts of the SNs that are identical to those in each batch (such as chip packaging information, model, and version information) to generate data B. The bootloader then performs multiple complex operations (such as addition, shifting, and XOR operations) on the seed data, magic number, ROM fixed data, and data B according to a predetermined algorithm, finally generating a 128-bit AES key. This ensures that all chips within the same batch have the same AES key.

[0046] Here, the entire process of the bootloader generating the AES key after obtaining the seed data is completed internally within the chip, without any external communication. Because no information can be obtained externally, a correct AES key cannot be generated, thus enhancing security.

[0047] Step S3: Download the encrypted firmware to the storage and decrypt the encrypted firmware using the AES key.

[0048] Ciphertext firmware is generated by encrypting the target firmware using an AES key. For example... Figure 2B As shown, the steps for generating encrypted firmware include:

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

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

[0051] The secure storage area is a special storage region within the security chip's ROM, used to store sensitive data, such as secure boot code. The secure storage area is accessible after power-on reset and can be made inaccessible for a subsequent period via software settings, thus protecting the sensitive data from external reading or tampering.

[0052] 3) Disable JTAG and set the secure storage area to a non-readable and non-writable state to prevent it from being read or tampered with from the outside.

[0053] JTAG (Joint Test Activision Group) is an international standard test interface primarily 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 chip's internal state. Therefore, disabling JTAG can prevent unauthorized access and tampering with the microcontroller's firmware or data. In STM32 microcontrollers, secure memory areas can be made inaccessible by setting specific option bytes. Therefore, disabling JTAG and setting secure memory areas to a non-readable / writable state improves security.

[0054] 4) Select the target firmware. The secure bootloader encrypts the target firmware using an AES key and generates encrypted firmware, which is then saved to the application area of ​​the secure chip (see...). Figure 3 ).

[0055] In this step, the encrypted firmware is decrypted using an AES key. Since AES (Advanced Encryption Standard) is a symmetric encryption algorithm, the same key is used for both encryption and decryption. Therefore, the factory can use the AES key generated by the secure bootloader to decrypt the encrypted firmware. This eliminates the need for the user to provide the AES key to the factory, and consequently, the need for an HSM smart card.

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

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

[0058] Step S5: Check if a self-generated AES key exists. If it exists, proceed to step S6; otherwise, proceed to step S7.

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

[0060] Step S6: If a valid AES key exists, then firmware decryption is disabled. The AES key is copied to a global variable, and then the AES key area is set to an unreadable and unwritable state. The firmware is read and the signature is verified. Proceed to step S8.

[0061] The generated AES key is copied to a global variable for later use, and the AES key area is set to an unreadable and unwritable state. Then, the firmware is read and the signature is verified.

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

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

[0064] The presence of an AES key indicates that the current firmware is encrypted, and the AES decryption function inside the security chip needs to be enabled to decrypt the firmware.

[0065] Step S9: After clearing the AES key global variable in the secure bootloader, 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 bootloader, integrity verification is performed in the following key steps, ensuring the security of the firmware during download and installation, preventing tampering and unauthorized access, thereby ensuring the secure and reliable download of security chip firmware (e.g., in a third-party factory). The specific reasons are analyzed as follows:

[0067] 1) Since the firmware is signed using an RSA private key during download, the firmware signature needs to be verified using an RSA public key before booting. This step prevents the firmware from being tampered with.

[0068] 2) Embedding a self-generated AES algorithm in the bootloader, by injecting a seed and requesting the generation of an AES key, ensures 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, attackers cannot obtain the AES key generation algorithm or generate the correct AES key, fundamentally improving security.

[0069] 3) The downloaded firmware is encrypted. Because 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) By resetting the chip, it can be ensured that any potential malware or tampering is removed during the firmware download and decryption process.

[0071] 5) Check the OTP (One-Time Programming) area where AES is located inside the chip. If AES is present, it indicates that the chip is secure because the AES key is generated inside the secure chip, rather than being obtained from the outside. This prevents the key from being intercepted during transmission.

[0072] 6) After the firmware download is complete, signature verification can ensure the integrity and origin of the firmware. 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, as this confirms that the firmware has not been tampered with.

[0074] Second Embodiment

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

[0076] Since the seed data injected by the factory in the first embodiment is publicly available, although it will not directly cause the AES key generated by the chip to be cracked, if the relevant parameters in the secure bootloader and the complex calculations for generating the AES key are leaked (this usually occurs due to the leakage of the secure bootloader's source code), the generated AES key will be leaked. To address this extremely low probability possibility, the secure chip firmware download method has been improved.

[0077] Before injecting seed data, the user obtains the RSA public key provided inside the chip, uses the RSA public key to encrypt the original seed data to obtain 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, which includes the following steps:

[0079] Step S1: The security chip uses its 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] This way, the seed data is not made public, thus avoiding the above risks.

[0082] Steps S3 to S9 after generating the AES key are the same as steps S3 to S9 in the first embodiment, and will not be repeated here.

[0083] In summary, the secure chip firmware download method provided in the various embodiments of the present invention integrates AES self-generation technology in the secure bootloader, enabling the generation of the same AES key for the same secure chip both at the user and factory levels based on the injected seed data and internal bootloader data. Therefore, it eliminates the need to utilize an HSM security module to ensure the security of the AES key.

[0084] Furthermore, the secure bootloader within the factory-side security chip performs complex calculations on the injected seed data and its own internal data to generate an AES key. Even if the seed data is publicly available, the generated AES key cannot be deciphered. Moreover, the original seed data can be encrypted to obtain ciphertext seed data, further enhancing security.

[0085] In various embodiments of the present invention, the secure bootloader not only supports the download and booting of encrypted firmware, but also supports the download and booting of plaintext firmware, allowing users to choose according to different needs.

[0086] In addition, when downloading encrypted firmware at the factory, the HSM security module is omitted compared to traditional solutions, simplifying the operation process and improving production efficiency.

[0087] Third Embodiment

[0088] This embodiment provides a secure chip firmware download system. For example... Figure 6As shown, the security chip firmware download system includes a processor and a memory; wherein, the memory is coupled to the processor and is used to store a computer program, which, when executed by the processor, enables the processor to implement the aforementioned security chip firmware download method.

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

[0090] In one exemplary embodiment, the security chip firmware download system may be implemented by a computer or physical entity, or by a product with certain functions, to execute the aforementioned security chip firmware download method and achieve the same technical effect as the aforementioned security chip firmware download method. Specifically, the computer may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interface device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0091] In another exemplary embodiment, the present invention also provides a computer-readable storage medium including program instructions that, when executed by a processor, implement the steps of the security chip firmware download method in any of the above embodiments. For example, the computer-readable storage medium may be the memory including the program instructions described above, which can be executed by the system's processor to complete the security chip firmware download method described above and achieve the same technical effects as the method described above.

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

[0093] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0094] The secure chip firmware download method and system provided by this invention have been described in detail above. Any obvious modifications made by those skilled in the art without departing from the essence of this invention will constitute an infringement of the patent rights of this invention and will incur corresponding legal liability.

Claims

1. A method for downloading firmware for a secure chip, characterized in that... Includes the following steps: Step S1: Inject the RSA public key; Step S2: Inject seed data and request the generation of an AES key; Step S3: Download the encrypted firmware to the storage and decrypt the encrypted firmware using the AES key; Step S4: After the download is complete, reset the security chip; Step S5: Check if a self-generated AES key exists. If it exists, proceed to step S6; otherwise, proceed to step S7. Step S6: If a valid AES key exists, then firmware decryption is disabled. The AES key is copied to a global variable. Then, the AES key area is set to an unreadable and unwritable state. The firmware is read and the signature is verified. Proceed to step S8. Step S7: If no valid AES key exists, directly read the firmware and verify the signature, then proceed to step S8; Step S8: After the signature verification is successful, check again whether a self-generated AES key exists. If it does not exist, it means that the downloaded firmware is plaintext firmware and can be started directly; if it exists, proceed to step S9. Step S9: After clearing the AES key global variable in the secure bootloader, enable firmware decryption and finally start the firmware.

2. The secure chip firmware download method as described in claim 1, characterized in that: The AES key generated in step S2 corresponds one-to-one with the security chip, is generated inside the security chip, and is stored in the OTP area of ​​the security chip.

3. The secure chip firmware download method as described in claim 1, characterized in that: The security chip has a unique serial number (SN) and batch number, both stored in the OTP area; wherein, the batch number consists of the start SN and end SN of a batch of consecutively numbered chips; the SN contains the chip's unique serial number and parameters, and the parameters of chips in the same batch are the same; The bootloader performs an operation on the start SN and end SN of the security chip to obtain a set of data A. Then, it performs an operation on data A and the parameters to generate data B. The bootloader then calculates the seed data, magic number, ROM fixed data, and data B according to a predetermined algorithm to finally generate a set of AES keys.

4. The secure chip firmware download method according to any one of claims 1 to 3, characterized in that... In step S3, the step of generating encrypted firmware includes: connecting the security chip to the download tool through a secure bootloader, then injecting seed data and requesting the security chip to generate an AES key; The secure bootloader generates a unique and fixed AES key based on the security chip's serial number, seed data, and the magic number in the secure bootloader, and stores it in the secure storage area of ​​the security chip. Disable JTAG and set the secure storage area to a non-read / write state; Select the target firmware, and the secure bootloader will encrypt the target firmware using an AES key to generate encrypted firmware, which will then be saved to the application area of ​​the secure chip.

5. A method for downloading firmware for a secure chip, characterized in that... The steps include: Step S1: The security chip uses its 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 storage and decrypt the encrypted firmware using the AES key; Step S4: After the download is complete, reset the security chip; Step S5: Check if a self-generated AES key exists. If it exists, proceed to step S6; otherwise, proceed to step S7. Step S6: If a valid AES key exists, then firmware decryption is disabled. The AES key is copied to a global variable. Then, the AES key area is set to an unreadable and unwritable state. The firmware is read and the signature is verified. Proceed to step S8. Step S7: If no valid AES key exists, directly read the firmware and verify the signature, then proceed to step S8; Step S8: After the signature verification is successful, check again whether a self-generated AES key exists. If it does not exist, it means that the downloaded firmware is plaintext firmware and can be started directly; if it exists, proceed to step S9. Step S9: After clearing the AES key global variable in the secure bootloader, enable firmware decryption and finally start the firmware.

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

7. The secure chip firmware download method as described in claim 6, characterized in that: The secure bootloader used in step S2 to generate the AES key has the same encryption algorithm, the same magic number, and the same security chip serial number as the secure bootloader used to generate the ciphertext firmware, so as to generate the same AES key.

8. The secure chip firmware download method as described in claim 5, characterized in that: The security chip has a unique serial number (SN) and batch number, both stored in the OTP area; wherein, the batch number consists of the start SN and end SN of a batch of consecutively numbered chips; the SN contains the chip's unique serial number and parameters, and the parameters of chips in the same batch are the same; The bootloader performs an operation on the start SN and end SN of the security chip to obtain a set of data A. Then, it performs an operation on data A and the parameters to generate data B. The bootloader then calculates the seed data, magic number, ROM fixed data, and data B according to a predetermined algorithm to finally generate a set of AES keys.

9. The secure chip firmware download method according to any one of claims 5 to 8, characterized in that... In step S3, the step of generating encrypted firmware includes: connecting the security chip to the download tool through a secure bootloader, then injecting seed data and requesting the security chip to generate an AES key; The secure bootloader generates a unique and fixed AES key based on the security chip's serial number, seed data, and the magic number in the secure bootloader, and stores 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 for the AES key area; Select the target firmware, and the secure bootloader will encrypt the target firmware using an AES key and generate encrypted firmware, which will then be saved to the application area of ​​the secure chip.

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

Images