A secure boot method based on HSM security hardware support

Abstract

The application discloses a kind of security startup methods based on HSM security hardware support, including self-update step and security startup step: the code of Bootloader is copied a copy and repartition locates code to the code interval used by App, retains the erasing code flash function, and the main core and HSM interaction part are deleted, and it is called Bootloader2 carrying code;Boot manager module is added in the startup code in Bootloader, and the Bootloader code that needs to be re-burned into ECU after repair is compiled to generate hex, the hex file is set to refresh file with specified address, and self-update refresh file is obtained by merging;Bootloader2 and updated Bootloader' are formed;ECU receives the refresh instruction issued by refresh tool, writes App valid flag to CODE FLASH, simultaneously obtains hash1, stores hash1 in the special DataFlash of HSM, judges App valid, then calls HSM to calculate hash and obtains hash2, compares by reading hash1 through HSM, consistent, then runs App, otherwise, stay in Bootloader and only retain refresh function, protect against software attack of hacker, and can safely upgrade Bootloader and App code.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security links of automobile electronic intelligent networking, and particularly relates to a secure boot method based on HSM secure hardware support. BACKGROUND

[0002] With the continuous development of intelligent driving and intelligent cockpit, the in-vehicle ECUs are also increasingly centralized and networked. The ECUs can not only directly communicate through Ethernet, but also communicate with the outside through V2X technology. The connection between vehicles and the outside world is becoming closer and closer. As a result, many communication channels with vehicles are opened to the outside world.

[0003] For example, the most common whole vehicle OTA technology. If the software running in the ECU is suddenly tampered with or controlled by hackers during driving, it will greatly affect driving safety. With the continuous development of future whole vehicle autonomous driving technology, the role of people in driving will become smaller and smaller. At this time, the information security of the whole vehicle will be crucial.

[0004] The purpose of whole vehicle information security is to make relevant security checks and verifications during the startup phase of each intelligent control ECU of the whole vehicle, so as to control the risk in time. If detection is performed during Runtime, it may cause greater driving safety problems.

[0005] Therefore, in the field of vehicle information security, relevant security check technology should be done during the startup phase of each intelligent ECU node, which is the so-called secure boot technology. Without doubt, it can kill the tampering caused by various hackers in the cradle, thereby ensuring the driving safety in the final electronic control unit (ECU) program running environment.

[0006] Since the verification value of the entire code area needs to be calculated and compared during secure boot, a key will be used to participate in the calculation, and a large amount of CPU resources will be consumed. Therefore, it is usually implemented on a vehicle-grade chip with a hardware security module (Hardware Security Module, hereinafter referred to as HSM). HSM is an independent core running, and the operation is relatively independent, and the hardware acceleration of the algorithm is configured. HSM is responsible for executing all cryptographic applications, including symmetric key-based encryption and decryption (AES-CMAC, etc.), integrity checking, asymmetric key-based encryption and decryption (RSA), digital signature generation and verification, HASH calculation, secure boot, etc. On the one hand, the security of password storage is guaranteed, and on the other hand, the hardware acceleration function of HSM guarantees the computing power, so that the device can start faster.

[0007] The secure boot technology generally includes an upgrade program (hereinafter referred to as Bootloader) secure boot and an application program (hereinafter referred to as App) secure boot. First, the secure boot scheme of Bootloader is introduced, which is generally as follows:

[0008] After the ECU is powered on for the first time, the Boot Loader code is executed first, and if there is no valid App code or it is judged that there is a refresh request, it is maintained under the Boot Loader code. Before the refresh tool can receive the refresh command to refresh, the secure boot verification of BootLoader is performed first to confirm that the current Bootloader is reliable and trusted, and the verification is passed before the refresh is run, otherwise the reset is executed. The trust anchor is established according to the AES-CMAC verification of the first programmed Bootloader code and the verification range in the HSM to produce a CMAC value. This value cannot be erased or rewritten by a programming device. It is securely protected and stored by the HSM. The specific strategy of secure boot is as follows: the main core communicates with the HSM, reads the software range table of secure boot verification from the specified dataflash address of the HSM to determine whether the flag byte has been set, if it is judged that it has never been set, the function interface corresponding to the HSM firmware is called to set the verification table, including the starting address of the verification code and the verification length, after the setting is successful, the secure boot table is updated to set the flag to True, and is stored in the secure dataflash of the HSM for prohibited erasing protection. The HSM side calculates the CMAC value corresponding to this Bootloader code according to the set verification starting address and verification length through the pre-set hardware acceleration AES-CMAC algorithm in the HSM, and stores it in the HSM. This time, the secure boot verification is not performed, and the Bootloader is directly started to refresh. After the second start, the main core communicates with the HSM to read the secure boot verification table set flag stored in the specified dataflash of the HSM, and does not re-set the secure boot table, then the HSM performs CMAC operation and comparison with the stored value in the HSM, the main core queries the secure verification result, and if the query is consistent, the subsequent execution is allowed, otherwise it is not allowed.

