Vehicle-mounted chip safe starting method and device and computer program product

Abstract

The invention discloses a safe starting method and device for a vehicle-mounted chip and a computer program product, and the method comprises the steps: carrying out the safety verification and encryption storage of an original key when the chip is started for the first time; when the chip is started subsequently, decrypting the stored secret key, and performing decryption and integrity verification on the bootstrap program based on the decrypted secret key; after the bootstrap program passes the verification, generating a verification reference value for the firmware of the application program and selectively encrypting the verification reference value; and in a bootstrap program stage, executing decryption operation on the encrypted application program firmware, comparing a decryption result with the verification reference value, and if the comparison succeeds, triggering the application program to be started. According to the method, the medium protection key is injected into the one-time programmable memory of the chip security area, and the key stored on the peripheral medium is encrypted and decrypted, so that the security, reliability and external accessibility of the key are ensured. According to the invention, multi-layer security reinforcement and higher security starting are realized, and the security and starting efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the field of automotive electronics technology, and particularly to a method, device, and computer program product for secure startup of in-vehicle chips. Background Art

[0002] With the continuous development and increasing requirements in the field of automotive software information security, in-vehicle electronic chip manufacturers are facing increasingly severe security challenges. To ensure the security of in-vehicle systems, encryption / decryption and signature verification engines (HSE / HSM) are built into the chips, and secure and non-secure areas are divided, or an external secure chip solution is adopted. These designs are based on mainstream cryptographic algorithms and aim to build an advanced secure startup process to effectively manage the keys used during startup and implement strict verification methods.

[0003] In the advanced secure startup process, encryption / decryption technology is a core link. When a software package is released, symmetric cryptographic algorithms, such as the AES algorithm, are introduced to generate symmetric keys. These keys are used to encrypt the firmware package that needs to be encrypted. The encrypted software package is then imported into the factory for mass production and burning. When the product starts up, the encrypted firmware is decrypted using a pre-agreed key, and then the decrypted firmware is passed to the next stage for processing.

[0004] Signature and verification technology is also an important part of the advanced secure startup process. When a software package is released, asymmetric cryptographic algorithms, such as the RSA algorithm, are used to generate an asymmetric key pair. The private key is used to sign the firmware package, and the public key is used to verify the signature of the firmware when the product starts up. After the signature verification is successful, the firmware is passed to the next stage for processing.

[0005] Given that encryption / decryption and signature verification processing can be quite time-consuming when the firmware package is large, an effective optimization method is to first calculate the hash value of the firmware to obtain the hash value of the firmware package, and then only encrypt or sign this hash value. This can significantly reduce the processing time and improve the startup efficiency.

[0006] In the process of information security processing, the management of keys is crucial. Keys may need to be burned (efuse) into the secure area or OTP (one-time programmable) area of the chip, or stored together with the firmware in a package. In addition, the operation of some keys may need to be carried out in a secure environment. Therefore, a reasonable key deployment strategy must be formulated to reduce the exposure risk of keys and process files, and advanced security measures must be taken to protect and store these keys.

[0007] Advanced secure boot actually constructs a trust chain, dividing the entire boot process into multiple stages. Each stage has its specific tasks, security processing logic, and key usage policies. Starting from the bootrom, the boot process proceeds step by step and stage by stage in a serial chain until the user application App is launched. If a stage fails to boot, the system records the reason for the failure, stops at that stage, and reports the conclusion in the form of a log.

[0008] However, existing technical solutions have some drawbacks. First, the chip needs to clearly divide the security domain and non-security domain of hardware resources, and the encryption and decryption module must support the required encryption, decryption, and signature verification algorithms. Second, the security trust chain of the boot process is relatively long, involving multi-level security processing, resulting in a relatively complex process. Summary of the Invention

[0009] The technical problem to be solved by the embodiments of the present invention is to provide a method, device, and computer program product for secure boot of a vehicle-mounted chip to improve the security of boot and reduce the risk of data exposure.

[0010] To solve the above technical problems, the present invention provides a method for secure boot of a vehicle-mounted chip, including the following steps:

[0011] When the chip is first booted, perform security verification and encrypted storage on the original key;

[0012] When the chip is booted subsequently, decrypt the stored key and decrypt and verify the integrity of the bootloader based on the decrypted key;

[0013] When the bootloader verification passes, generate a verification reference value for the application firmware and perform selective encryption;

