Safety starting method based on HSM safety hardware support

Abstract

The invention relates to a secure starting method based on HSM secure hardware support, which comprises a self-updating step and a secure starting step: copying a code of a Bootloader, re-partitioning and positioning the code to a code interval used by an App, retaining a basic CodeFlash erasing function, deleting an interaction part between a main core and an HSM, and named as Bootloader 2 carrying code; a Bootloader module is newly added to a starting code in the Bootloader, the Bootloader code needing to be re-burnt into the ECU after repairing is compiled to generate hex, a hex file is subjected to specified address setting and file refreshing, and a self-updating refreshing file is obtained through merging; the ECU receives a refreshing instruction issued by a refreshing tool, writes an App effective mark into a CODE FLASH, obtains a hash1 at the same time, stores the hash1 into a special DataFlash of an HSM, calls the HSM to carry out hash calculation to obtain a hash2 if the App is judged to be effective, reads the hash1 through the HSM to carry out comparison, runs the App if the hash1 is consistent, and stays at the Bootloader to only retain a refreshing function and protect software attacks of hackers and also can safely upgrade Bootloader and App codes if the hackers are consistent.

Description

Technical Field

[0001] The present invention relates to the technical field of information security of intelligent connected automobile electronics, and in particular to a secure startup method based on HSM security hardware support. Background Art

[0002] With the continuous development of smart driving and smart cockpits, ECUs in vehicles are becoming more centralized and networked. ECUs can not only communicate directly through Ethernet, but also communicate with the outside world through V2X technology. The connection between cars and the outside world is becoming closer and closer, which invisibly opens up many channels for the outside world to communicate with the vehicle.

[0003] For example, our most common 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 vehicle autonomous driving technology in the future, the role of people in driving will become smaller and smaller. At this time, the information security of the whole vehicle will become crucial.

[0004] The purpose of vehicle information security is to ensure that each intelligent control ECU of the vehicle performs relevant safety confirmation and verification during the startup phase so that risks can be controlled in a timely manner. If detection is performed during runtime, it may cause greater driving safety issues.

[0005] Therefore, in the field of vehicle information security, implementing corresponding security check technology at the startup stage of each intelligent ECU node, which is what we call secure boot technology, can undoubtedly nip in the bud all kinds of tampering caused by hackers, thereby ensuring driving safety in the program running environment of each electronic control unit (ECU for short).