[0009] From the safety of vehicle operation and the convenience of production, the secure boot scheme of Bootloader

[0010] The main problems are as follows:

[0011] Bootloader security boot implemented by interacting with HSM has high security, but after the security boot function takes effect in the last link of the factory, it is found that the function has defects and needs to be reprogrammed, which will cause the upgraded Bootloader security boot check to fail and cannot be started, and can only be burned back to the original code. Because the CMAC value stored in the HSM is only generated when it is first burned, subsequent burning will not recompute and generate a new CMAC value for the re-burned Bootloader, and subsequent code burning is judged as tampering attack code. This results in the problem of balancing security and production convenience.

[0012] On the other hand, the security boot scheme of App is introduced. The commonly used security boot scheme of App code in the industry is described as follows:

[0013] In the production phase, instead of directly burning the combined code of Bootloader and App, App is burned through the execution of the information security refresh process. After successfully burning App, before running App after reset, Bootloader calculates the CMAC value or hash value of the entire App code area data using AES-CMAC or Hash algorithm and stores it in non-volatile memory (NVM, which can be easily read without encryption protection), or stores the CMAC or hash value as a key in a security module such as ICU-S (which is a separate security core from the HSM we use). When the App is valid after each subsequent power-on or reset, the Bootloader jumps to the App. Before jumping, the CMAC value or hash value of the entire current App is calculated again and compared with the previously stored value. If they are consistent, the App is run, otherwise the Bootloader is stayed and only the refresh function is run.

[0014] In the above method, the hash calculation is used as an example, and the calculation and storage of the hash value have the following problems:

[0015] (1) The hash calculation algorithm of App is implemented through software, and the operation speed is slow and time-consuming, which affects the overall refresh efficiency for up to 10 seconds according to the code size. The calculated hash value is stored in NVM, which has low security and can be erased, and does not meet the information security requirements.

[0016] (2) When the hash value of the App is stored as a key by the security module ICU-S, although the security is partially enhanced, when the hash value of this time is updated to the security module after refreshing different Apps each time, the count value update counter needs to be transmitted to the ICU-S module to be successful, otherwise the update fails. This parameter can only be accumulated by the main core and stored to NVM, and cannot be read from ICU-S. This update counter is easy to be erased, thus causing the function of updating the hash value to fail, and further causing the security start function to fail. SUMMARY

[0017] The purpose of the present application: in order to overcome the defects of the prior art, the present application provides a security start method based on HSM security hardware support, which protects against software attacks by hackers, and can safely upgrade Bootloader and App code.

[0018] The present application discloses a security start method based on HSM security hardware support, characterized by comprising a self-updating step and a security start step:

[0019] The self-updating step comprises: in the Bootloader code side of the electronic control system ECU, copying a copy of the Bootloader code and re-partitioning the code to the code interval used by the App, and simultaneously simplifying the function, only retaining the basic erase CodeFlash function, deleting the interaction part of the main core and HSM, and calling it Bootloader2 carrying code;

[0020] A Boot manager module is added in the Bootloader start code for deciding whether to execute the current Bootloader or jump to the Bootloader2 carrying code;