[0014] In the bootloader stage, perform a decryption operation on the encrypted application firmware, and compare the decryption result with the verification reference value. If the comparison is successful, trigger the start of the application.

[0015] Preferably, the performing security verification and encrypted storage on the original key when the chip is first booted specifically includes:

[0016] Verify the first boot flag and value;

[0017] Calculate the hash values of the pre-burned public key and AES key respectively, and compare and verify them with the reference hash values preset in the one-time programmable memory;

[0018] Use the media protection key in the one-time programmable memory as the encryption root key to encrypt the plaintext key;

[0019] Decrypt the encrypted key and compare it with the original plaintext key;

[0020] If the comparison is successful, erase the plaintext key and store the ciphertext key in the secure storage area.

[0021] Preferably, when the chip is subsequently started, decrypting the stored key and decrypting and verifying the integrity of the bootloader based on the decrypted key specifically includes:

[0022] Decrypt the ciphertext key;

[0023] Use the decrypted key to decrypt the bootloader;

[0024] Use the public key to verify the signature of the bootloader and check the version.

[0025] Preferably, the method further includes:

[0026] During the process of decrypting and verifying the bootloader, if the signature and version are invalid, clean up and terminate the operation, and give an error print message.

[0027] Preferably, generating a verification reference value for the application firmware and performing selective encryption specifically includes:

[0028] Calculate the hash value of the application firmware;

[0029] Perform a signature operation on the hash value;

[0030] Assemble the signed hash value, relevant processing results, and the original application firmware together;

[0031] Perform an encryption process on the overall critical area.

[0032] Preferably, during the bootloader stage, performing a decryption operation on the encrypted application firmware and comparing the decryption result with the verification reference value specifically includes:

[0033] Use the media protection key to decrypt the key used by the application;

[0034] Load the application into the dynamic random access memory;

[0035] Use the AES key to decrypt the application;

[0036] Calculate the hash value of the application and compare it with the previously generated and signed hash value.

[0037] Preferably, the method further includes:

[0038] When the hash values are inconsistent, determine whether the predetermined number of attempts has been reached;

[0039] If the predetermined number of attempts has not been reached, re-perform the operations of loading, decrypting, calculating, and verifying the hash value;

[0040] If the predetermined number of times is reached, clean the relevant data and stop at this stage, and at the same time give an error print message;

[0041] When the hash values are the same, further verify whether the signature and version of the application are valid;

[0042] If the signature and version are valid, jump and run the application.

[0043] Preferably, the method further includes:

[0044] During the startup process, check whether to perform an upgrade or OTA process;

[0045] If so, enter the upgrade or OTA process.

[0046] The present invention also provides a control device for a vehicle temperature sensing device, including:

[0047] One or more processors;

[0048] A memory;

[0049] One or more applications, wherein the one or more applications are stored in the memory and are configured to be executed by the one or more processors, and the one or more applications are configured to execute the vehicle chip secure boot method described above.

[0050] The present invention also provides a computer program product, including computer instructions, and the computer instructions instruct a computer device to perform the operations corresponding to the method.

[0051] Implementing the present invention has the following beneficial effects: By injecting a media protection key into the one-time programmable memory in the chip security area, the present invention encrypts and decrypts the key stored on the peripheral media, ensuring the security, reliability, and non-external accessibility of the key. At the same time, a multi-level protection strategy of first calculating the hash value of the application firmware, then signing the hash value, and finally encrypting the critical area of the firmware is adopted, greatly enhancing the security of the application firmware. During the secure boot process, since the lengths of the decrypted, signature-verified, and verified data are short, the secure verification and boot can be quickly completed, improving the boot efficiency. In addition, by optimizing the amount of secure processing data, the present invention reduces the amount of signature-verified data during startup, thereby shortening the overall secure boot time. In summary, the present invention realizes multi-level security reinforcement and higher secure boot, effectively reducing the risk of data exposure, enhancing the security and boot efficiency of the system, and providing strong technical support for the security protection of chips and embedded systems. Description of the Drawings

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0053] Figure 1 It is a schematic flowchart of a method for secure startup of an in-vehicle chip in Embodiment 1 of the present invention.

[0054] Figure 2 It is a schematic flowchart of the management process of the signature encryption / decryption key of the bootloader in the embodiments of the present invention.

[0055] Figure 3 It is a schematic flowchart of the management process of the signature encryption / decryption key of the application program in the embodiments of the present invention.