[0006] Since the checksum of the entire code area needs to be calculated and compared during secure boot, the key will be used in the calculation, and more CPU resources will be consumed. It is usually implemented on an automotive-grade chip with a hardware security module (HSM). HSM runs on an independent core, the operation is relatively independent, and hardware acceleration of the algorithm is configured. HSM is responsible for executing all cryptographic applications, including encryption and decryption based on symmetric keys (AES-CMAC, etc.), integrity checks, encryption and decryption based on asymmetric keys (RSA), generation and verification of digital signatures, hash (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 ensures computing power, allowing the device to start faster.

[0007] Secure boot technology usually includes secure boot of upgrade program (hereinafter referred to as Bootloader) and secure boot of application program (hereinafter referred to as App). Let's first introduce the secure boot solution of Bootloader, which usually adopts: After the ECU is powered on for the first time, the Boot Loader code is executed first. If there is no valid App code or a refresh request is detected, the Boot Loader code is maintained. Before receiving the refresh command from the refresh tool for refresh, the Boot Loader security startup check is performed to confirm that the current Boot Loader is reliable and trusted. The refresh is run only after the check is passed, otherwise a reset is performed. The trust anchor is established based on the CMAC value produced by the AES-CMAC check in the HSM based on the first burned Boot Loader code and the verification range. This value cannot be erased or rewritten by the burning device. It is securely protected and stored by the HSM. The specific strategy for secure boot is: the main core communicates with the HSM, and reads the flag byte of whether the software range table of the secure boot check has been set from the specified dataflash address of the HSM. If it is determined that it has never been set, call the function interface corresponding to the HSM firmware to set the check table, including the starting address and check length of the check code. After the setting is successful, update the set flag of the secure boot table to True, and store it in the secure dataflash of the HSM for erasure protection. The HSM side calculates the CMAC value corresponding to this Bootloader code based on the set check start address and check length through the hardware accelerated AES-CMAC algorithm preset in the HSM and stores it in the HSM. No secure boot check is performed this time, and the Bootloader is directly run to start the refresh. After the second startup runs to the Bootloader, the main core communicates with the HSM to read the secure boot check table stored in the specified dataflash of the HSM. The flag has been set and the secure boot table is not reset. Then the HSM performs CMAC calculations and compares it with the value stored in the HSM. The main core queries the security check results. If the query is consistent, subsequent execution is allowed, otherwise it is not allowed.

[0008] From the perspective of vehicle operation safety and production convenience, the Bootloader's secure boot solution The main problems are as follows: The Bootloader secure boot implemented by interacting with HSM is highly secure, but after the secure boot function takes effect in the final stage of the vehicle leaving the factory, it is found that the function is defective and needs to be burned again, which will cause the upgraded Bootloader secure boot verification 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 burned for the first time, the subsequent burning will not be recalculated based on the Bootloader burned again, and the subsequent burned code is judged as tampering attack code. This has caused the problem of unbalanced security and production convenience.

[0009] On the other hand, let's introduce the secure startup solution for apps. The commonly used secure startup solution for app code in the industry is described as follows: In the production stage, the combined code of Bootloader and App is not burned directly, but App is flashed by executing the information security refresh process. After the App is successfully flashed, before resetting and running the App, the Bootloader calls AES-CMAC or Hash algorithm to calculate the CMAC value or hash value of the code area data of the entire App and stores it in the non-volatile data 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 (the HSM we use is an independent security core). When the App is determined to be valid after each subsequent power-on or reset, the App jump action is executed. Before jumping, the CMAC value or hash value of the entire range of the current App is calculated again and compared with the previously stored value. It will run only if they are consistent, otherwise it will stay under the Bootloader and only run the refresh function.

[0010] In the above method, taking hash calculation as an example, the calculation and storage of hash values ​​have the following problems: (2) The hash calculation algorithm of the App is implemented by software, which has a slow operation speed and takes a long time. Depending on the code size, it can take up to tens of seconds, affecting the overall refresh efficiency. The calculated hash value is stored in NVM, which has low security and can be erased, which does not meet information security requirements.

[0011] (3) When the hash value of the App is used as a key and stored in the security module ICU-S, although security is partially enhanced, each time the hash value is updated to the security module after refreshing a different App, the update counter must be passed to the ICU-S module to successfully update the counter value, otherwise the update fails. This parameter can only be accumulated and stored in NVM by the main core, and cannot be read from ICU-S. This update counter can be easily erased, resulting in the failure of the entire hash value update function and the failure of the secure boot function. Summary of the invention

[0012] Purpose of the present invention: In order to overcome the defects of the prior art, the present invention provides a secure boot method based on HSM security hardware support, which protects against software attacks by hackers and can safely upgrade the Bootloader and App code.

[0013] The present invention discloses a secure boot method based on HSM security hardware support, which is characterized by comprising a self-update step and a secure boot step: The self-update steps include: on the Bootloader code side of the electronic control system ECU, copy the Bootloader code and repartition the code to the code area used by the App, and simplify the functions, only retaining the basic erase CodeFlash function, and deleting the interaction part between the main core and the HSM, which is called 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; Compile the Bootloader code (Bootloader' for short) that needs to be re-burned into the ECU after repair 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 hex. 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 transfer and an updated Bootloader'; The safe boot steps include: ECU receives the refresh command issued by the refresh tool. After the refresh process is successfully executed, the App valid flag is written to CODE FLASH. At the same time, the preset secure hash algorithm in HSM is called to calculate hash1 of this App, and hash1 is stored in the dedicated DataFlash of HSM. After each subsequent reset or power-on restart, the Bootloader code is first entered to determine that the App is valid, then the HSM is called to perform hash calculation to obtain hash2, and hash1 is read through the HSM for comparison. If they are consistent, the App is run, otherwise it stays in the Bootloader and only retains the refresh function.

[0014] The present invention is further configured as follows: when the self-update refresh file is sent to the host manufacturer, the corresponding authorization certificate and signature file are issued by the certificate system, and the flashing tool performs the same refresh process as the App. After the certificate chain verification and the signature verification are passed, the self-update downloaded file is written to the CODE FLASH area of ​​the App. At this time, the specified address is read to determine whether the real App or the self-update file of the Bootloader is flashed. After determining that it is a self-update refresh file, the Bootloader2 valid flag is set, and a reset is performed. After the reset, it is first started to the Bootmanager of the original defective Bootloader. If the Bootmanager reads that Bootloader2 is valid, it will no longer continue to execute the Bootloader and jump to Bootloader2. In Bootloader2, all the contents of the original Bootloader area except the Boot manager area are first erased, and then the Bootloader' content is written to the original defective code area. After all operations are completed, a reset action is performed, and the updated BootLoader can be run after restarting.

[0015] The present invention is further configured to perform hash calculation on the flashed self-update refresh file and compare the hash obtained by decrypting the signature operation of the public key obtained after the certificate chain verification in the refresh header file. If they are consistent, it is considered that the updated Bootloader is allowed and the erase code Bootloader2 is allowed to take effect, otherwise it is not effective.

[0016] A further configuration of the present invention is that the Bootloader2 does not erase the Bootmanager area when overwriting the old Bootloader. When a power outage or abnormality occurs during the transfer, after power is turned on again, the logic in the Boot manager can still determine that it is Bootloader2 that is valid and jump to Bootloader2 to continue executing the transfer and overwriting action until the overwriting is successfully completed, and then clear the Bootloader2 valid flag.

[0017] A further configuration of the present invention is as follows: after Bootloader2 successfully erases and overwrites the old Bootloader, a Bootloader successfully updated flag is set and stored in the reset non-lost Retain RAM, a soft reset is performed, and this flag is read after jumping to the updated Bootloader, and the function interface of the HSM is called to perform a secure boot table reset, and the CMAC value stored in the HSM for each boot verification is recalculated according to the current updated Bootloader code.

[0018] The present invention is further configured as follows: the secure startup 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 connected to the HSM end in communication, the HSM stores a preset root certificate and sub-certificate, the refresh tool issues a third business certificate, the ECU end loads the root certificate and sub-certificate stored in the HSM after receiving it, parses the certificate and performs RSA de-signature, confirms that the three certificates are in a 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 refresh tool will also send the hash value and digital signature corresponding to this refresh package. The signature can be decrypted using the public key in the business certificate. After receiving it, the ECU needs to use the public key of the business certificate to decrypt it. If the decrypted hash is consistent with the hash sent by the refresh tool, the hash sent this time is considered valid and recorded as hash1 for cache for subsequent comparison. Step 3: After the refresh execution has written all the refresh files 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, and hash1 is compared with hash2. 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 is started from the Bootloader first, and the decision to stay in the Bootloader or jump to the App execution is made based on the App valid flag.

[0019] A further configuration of the present invention is that when the ECU side calls the preset secure hash algorithm of the HSM, the App code area to be calculated is hashed in blocks, and the size of each block can be set according to the maximum block that the HSM can calculate at one time.

[0020] Further configuration of the present invention: when the ECU side calls HSM to store hash values, a strategy for preventing frequent writing to the HSM Dataflash is formulated, and when the App fails to start securely, it needs to stay under the Bootloader and record a security log to record the secure startup failure information.

[0021] The specific beneficial effects of the present invention are: protecting against software attacks by hackers and safely upgrading the Bootloader and App codes. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a schematic diagram of the safety startup principle of the present invention; Figure 2 A schematic diagram of the first or sub-first start of the present invention; Figure 3 This is a diagram illustrating the security hardware characteristics of the present invention; Figure 4 A schematic diagram of the logic of setting the secure boot table after the self-update function of the present invention is added; Figure 5 This is the overall flow chart of the secure refresh and secure startup of the present invention. DETAILED DESCRIPTION

[0023] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings: In the embodiment of the present invention: To facilitate understanding of the present embodiment, a secure boot principle of a hardware security module disclosed in the embodiment of the present application is first introduced in detail.

[0024] Taking BootLoader as an example, referring to Figure 1 of the specification, the present application embodiment provides a secure boot method based on HSM security hardware support, involving the following algorithms and principles: HSM can be used as the root of trust for the system. The implementation of secure boot can be divided into parallel and serial. The serial scheme is carried out after the HSM core is started, and the main core is run after successful verification, but this will cause a startup delay; the parallel scheme is adopted in Figure 1 of the specification, the main core is first released by the security core, and then the HSM query of the verification result of the main core code before the main core runs the main function determines whether the main core can continue to execute, so that the system can be started faster. Rely on hardware-accelerated AES-CMAC operation to verify the software; the user configures the software components and ranges that need to be checked. When setting this configuration, the HSM calculates the corresponding reference CMAC and fixes them in its internal memory. During the ECU secure boot, the host can trigger the check of the previously defined software parts; the relevant code flash area is calculated to obtain the corresponding CMAC value and compared with the reference CMAC. Only when the two values ​​match, the authenticity and integrity of the software part are valid, and the code contained therein can be executed.

[0025] The core element of 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. When creating the table entry, the HSM will calculate the AES CMAC for the given address range. The AES key used to calculate this CMAC is randomly generated for each chip during chip production and securely stored in the key slot by the AES engine; it is a separate key that is only available to the HSM and is only used for secure boot. Therefore, if the user has correctly configured the HSM dedicated protection and debug protection, the key is considered safe.

[0026] As shown in the first boot process of Figure 1 of the specification, the CMAC value of the Bootloader secure boot verification is only set at the first boot, which can be understood as always establishing a trust anchor based on the code of the first power-on boot. The specific steps are described in Figure 2 of the execution specification: The main core needs to interact with the HSM when it is powered on for the first time. A1 reads the table stored in the HSM and the flag has been set. The reading result of A1 is A2, the secure boot table 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. After that, the boot continues directly and A6 is executed to update the table to be set to the HSM. The subsequent power-on process is described according to Figure 2 of the execution specification as follows: A1 reads whether the table has a flag set. If it is set, proceed to A3 to run the AES-CMAC operation of the HSM to obtain CMAC2. Continue to execute A5 to compare CMAC1 and CMAC2, and decide whether to continue to execute the Bootloader code based on the comparison result.

[0027] The embodiment of the present application provides a core element of the BootLoader secure boot of a hardware security module. Whether the secure boot table "trusted boot reference table" can be reset determines whether the trust anchor CMAC1 of the secure boot can be updated, that is, whether the trust can be re-established according to the new Bootloader to allow it to start. However, by re-burning a new Bootloader, it is impossible to erase the CMAC1 that has been set in the HSM, nor can it erase the table set flag in the A1 process of Figure 2 of the specification, because these data are stored in the secure HSM and cannot be erased. This is also determined by the HSM security hardware. For details, please refer to the schematic diagram of the specification Figure 3 for the description of the security hardware characteristics.

[0028] The self-update technology of the present invention is also designed based on the idea described above. That is, the secure boot table is re-updated by HSM to update CMAC1. Attached Figure 4 of the specification shows the reset logic of the secure boot table after the self-update technology is added. Compared with the attached Figure 2 of the specification, the logic of A7 is added. After judging that there is a request to reset the secure boot table for self-update, the secure boot table can also be reset by the first power-on process, and the AES-CMAC operation of HSM is performed again according to the newly flashed Bootloader to obtain a new CMAC1. Refer to steps B9, B10, B12, B13, B14, and B15 of attached Figure 5 of the specification for details. After the self-update refresh process of the Bootloader is completed, the self-update is not completed. The updated Bootloader' still exists in the code area used by the App as a false App, and has not been transferred to the original Bootloader area. It is necessary to transfer and overwrite first, and then interact with the HSM to set the security check CMAC1 based on the Bootloader' and store it. Therefore, after the refresh is successful, it is necessary to go through the reset to reach the process B9, and then perform B10 to check the existence of Bootloader2 and jump to Bootloader2. After the jump is successful, the flashdriver executes B13 to move the flashed Bootloader' to the original Bootloader area. Only after success can the Bootloader2 existence flag be cleared and CODE FLASH be stored to prevent the next jump and transfer. Next, the security boot table needs to be reset and the reset action is performed, that is, step B14. After step B14 runs to B15, a new CMAC1 is obtained. After the table is reset successfully, the reset flag needs to be cleared in time to avoid being reset again. Subsequent startup can pass the security check and start according to the new Bootloader.

[0029] The self-update technology of the present invention needs to cooperate with the information security refresh process, and needs to obtain the authorization of the host factory and obtain the signature and certificate information. The refresh process must go through the hash comparison and verification process to verify the legitimacy of the Bootloader self-update file. The Bootloader self-update process uses the same process as the App refresh process, and no additional refresh instructions are required. For the specific refresh process, refer to the B1, B2, B3, B4, and B5 processes in Figure 5 of the specification.

[0030] In response to the above-mentioned problems (2) and (3), the embodiment of the present application provides a secure boot solution for App code based on HSM hash calculation and storage in HSM dedicated DataFlash. There are differences in the verification algorithm of Bootloader secure boot. In addition, Bootloader updates the secure boot setting table and updates the CMAC value to achieve a safe restart after the self-update is successful, while App updates the hash value to achieve a safe restart after performing a normal information security refresh. The specific method includes: ECU receives the refresh instruction issued by the refresh tool, and after the refresh process is successfully executed, writes the App valid flag to CODE FLASH, and at the same time, calculates the hash1 of this App by calling the preset secure hash algorithm in HSM, and stores hash1 in the dedicated DataFlash of HSM. After each subsequent reset or power-on restart, the Bootloader code is first entered to determine that the App is valid, then the HSM is called to perform hash calculation to obtain hash2, and hash1 is read through HSM for comparison. If they are consistent, the App is run, otherwise it stays in the Bootloader and only retains the refresh function.

[0031] In the implementation mode of the present application, the above refresh process should comply with information security, and the verification steps include: Step 1, corresponding to the B1 process of Figure 5 of the specification: before starting the download request, you must first obtain authorization through the verification of the certificate chain, the ECU is connected to the HSM end, and the preset root certificate and sub-certificate are stored in the HSM. The third business certificate is issued in the refresh tool, and the ECU end loads the root certificate and sub-certificate stored in the HSM after receiving it, performs certificate parsing and RSA de-signing operations, and confirms that the three certificates are in a certificate chain. If it is confirmed that the business certificate is in the certificate chain, obtain the public key therein for the next step.

[0032] Step 2, corresponding to the B2 process in Figure 5 of the specification: the refresh tool will also send the hash value and digital signature corresponding to this refresh package. The signature can be decrypted using the public key in the business certificate. After receiving it, the ECU needs to use the public key of the business certificate to decrypt it. The decrypted hash is consistent with the hash sent by the refresh tool. The hash sent this time is considered valid and recorded as hash1 for cache for subsequent comparison.

[0033] Step 3, corresponding to B3, B4, B5, B7 process in Figure 5 of the specification: After the refresh execution writes all the refresh files to the ECU, call the secure hash algorithm in the HSM to calculate the entire code segment data of the App code to obtain hash2, compare hash1 and hash2, set the App valid flag if they are consistent, and write it permanently to the corresponding CODE FLASH address through flashdriver. After power-on reset, it starts from the Bootloader first, and decides whether to stay in the Bootloader or jump to the App execution according to the App valid flag.

[0034] In the implementation mode of the present application, when executing step B7 in Figure 5 of the specification, that is, writing the hash value corresponding to the App flashed this time into the HSM memory, a strategy to prevent frequent writing of the HSM Dataflash should be formulated to improve the life and stability. The strategy of first reading the current value stored in the HSM and comparing it with the value to be written can be adopted. If they are inconsistent, the strategy of writing is done, and feeding the dog in time to prevent reset.

[0035] In the implementation of the present application, the App security boot verification process is shown in B13 and B14 of Figure 5 of the specification. When the security boot fails, it is necessary to stay in the Bootloader and record the boot failure security log information. It is convenient for the diagnostic device to read the log data through the diagnostic service to distinguish whether the App code defect causes the inability to run or the security boot failure caused by tampering attack, which is convenient for problem analysis.

[0036] In addition to the design of the software writing level of secure boot, the embodiment of the present application also provides a PCB design with a scrambled hardware programming port to cooperate with setting a debugging password and a serial programming password for each piece to strengthen the security protection of the code. The method is specifically described as follows: the two rows of programming interface points originally deployed on the PCB board that are regularly arranged and used to connect the debugger or burner are scattered and distributed, and a unique password is assigned to each piece in the production process. The password is written into the debugging password area and the burning mode password area of ​​the security configuration word by burning. It is necessary to refer to the chip manual to obtain the password setting address and setting method information. The simulation and burning of the programming debug port require the password to be entered in the debugging environment or the burning software interface before it can be carried out.

[0037] In response to the above-mentioned problems, the embodiment of the present application also provides a production process guidance specification for correctly enabling HSM security hardware. The method mainly refers to the description of the security hardware HSM part of the Renesas U2Ax series chip. The steps are described as follows: The first step is to burn the HSM firmware hex file, and the firmware code can be run after the HSM core is enabled. The second step is to enable the security core by writing the security configuration word area to set the configuration words related to the security core, set the reset vector address of the security core startup, and set the CODE FLASH core dataflash address used by the security core for lock protection. Based on the security hardware feature description diagram illustrated in Figure 3 of the specification, the order of step one and step two cannot be reversed. When step two is executed before step one, there will be no executable code after the HSM is started, and the code area used by the HSM has been protected and cannot be burned into the firmware again. At this time, the already turned on HSM core cannot be turned off by the burner, resulting in a faulty part that cannot be run.

[0038] 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 a processor, the computer-executable instructions prompt the processor to implement the above method. The specific implementation can be found in the aforementioned method embodiment, which will not be repeated here.

[0039] 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. The specific implementation can be found in the method embodiments, which will not be repeated here.

[0040] 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.

[0041] 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 can be executed 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, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform 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.

[0042] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A secure boot method based on HSM security hardware support, characterized in that: Includes self-update steps and secure boot steps: The self-update steps include: on the Bootloader code side of the electronic control system ECU, copy the Bootloader code and repartition the code to the code area used by the App, and simplify the functions, only retaining the basic erase CodeFlash function, and deleting the interaction part between the main core and the HSM, which is called 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', and Bootloader' is compiled to generate hex. Using the Hexview script tool, the hex file address is offset to the App code area and the refresh file is set at the specified address of hex, and then merged 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 transfer and an updated Bootloader'; The safe boot steps include: ECU receives the refresh command issued by the refresh tool. After the refresh process is successfully executed, the App valid flag is written to CODE FLASH. At the same time, the preset secure hash algorithm in HSM is called to calculate the hash1 of this App, and hash1 is stored in the dedicated DataFlash of HSM. After each subsequent reset or power-on restart, the Bootloader code is first entered to determine that the App is valid, then the HSM is called to perform hash calculation to obtain hash2, and hash1 is read through the HSM for comparison. If they are consistent, the App is run, otherwise it stays in the Bootloader and only retains the refresh function.

2. A secure boot method based on HSM security hardware support according to claim 1, characterized in that: When the self-update refresh file is sent to the OEM, the corresponding authorization certificate and signature file are issued by the certificate system. The flash tool performs the same refresh process as the App. After the certificate chain verification and signature verification are passed, the self-update download file is written to the CODE FLASH area of ​​the App. At this time, the specified address is read to determine whether the real App or the self-update file of the Bootloader is flashed. After determining that it is a self-update refresh file, the Bootloader2 valid flag is set and a reset is performed. After the reset, it first starts to the Boot manager of the original defective Bootloader. If the Bootmanager reads Bootloader2 and it is valid, it will no longer continue to execute the Bootloader and jump to Bootloader2. In Bootloader2, all contents of the original Bootloader area except the Boot manager area are first erased, and then the Bootloader' content is written to the original defective code area. After all operations are completed, a reset action is performed. After starting again, the updated BootLoader can be run.

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 operation of the public key obtained after 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. A 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 turned on again, the logic in the Boot manager can still determine that Bootloader2 is valid and jump to Bootloader2 to continue the transfer and overwriting action until the overwriting is successfully completed, and then clear the Bootloader2 valid flag.

5. A 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, performs a soft reset, reads this flag after jumping to the updated Bootloader, 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 startup step also includes a refresh process verification step: including step 1, before starting the download request, authorization must be obtained through the verification of the certificate chain, the ECU is connected to the HSM end, the HSM stores the preset root certificate and sub-certificate, the refresh tool issues the third business certificate, the ECU end loads the root certificate and sub-certificate stored in the HSM after receiving it, parses the certificate and performs RSA de-signature, confirms that the three certificates are in a certificate chain, and if it is confirmed that the business certificate is in the certificate chain, obtains the public key therein for the next step; Step 2: The refresh tool will also send the hash value and digital signature corresponding to this refresh package. The signature can be decrypted using the public key in the business certificate. After receiving it, the ECU needs to use the public key of the business certificate to decrypt it. If the decrypted hash is consistent with the hash sent by the refresh tool, the hash sent this time is considered valid and recorded as hash1 for cache for subsequent comparison. Step 3: After the refresh execution has written all the refresh files 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, and hash1 is compared with hash2. 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 is started from the Bootloader first, and the decision to stay in the Bootloader or jump to the App execution is made based on the App valid flag.

7. A 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, and the size of each block can be set according to the maximum block that the HSM can calculate at one time.

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

Images