[0021] The repaired Bootloader code (Bootloader') which needs to be re-burned into the ECU is compiled to generate hex, the hex file is address-shifted to the App code area using the script tool of Hexview, and the refresh file is set at the specified address of the hex, and is combined with the compiled target file of Bootloader2 to obtain a self-updating refresh file;

[0022] Thus, a Bootloader2 for carrying and an updated Bootloader' are formed in the self-updating refresh file;

[0023] The security starting step comprises: the ECU receives the refresh instruction issued by the refresh tool, after the refresh process is successfully executed, the App valid flag is written to the CODE FLASH, and the hash1 of the App is calculated by calling the preset security hash algorithm in the HSM, and the hash1 is stored in the special DataFlash of the HSM, and after each reset or power-on restart, the Bootloader code is entered first to judge whether the App is valid, and if the App is valid, the hash2 is calculated by calling the HSM, the hash1 is read by the HSM for comparison, if the hash1 is consistent, the App is run, otherwise, the Bootloader is remained only with the refresh function.

[0024] Further, the self-updating refresh file is sent to the host factory, the corresponding authorized certificate and signature file are issued by the certificate system, the refresh process of the App is executed on the brush writing tool side, after the certificate chain verification and signature verification are passed, the self-updating download file is written to the CODE FLASH region of the App, at this time, it is determined whether the self-updating file is the real App or the Bootloader by reading the specified address, after it is determined that the self-updating refresh file, the Bootloader2 valid flag is set, and the reset is executed, after the reset, the Bootmanager of the original defective Bootloader is started first, if the Bootmanager reads the Bootloader2 valid, the Bootloader is not executed any more and is jumped to the Bootloader2, in the Bootloader2, the content of the original Bootloader region except the Bootmanager region is erased, and the content of the Bootloader' is written to the original defective code region, after all operations are completed, the reset action is performed, and after the next start, the updated BootLoader can be run.

[0025] Further, the self-updating refresh file is sent to the host factory, the corresponding authorized certificate and signature file are issued by the certificate system, the refresh process of the App is executed on the brush writing tool side, after the certificate chain verification and signature verification are passed, the self-updating download file is written to the CODE FLASH region of the App, at this time, it is determined whether the self-updating file is the real App or the Bootloader by reading the specified address, after it is determined that the self-updating refresh file, the Bootloader2 valid flag is set, and the reset is executed, after the reset, the Bootmanager of the original defective Bootloader is started first, if the Bootmanager reads the Bootloader2 valid, the Bootloader is not executed any more and is jumped to the Bootloader2, in the Bootloader2, the content of the original Bootloader region except the Bootmanager region is erased, and the content of the Bootloader' is written to the original defective code region, after all operations are completed, the reset action is performed, and after the next start, the updated BootLoader can be run.

[0026] Further setting of the present application: Bootloader2 does not erase Bootmanager area when erasing and covering old Bootloader, and when power failure or abnormality occurs during carrying, after power on again, it can still be judged by the logic in Boot manager that it is Bootloader2 effective to jump to Bootloader2 to continue carrying covering action, until successful completion of covering, then clear Bootloader2 effective flag.

[0027] Further setting of the present application: after Bootloader2 successfully erases and covers old Bootloader, set Bootloader successfully updated flag and store it to reset non-loss Retain RAM, perform soft reset, read this flag after jumping to updated Bootloader, call function interface of HSM to perform security startup table reset, and recalculate CMAC value stored in HSM for each startup verification according to current updated Bootloader code.

[0028] Further setting of the present application: the security startup step further includes refreshing flow verification step: including step 1, before starting download request, it must be authorized by certificate chain verification, ECU is in communication connection with HSM, HSM stores preset root certificate and sub certificate, refreshing tool issues third business certificate, ECU receives and loads root certificate and sub certificate stored in HSM, performs certificate analysis and RSA signature, confirms that three certificates are in a certificate chain, if it is confirmed that the business certificate is in the certificate chain, the public key is obtained for next step;

[0029] Step 2, the refreshing tool also issues hash value corresponding to this refreshing package and its digital signature, the signature can be decrypted using the public key in the business certificate, ECU receives and needs to use the public key of the business certificate to decrypt, the decrypted hash is consistent with the hash issued by the refreshing tool, and it is considered that the hash issued this time is effective, and it is recorded as hash1 for caching for subsequent comparison;

[0030] Step 3, after refreshing all the refresh files to ECU, the hash2 is obtained by calling the secure hash algorithm in HSM to operate the whole code segment data of App code, and the hash1 and hash2 are compared, and if they are consistent, the App valid flag is set, and is permanently written to the corresponding CODE FLASH address through the flashdriver, and after power reset, Bootloader is started first, and it is decided whether to stay in Bootloader or jump to App execution according to the App valid flag.

[0031] Further setting of the application: when the preset secure hash algorithm of HSM is called by ECU, the App code region to be calculated is subjected to block hash operation, and the size of each block can be set according to the maximum block that can be calculated by HSM at a time.

[0032] Further setting of the application: when the hash value storage of HSM is called by ECU, the anti-frequent writing strategy for the Dataflash of HSM is formulated, the App security startup fails, and the Bootloader needs to be stayed in and the security log is recorded, and the security startup failure information is recorded.

[0033] The specific beneficial effects of the application are that the software attack of hackers is prevented, and the Bootloader and App code can be safely upgraded. BRIEF DESCRIPTION OF DRAWINGS

[0034] Figure 1 It is a security startup schematic diagram of the application;

[0035] Figure 2 It is a first or first-time startup schematic diagram of the application;

[0036] Figure 3 It is a security hardware characteristic diagram of the application;

[0037] Figure 4 It is a security startup table setting logic schematic diagram of the application after the self-updating function is added;

[0038] Figure 5 It is a security refresh and security startup whole flow diagram of the application. DETAILED DESCRIPTION

[0039] The specific embodiments of the application are described in detail below in combination with the drawings:

[0040] In the embodiment of the application: in order to facilitate the understanding of the embodiment, first, the security startup principle of the hardware security module disclosed in the embodiment of the application is introduced in detail.

[0041] For example, BootLoader, see the attached drawings Figure 1 The embodiment of the application provides a secure boot method based on HSM secure hardware support, which relates to algorithms and principles:

[0042] HSM can be used as the root of trust of the system. The implementation of secure boot can be parallel and serial. The serial scheme is performed after the HSM core is started, and the main core is run after the verification is successful, but this will cause a delay in starting; the attached drawings Figure 1 The main core is released by the secure core first, and then the main core is queried for the verification result of the main core code by the HSM before the main function of the main core is run, so that the system can be started more quickly. Rely on hardware-accelerated AES-CMAC operation to verify software; the user configures the software components and the range that need to be checked, and when setting the configuration, the HSM calculates the corresponding reference CMAC and fixes them in the internal memory, and during the ECU secure boot, the host can trigger the check on the previously defined software part; the corresponding CMAC value is obtained by calculating the related code flash area, and is compared with the reference CMAC, and only when the two values match, the authenticity and integrity of the software part are valid, and the code contained therein can be executed.

[0043] The core element of the HSM secure boot is the "trusted boot reference table" secure boot component table, which contains the starting address and length information; here, the user defines the software components checked by the HSM, and when creating the table entry, the HSM will calculate the AES-CMAC of the given address range, and the AES key used to calculate the CMAC is randomly generated for each chip during chip production and is securely stored into the key slot through the AES engine; it is a separate key, which is only available to the HSM and is only used for secure boot, so if the user correctly configures the HSM-specific protection and debug protection, the key is considered to be secure.

[0044] As shown in the first start flow of the attached drawings 1, the CMAC value of the Bootloader secure boot verification is set only at the first start, which can be understood as establishing a trust anchor based on the code started at the first power-on. The specific steps are described as follows: the main core needs to interact with the HSM at the first power-on, A1 reads the set flag of the table stored in the HSM, the reading result of A1 is that the secure boot table of A2 has not been set, A4 is executed to run the AES-CMAC operation in the HSM to obtain A4, CMAC1 is stored in the HSM, and then the start is directly continued, and A6 is executed to update the set table to the HSM. The subsequent power-on flow is based on the attached drawings Figure 2Description: A1 reads the flag if the table has been set, if yes, go to A3 run the AES-CMAC operation of HSM to get CMAC2, continue to A5 compare CMAC1 and CMAC2, according to the comparison result, decide if the Bootloader code is to be executed continuously.

[0045] The core element of the BootLoader security start of the hardware security module provided in the embodiments of the present application is whether the trusted boot reference table can be reset, which determines whether the trust anchor CMAC1 of the security start can be updated, that is, whether the trust can be re-established according to the new Bootloader to allow it to start. However, a new Bootloader cannot erase the CMAC1 set in the HSM, nor can it erase the description in the specification attached Figure 2 The table set flag in A1 flow is because these data are stored in the security HSM and cannot be erased. This is determined by the security hardware of the HSM, see the schematic description in the specification attached FIG. 3 security hardware characteristics.

[0046] The self-updating technology of the present application is also designed based on the above-described idea. That is, the security start table is updated by the HSM to update the CMAC1. The description FIG. 4 shows the resetting logic of the security start table after the self-updating technology is added. Compared with the description FIG. 2, A7 is added. When it is judged that there is a request for resetting the security start table for self-updating, the process for resetting the security start table for the first power-on can also be performed, and the new CMAC1 is obtained by performing the AES-CMAC operation of the HSM according to the newly flashed Bootloader. For details, refer to the steps B9, B10, B12, B13, B14, and B15 in the description FIG. 5. After the Bootloader self-updating and flashing process is completed, the self-updating is not yet completed. The updated Bootloader' still exists as a false App in the code area used by the App, and has not been moved and covered to the original Bootloader area. Therefore, it is necessary to move and cover it first, and then interact with the HSM to set and store the security check CMAC1 based on the Bootloader'. Therefore, after the flashing is successful, it is necessary to pass through the reset to reach the process B9, and then perform the B10 to check the existence of the Bootloader2 and jump to the Bootloader2 action. After the successful jump, the B13 is performed by the flashdriver to move and flash the Bootloader' to the original Bootloader area. After the success, the existence identification of the Bootloader2 can be cleared, and the CODE FLASH can be stored to prevent the next time from jumping and moving again. Next, the security start table needs to pass through the resetting flag and perform the reset action, that is, the step B14. After the step B14 is run to B15, the new CMAC1 is obtained. After the resetting table is successful, the resetting flag needs to be cleared in time to avoid being reset again. In the subsequent start, the new Bootloader can be checked and started through the security check.

[0047] The self-updating technology of the present application needs to cooperate with the information security flashing process, needs to obtain the authorization of the host factory, and obtain the signature and certificate information. In the flashing process, the hash comparison and check process must be performed to verify the legality of the Bootloader self-updating file. The self-updating process of the Bootloader uses the same process as the App flashing, and does not need to increase additional flashing instructions. For details of the flashing process, refer to the B1, B2, B3, B4, and B5 processes in the description FIG. 5.

[0048] To solve the above problems (1) and (2), the embodiment of the application provides a secure starting scheme of an App code based on HSM for hash calculation and storage to a HSM special DataFlash. There is a difference in the verification algorithm of the Bootloader secure starting. In addition, the Bootloader updates the CMAC value of the secure starting setting table after the self-updating is successful to realize the re-secure starting, while the App updates the hash value after the normal information security refreshing is performed to realize the re-secure starting. The specific method comprises the following steps: the ECU receives the refreshing instruction issued by the refreshing tool, writes the App valid flag to the CODE FLASH after the refreshing process is successfully performed, and stores the hash1 obtained by calculating the current App by calling the preset secure hash algorithm in the HSM to the special DataFlash of the HSM. After each reset or power-on starting in the subsequent time, the Bootloader code is first entered to judge whether the App is valid, and the hash2 is obtained by calling the HSM for hash calculation, the hash1 is read by the HSM for comparison, and the App is run if the comparison is consistent, otherwise, the Bootloader is stayed to only keep the refreshing function.

[0049] In the embodiment of the application, the above refreshing process should be in line with the information security, and the verification step comprises the following steps:

[0050] Step 1, corresponding to the B1 process of the attached drawing 5 of the specification: Before starting the download request, the authorization must be obtained by the verification of the certificate chain, the ECU is in communication connection with the HSM end, and the HSM stores the preset root certificate and the sub-certificate. The third business certificate is issued by the refreshing tool, and the ECU end receives the root certificate and the sub-certificate stored in the HSM, performs the certificate analysis and RSA signature decryption operation, confirms that the three certificates are in a certificate chain, and obtains the public key in the business certificate for the next step if the business certificate is confirmed to be in the certificate chain.

[0051] Step 2, corresponding to the B2 process in the attached drawing 5 of the specification: The refreshing tool also issues the hash value corresponding to the current refreshing package and the digital signature thereof, the signature can be decrypted by using the public key in the business certificate, the ECU receives the hash after the decryption, and the hash after the decryption is consistent with the hash issued by the refreshing tool, and the hash after the decryption is considered to be effective, and is recorded as hash1 for the subsequent comparison.

[0052] Step 3, corresponding to B3, B4, B5, B7 in the description accompanying Figure 5: after refreshing and executing writing of all the refreshed files to the ECU, the secure hash algorithm in the HSM is called to operate on the entire code segment data of the App code to obtain hash2, and hash1 and hash2 are compared, and if they are consistent, the App valid flag is set, and is permanently written to the corresponding CODE FLASH address through the flash driver. After power-on reset, it is first started from the Bootloader, and it is decided whether to stay in the Bootloader or jump to the App for execution according to the App valid flag.

[0053] In the embodiment of the present application, when step B7 in the description accompanying Figure 5 is performed, i.e. the hash value corresponding to the App written this time is written to the hsm memory, a strategy for preventing frequent writing to the Dataflash of the HSM should be developed to improve the service life and stability. The strategy of reading the current value stored in the HSM first and comparing it with the value to be written, and writing only when they are inconsistent, can be adopted, and the watchdog is fed in time to prevent reset.

[0054] In the embodiment of the present application, the App security startup verification process is shown in B13, B14 of the description accompanying Figure 5, and when the security startup fails, it needs to stay in the Bootloader and record the security log information of startup failure. This facilitates the diagnosis device to read the log data through the diagnosis service to distinguish whether the failure to run is caused by App code defects or the security startup failure caused by tampering attacks, and to facilitate analysis of the problem.

[0055] In addition to the software programming level design of security startup, the present application also provides a PCB design with scrambled hardware programming port, which is matched with a one-piece-one-key debugging password and serial programming password to strengthen the security protection of the code. The method is specifically described as follows: the originally arranged 2 rows of regular arrangement programming interface points on the PCB for connecting the debugging or burner are scattered and distributed, and a unique password is allocated to each piece in the production link. The password is written into the debugging password area and the burning mode password area of the security configuration word through the burning method. The password setting address and setting method information need to be obtained by referring to the chip manual. The simulation and burning of the programming debugging port need to input the password in the debugging environment or the burning software interface to proceed.

[0056] To address the above-mentioned issues, embodiments of the present application also provide a production process guidance specification for correctly enabling HSM security hardware. The method primarily refers to the description of the secure hardware HSM in the Renesas U2Ax series chips. The steps are as follows: First, burn the HSM firmware hex file. Once the HSM core is enabled, the firmware code can run. Second, enable the secure core by writing to the secure configuration word area, setting the security core-related configuration words, setting the reset vector address for the secure core startup, and locking the CODEFLASH core dataflash address used by the secure core for protection. Based on the secure hardware feature diagram illustrated in Figure 3 of the specification, the order of steps 1 and 2 cannot be reversed. Executing step 2 before step 1 will result in the HSM booting up with no executable code, causing the HSM to run unnecessarily. Furthermore, the code area used by the HSM is protected and cannot be burned into firmware again. At this point, the enabled HSM core cannot be disabled using a programmer, resulting in a faulty component that cannot be run.

[0057] An embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by the processor, the computer-executable instructions prompt the processor to implement the above-mentioned method. The specific implementation can be found in the above-mentioned method embodiment, which will not be repeated here.

[0058] The computer program products of the methods, devices, and electronic devices provided in the embodiments of the present application include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the previous method embodiments. For specific implementation, please refer to the method embodiments and will not be repeated here.

[0059] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present application.

[0060] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0061] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present application, and are not intended to limit the technical solutions of the present application. The protection scope of the present application is not limited thereto. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can make modifications or easily think of changes to the technical solutions described in the foregoing embodiments, or make equivalent replacements to some of the technical features within the technical scope disclosed by the present application. Such modifications, changes or replacements do not cause the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A secure boot method based on HSM security hardware support, characterized by: Includes self-update steps and secure boot steps: The self-update process involves: On the ECU's bootloader code side, a copy of the bootloader code is made and repartitioned to the code area used by the app. Simultaneously, the code is simplified, retaining only the basic codeflash erase and write functionality, while the interaction between the main core and the HSM is deleted. This is referred to as the Bootloader2 transfer code. In the boot code of Bootloader, a Boot manager module is added to decide whether to execute the current Bootloader or jump to Bootloader2 to transfer code; The Bootloader code that needs to be re-burned into the ECU after repair is named Bootloader'. Compile Bootloader' to generate hex. Use the Hexview script tool to offset the address of the hex file to the App code area and set the refresh file at the specified address of the hex. Then merge it with the compiled target file of Bootloader2 to obtain the self-update refresh file. In this way, the self-update refresh file will contain a Bootloader2 for transport and an updated Bootloader'; The secure boot steps include: the ECU receives the refresh command issued by the refresh tool. After the refresh process is successfully completed, the App validity flag is written to the CODE FLASH. At the same time, the preset secure hash algorithm in the HSM is called to calculate the entire code segment data of the newly refreshed App code to obtain hash1, and hash1 is stored in the HSM's dedicated DataFlash. After each subsequent reset or power-on restart, the Bootloader code is first entered to determine the App validity flag. After that, the HSM is called to perform hash calculation to obtain hash2. The HSM reads hash1 for comparison. If they are consistent, the App is run. Otherwise, it stays in the Bootloader and only retains the refresh function.