[0056] Figure 4 It is a schematic flowchart of the first power-on startup process in the embodiments of the present invention.

[0057] Figure 5 It is a schematic flowchart of the second power-on startup process in the embodiments of the present invention.

[0058] Figure 6 It is a schematic flowchart of the application program startup process in the embodiments of the present invention. Specific embodiments

[0059] The following descriptions of the embodiments refer to the accompanying drawings to exemplify specific embodiments in which the present invention can be implemented.

[0060] Please refer to Figure 1 As shown, Embodiment 1 of the present invention provides a method for secure startup of an in-vehicle chip, including the following steps:

[0061] When the chip starts up for the first time, perform security verification and encrypted storage on the original key;

[0062] When the chip starts up subsequently, decrypt the stored key and perform decryption and integrity verification on the bootloader based on the decrypted key;

[0063] When the bootloader verification passes, generate a verification reference value for the application program firmware and perform selective encryption;

[0064] In the bootloader stage, perform a decryption operation on the encrypted application program firmware, and compare the decryption result with the verification reference value. If the comparison is successful, trigger the startup of the application program.

[0065] As can be seen from the above steps, in the embodiment of the present invention, the encryption key is verified during the first startup, and the decryption key is used for program verification during subsequent startups, ensuring the security and orderliness of key usage and preventing the key from being illegally obtained and tampered with. Through the integrity verification of the bootloader, a progressive security trust chain is constructed to ensure the reliability of each startup link. A verification reference value is generated for the application firmware and selectively encrypted, and corresponding decryption, verification, and checking are performed during the bootloader stage, improving the security of the application and preventing the firmware from being maliciously modified. This effectively enhances the security and stability of the in-vehicle chip startup process, reduces security risks, and ensures the normal operation of the in-vehicle system.

[0066] It can be understood that before the first startup of the chip, a series of preparatory operations need to be performed. First, according to the project software design requirements, the division of the startup stage is clarified, which determines the execution order and connection logic of each functional module during chip startup. At the same time, the usage principle and management method of the key are determined, such as clarifying which keys are used for encryption, which are used for signature verification, and the storage and call rules of the keys, etc., to ensure the security of chip startup and subsequent operation. In addition, the medium division and storage definition need to be completed, defining which area of which storage medium different types of data are stored in, ensuring the orderliness and efficiency of data storage.

[0067] Then, based on the above design plan, developers carry out compilation work in a specific environment to convert the code into machine language recognizable by the chip. Subsequently, comprehensive test verification is carried out to detect vulnerabilities and errors in the software and ensure that the software functions meet the design expectations. After passing the test, a mass production software package is output, which is the core software carrier for the chip to run during startup.

[0068] Then, the mass production upgrade package is burned into the corresponding storage area of the chip on the production line. The burning process accurately places the software package in place according to the previous medium division and storage definition, preparing for the first startup of the chip and ensuring that the chip can smoothly call the burned software program during startup and start and run according to the predetermined process.