2. The secure boot method based on HSM security hardware support according to claim 1, characterized in that: When the self-update flash file is sent to the OEM, the corresponding authorization certificate and signature file are issued by the certificate system. The flashing tool performs the same flashing process as the app. After the certificate chain and signature verification pass, the self-update downloaded file is written to the app's CODE FLASH area. At this time, the specified address is read to determine whether the flashed file is the real app or the bootloader's self-update file. If it is determined to be a self-update flash file, the Bootloader2 valid flag is set and a reset is performed. After the reset, it first boots into the Boot Manager of the original defective Bootloader. If the BootManager reads Bootloader2 and finds it valid, it will no longer execute the Bootloader and jump to Bootloader2. Bootloader2 first erases all contents of the original Bootloader area except the Boot Manager area, and then writes the Bootloader's contents into the original defective code area. After all operations are completed, a reset is performed, and the updated BootLoader can be run after the next boot.

3. A secure boot method based on HSM security hardware support according to claim 1 or 2, characterized in that: The hash calculation of the flashed self-update refresh file is compared with the hash obtained by decrypting the signature of the public key obtained after passing the certificate chain verification in the refresh header file. If they are consistent, the updated Bootloader is considered to be allowed and the erase code Bootloader2 is allowed to take effect. Otherwise, it will not take effect.

4. The secure boot method based on HSM security hardware support according to claim 3, characterized in that: When Bootloader2 overwrites the old Bootloader, the Bootmanager area is not erased. When a power outage or abnormality occurs during the transfer, after power is restored, the logic in the Boot manager can still determine that Bootloader2 is valid and jump to Bootloader2 to continue the transfer and overwriting operation until the overwriting is successfully completed, and then clear the Bootloader2 valid flag.

5. The secure boot method based on HSM security hardware support according to claim 4, characterized in that: After Bootloader2 successfully erases and overwrites the old Bootloader, it sets the Bootloader has been successfully updated flag and stores it in the reset retain RAM. It performs a soft reset and reads this flag after jumping to the updated Bootloader. It calls the HSM function interface to perform a secure boot table reset and recalculates the CMAC value stored in the HSM for each boot verification according to the current updated Bootloader code.

6. A secure boot method based on HSM security hardware support according to claim 1 or 2, characterized in that: The secure boot step also includes a refresh process verification step, including step 1, before starting the download request, authorization must be obtained by verifying the certificate chain, the ECU is in communication with the HSM, the HSM stores a preset root certificate and sub-certificate, the refresh tool issues a third business certificate, and after receiving it, the ECU loads the root certificate and sub-certificate stored in the HSM, performs certificate parsing and RSA de-signing, confirms that the three certificates are in the same certificate chain, and if it is confirmed that the business certificate is in the certificate chain, obtains the public key therein for use in the next step; Step 2: The flash tool will also send the hash value and digital signature corresponding to this flash package. The signature can be decrypted using the public key in the business certificate. After receiving it, the ECU needs to decrypt it using the public key in the business certificate. If the decrypted hash is consistent with the hash sent by the flash tool, the hash sent this time is considered valid and recorded as hash1 for cache for subsequent comparison. Step 3: After all the flash files are written to the ECU, the secure hash algorithm in the HSM is called to calculate the entire code segment data of the App code to obtain hash2. Hash1 and hash2 are compared. If they are consistent, the App valid flag is set and permanently written to the corresponding CODE FLASH address through the flashdriver. After power-on reset, it will start from the Bootloader first. The App valid flag determines whether to stay in the Bootloader or jump to the App execution.

7. The secure boot method based on HSM security hardware support according to claim 6, characterized in that: When the ECU side calls the preset secure hash algorithm of the HSM, it performs hash operations on the App code area to be calculated in blocks. The size of each block can be set according to the maximum block that the HSM can calculate at one time.

8. The secure boot method based on HSM security hardware support according to claim 7, characterized in that: When the ECU side calls the HSM to store hash values, a policy is formulated to prevent frequent writing to the HSM's Dataflash. When the App fails to start securely, it needs to stay in the Bootloader and record a security log to record the secure boot failure information.

Images