[0069] It should also be noted that the embodiment of the present invention provides an encryption and signature key management mechanism for the bootloader (BL), such as Figure 2As shown, it shows the three stages and states of the key in this area, and also prevents the exposure of keys or plaintext. Among them, Plain BL RSA Key refers to the plaintext of the RSA key used by the boot program, Plain BL AES Key refers to the plaintext of the AES key used by the boot program, CipherBL RSA Key refers to the ciphertext of the RSA key used by the boot program, and Cipher BL AES Key refers to the ciphertext of the AES key used by the boot program. The embodiment of the present invention also provides an encryption and signature key management mechanism for the application (APP), such as Figure 3 As shown, Plain SW RSA Key refers to the application ( Figure 3 (Indicated by Software, SW) uses plaintext with RSA keys, Plain SW AES Key refers to plaintext with AES keys used by applications, Cipher SW RSA Key refers to ciphertext with RSA keys used by applications, and Cipher SW AES Key refers to ciphertext with AES keys used by applications.

[0070] Please refer to Figure 4 As shown in FIG, after the above preliminary work for chip startup is completed, when the chip is powered on for the first time, the BootROM embedded in the hardware automatically starts and begins to run, performs initialization operations, activates the key processing related hardware modules, and enters the boot program stage.

[0071] During the boot process, the first boot flag and value are checked to determine whether the current boot is the first boot. If the check fails, the system enters the second power-on process to re-determine the boot status. If the check passes, indicating that it is the first boot, the location of the key is searched.

[0072] After finding the key location, perform double key verification first:

[0073] (1) Hash calculation: Calculate the hash value of the pre-burned public key (Public Key) for signature verification and the AES key (AES Key) for data encryption and decryption;

[0074] (2) Comparison verification: The calculated hash value is compared with the reference hash value preset in the one-time programmable memory (OTP). Only when the public key is the same as the AESKey (i.e. Figure 3 The subsequent key encryption process is triggered only when the hash check of the BL+SW key (shown) passes.

[0075] When performing an encryption operation on the (BL+SW) key, read the one-time programmable (flash protect key) burned in the OTP memory as the encryption root key; then use the flash protect key to encrypt the following plaintext keys stored in the flash medium: the public key for firmware signature verification and the AES key for data encryption and decryption.

[0076] It should be noted that in the embodiment of the present invention, the medium protection key flash protect key is used to protect sensitive data (such as keys) stored on a peripheral medium (such as a Flash memory). The flash protect key is injected into the secure area OTP memory on the chip. The OTP memory has the characteristic that once written, it cannot be modified, which ensures the security and non-tamperability of the flash protect key. By storing the flash protect key in the OTP, it can effectively prevent external attackers from obtaining the key through physical or software means. The flash protect key is used to encrypt and decrypt the keys stored on the peripheral medium Flash. During the encryption process, the flash protect key is used to encrypt the sensitive data, and the ciphertext is stored on the Flash. During the decryption process, the same flash protect key is used to decrypt the ciphertext to restore the original data. This encryption and decryption mechanism ensures the security of sensitive data during storage and transmission.

[0077] It can be understood that although the OTP area has been widely used in chip design, injecting the flash protect key into the OTP to protect sensitive data on the peripheral medium and combining a specific encryption and decryption algorithm to achieve the secure storage and transmission of data is a new solution proposed for specific security problems.

[0078] After that, a decryption operation is performed, and the decrypted key is compared with the plaintext (BL+SW) key. If the comparison is successful, it means that the encryption and decryption processes of the key are correct, and the currently decrypted key is exactly the same as the original plaintext key. The system will erase the plaintext (BL+SW) key to further prevent key leakage. After erasing the plaintext (BL+SW) key, the system will back up the ciphertext (BL+SW) key and store it in a pre-divided secure storage area so that the correct ciphertext key can be restored from the backup when needed later. Finally, the system is restarted to complete the first power-on startup process.

[0079] If the comparison is unsuccessful, it indicates that there are problems in the previous encryption and decryption processes. For example, the key is tampered with during storage, the encryption and decryption algorithms are incorrect, or data reading errors occur due to hardware failures. In such cases, it is necessary to clean up the previous operations and restart. Cleaning up the previous operations is to prevent the incorrect key data from having an adverse impact on the subsequent operation of the system. Because using an incorrect key may cause the system to be unable to perform encryption and decryption operations properly, thereby affecting other functional modules that rely on these operations (such as encryption protection for data transmission, signature verification of software, etc.). By cleaning up the previous operations, the system can be restored to a relatively initial state, and then restarted to allow the system to attempt the correct key processing and startup process again.

[0080] Please refer to Figure 5 again. When the chip is powered on for the second time, first decrypt the ciphertext (BL + SW) key. At the same time, check whether the upgrade or OTA (Over-The-Air) process is carried out. If so, enter the upgrade or OTA process; if not, continue to the next step and load the Bootloader program into the dynamic random access memory DRAM. DRAM has a high speed and is suitable for temporary storage during program operation. Moving the Bootloader into DRAM can make it run more efficiently.

[0081] Then, use the BL AES key to decrypt the Bootloader to ensure that the Bootloader can run normally. Then use the public key to verify the signature of the Bootloader and check the version. Signature verification is to verify whether the Bootloader has been tampered with. Only by passing the signature verification can the reliability of its source be ensured; version number verification is to confirm that the current Bootloader is the version that meets the requirements and avoid system failures caused by version incompatibility and other issues.

[0082] If the signature and version are valid (i.e., the verification passes), then jump to the application program execution stage; if the signature and version are invalid (i.e., the verification fails), then clean up and terminate the operation, clear the intermediate files and the plaintext key to prevent these data from being illegally used. At the same time, give an error print message to facilitate developers to troubleshoot problems and stop at this stage to avoid incorrect programs from continuing to run.

[0083] Another example Figure 6 is shown as follows. When the application program (APP) is compiled, considering that the size of the APP part is large and the startup stage may take a long time, the embodiments of the present invention perform the following processing:

[0084] Use the SHA256 algorithm or the CAMC packaging tool to calculate the hash algorithm for the entire APP firmware to obtain the hash value of the APP firmware. Then perform a signature operation on the hash value, assemble the signed hash value and related processing results with the original APP firmware, and finally perform an encryption process on the overall critical area. Through these operations, the security and integrity of the APP firmware during storage and transmission are guaranteed.

[0085] After entering the Bootloader stage, first verify the first startup flag and value in the same way. If the verification passes, enter the aforementioned first power-on startup process; if the verification fails, continue with the following operations for APP startup:

[0086] First, use the root key flash protect key to decrypt the key used by the application. At the same time, check whether the upgrade or OTA process is performed. If so, enter the upgrade or OTA process; if not, continue with the next step, load the application into the DRAM. Then use the AES key to decrypt the application to restore the application to a runnable state.

[0087] Then calculate and verify the hash value, including: calculating the application hash value using the hash 256 algorithm, which corresponds to the previous hash algorithm calculation for the APP firmware, and verifying the integrity of the application during storage and loading by calculating the hash value again; and verifying the application hash value using the RSA public key, that is, verifying the validity of the previous signature of the hash value to ensure the reliable source of the application and that it has not been tampered with.

[0088] Compare whether the calculated hash values are the same, that is, compare the current application hash value calculated using the hash 256 algorithm with the hash value generated in the previous stage (after compilation, using the SHA256 algorithm or the CAMC packaging tool to calculate the hash algorithm for the entire APP firmware), processed through signature, etc., and assembled with the original APP. If the hash values are the same, it means that the application has not changed during storage and loading, and the integrity is guaranteed; if the hash values are different, continue with the next judgment.

[0089] When the hash values are different, determine whether to try 3 times. If it has not been tried 3 times, return to the step of loading the application into the DRAM, and re-perform operations such as loading, decrypting, calculating, and verifying the hash value to try to restore the normal state of the application; if it has been tried 3 times, enter the cleaning and termination of operation step, that is, clean the relevant data and stop at this stage, and at the same time give an error print message to facilitate developers to troubleshoot problems.

[0090] When the hash values are relatively consistent, further verify whether the signature and version are valid. Only when the signature is valid and the version is correct can the authenticity and availability of the application be ensured. If both the signature and version are valid, it indicates that all levels of the application have passed the verification and the information authenticity and integrity are normal. Then, jump to and run the application to complete the startup process of the APP.

[0091] From the above description, it can also be learned that the application of the media protection key flash protect key in the present invention is closely centered around the secure startup scenario of in-vehicle chips and is deeply integrated with multi-stage verifications in the chip startup process (such as first startup mark verification, bootloader signature verification, application hash value comparison, etc.), forming a closed-loop from key storage protection to secure verification of the entire startup process. Moreover, the flash protect key is stored in the OTP of the chip's secure area. Combining with the physical security characteristics of the OTP, a three-layer security architecture of "chip secure area - OTP storage - peripheral flash key encryption and decryption" is constructed, which is different from the simple encryption method of "general storage medium + software encryption" commonly used in the art and has unique innovation in terms of security protection level and implementation logic.

[0092] Corresponding to the in-vehicle chip secure startup method described in the first embodiment of the present invention, the second embodiment of the present invention further provides an in-vehicle chip secure startup device, including:

[0093] One or more processors;

[0094] A memory;

[0095] One or more applications, wherein the one or more applications are stored in the memory and are configured to be executed by the one or more processors, and the one or more applications are configured to execute the in-vehicle chip secure startup method described in the first embodiment of the present invention.

[0096] Corresponding to the in-vehicle chip secure startup method described in the first embodiment of the present invention, the third embodiment of the present invention further provides a computer program product, including computer instructions, and the computer instructions direct a computer device to execute the operations corresponding to the in-vehicle chip secure startup method described in the first embodiment of the present invention.

[0097] Preferably, the processor may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor may also be any conventional processor. The processor is the control center of the device and connects various parts of the device through various interfaces and circuits.

[0098] The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function, etc., and the data storage area can store relevant data, etc. In addition, the memory may be a high-speed random access memory, or may also be a non-volatile memory, such as a plug-in hard disk, a SmartMedia Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., or the memory may also be other volatile solid-state storage devices.

[0099] It should be noted that the above device may include but is not limited to a processor and a memory, which can be understood by those skilled in the art.

[0100] For the working principle and process of the above embodiments, refer to the description of Embodiment 1 of the present invention above, and details are not described herein again.

[0101] As can be seen from the above description, compared with the prior art, the beneficial effects of the present invention are as follows: The present invention injects a media protection key into the one-time programmable memory in the chip's secure area to encrypt and decrypt the key stored on the peripheral media, ensuring the security, reliability, and non-external accessibility of the key. At the same time, a multi-level protection strategy of first calculating the hash value of the application program firmware, then signing the hash value, and finally encrypting the critical area of the firmware is adopted, greatly enhancing the security of the application program firmware. During the secure boot process, since the lengths of the decrypted, signature-verified, and verified data are short, the secure verification and boot can be completed quickly, improving the boot efficiency. In addition, the present invention optimizes the size of the secure processing data volume, reducing the amount of signature-verified data during boot, thereby shortening the overall secure boot time. In summary, the present invention realizes multi-level security reinforcement and higher secure boot, effectively reducing the risk of data exposure, enhancing the security and boot efficiency of the system, and providing strong technical support for the security protection of chips and embedded systems.

[0102] The above-disclosed are only the preferred embodiments of the present invention. Of course, the scope of the rights of the present invention cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. A method for secure startup of in-vehicle chips, characterized in that, It includes the following steps: When the chip is started for the first time, perform security verification and encrypted storage on the original key; When the chip is started subsequently, decrypt the stored key and decrypt and verify the integrity of the bootloader based on the decrypted key; After the bootloader passes the verification, generate a verification reference value for the application firmware and perform selective encryption; In the bootloader stage, perform a decryption operation on the encrypted application firmware, and compare the decryption result with the verification reference value. If the comparison is successful, trigger the start of the application.

2. The method according to claim 1, wherein The performing security verification and encrypted storage on the original key when the chip is started for the first time specifically includes: Verify the first start flag and value; Calculate the hash values of the pre-burned public key and AES key respectively, and compare and verify them with the reference hash value preset in the one-time programmable memory; Use the media protection key in the one-time programmable memory as the encryption root key to encrypt the plaintext key; Decrypt the encrypted key and compare it with the original plaintext key; If the comparison is successful, erase the plaintext key and store the ciphertext key in the secure storage area.

3. The method according to claim 1, wherein The decrypting the stored key and decrypting and verifying the integrity of the bootloader based on the decrypted key when the chip is started subsequently specifically includes: Decrypt the ciphertext key; Use the decrypted key to decrypt the bootloader; Use the public key to verify the signature of the bootloader and check the version.

4. The method according to claim 3, wherein It also includes: During the process of decrypting and verifying the bootloader, if the signature and version are invalid, clean up and terminate the operation, and give an error print message.

5. The method according to claim 1, characterized in that, The generating a verification reference value for the application firmware and performing selective encryption specifically includes: Calculate the hash value of the application firmware; Perform a signature operation on the hash value; Assemble the signed hash value, related processing results and the original application firmware together; Perform an encryption process on the overall critical area.

6. The method according to claim 5, wherein The performing a decryption operation on the encrypted application firmware and comparing the decryption result with the verification reference value in the bootloader stage specifically includes: Use the media protection key to decrypt the key used by the application; Load the application into the dynamic random access memory; Use the AES key to decrypt the application; Calculate the hash value of the application and compare it with the previously generated and signed hash value.

7. The method according to claim 6, wherein It also includes: When the hash values are inconsistent, determine whether the predetermined number of attempts has been made; If the predetermined number of attempts has not been reached, re-perform the operations of loading, decrypting, calculating and verifying the hash value; If the predetermined number of attempts has been reached, clean up the relevant data and stop at this stage, and give an error print message at the same time; When the hash values are consistent, further verify whether the signature and version of the application are valid; If the signature and version are valid, jump and run the application.

8. The method according to claim 1, wherein It also includes: During the startup process, check whether to perform an upgrade or OTA process; If so, enter the upgrade or OTA process.

9. A vehicle-mounted chip secure startup device, characterized in that It includes: One or more processors; A memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to execute the vehicle chip secure boot method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, Comprising computer instructions, the computer instructions instructing the computer device to perform operations corresponding to the method according to any one of claims 1 to 8.

Images