Brushing method and device of hardware security module, equipment, medium and product

Abstract

The invention discloses a flash method for a hardware security module, and the method comprises the steps: receiving an upgrade flash request sent by a host end, and obtaining a header data package and an application program data package; based on the basic information of the initial task module, a preset symmetric key and a header data packet, decrypting ciphertext data of the initial task module in the application program data packet to obtain plaintext data of the initial task module; based on the subdata signature of the initial task module, performing de-signature verification on plaintext data of the initial task module by using a first public key to obtain a first verification result; if the first verification result represents that verification succeeds and the initial task module meets the upgrading and flashing condition, upgrading and flashing the initial task module based on plaintext data of the initial task module; and based on the plaintext data of the initial task module, decrypting the ciphertext data of the next task module until the plaintext data of all the task modules are obtained, and upgrading and flashing the task modules meeting the upgrading and flashing conditions.

Description

Technical Field

[0001] The present application relates to the field of automobile technology, and in particular to a flashing method, device, equipment, medium and product of a hardware security module. Background Art

[0002] With the rapid development of automobile intelligence and networking, the security risks faced by automobile software are becoming more and more severe, and information security issues such as data leakage, malicious attacks, illegal access, and illegal acquisition or tampering of sensitive information are emerging in an endless stream. In the existing Electronic Control Unit (ECU), in order to effectively protect the confidentiality, integrity and other security attributes of assets, a customizable Hardware Security Module (HSM) is usually used to protect the relevant assets in the ECU sequence. As a special encryption device, HSM can support a variety of secure cryptographic services, has a powerful security mechanism and key management function, can realize the establishment of a secure communication channel between ECUs in the car, and ensure the safe operation of the firmware.

[0003] However, with the widespread application of HSM in many scenarios, its functions are becoming increasingly complex, and the HSM firmware can no longer continue the "never update" strategy. Therefore, under the premise of ensuring that the safety of vehicle ECU is not affected, how to update the HSM firmware safely, conveniently and quickly has become a serious problem that needs to be solved urgently. Summary of the invention

[0004] One of the purposes of this application is to provide a flashing method, device, equipment, medium and product for a hardware security module to ensure that the HSM can update the firmware safely, conveniently and quickly without affecting the safety of the vehicle ECU.

[0005] In order to achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

[0006] The technical solution of the embodiment of the present application is implemented as follows:

[0007] In a first aspect, the present application provides a flashing method for a hardware security module, the method being applied to a hardware security module in an electronic control unit, the hardware security module being communicatively connected to a host end in the electronic control unit, the method comprising:

[0008] Receive an upgrade flashing request sent by the host end, and obtain a header data packet and an application data packet from the upgrade file stored in the first cache area of ​​the hardware security module; wherein the header data packet includes: a magic number and basic information of multiple task modules, and the basic information includes a sub-data signature obtained by signing the sub-data content of the task module based on a first private key; the application data packet includes ciphertext data used by each task module for firmware upgrade flashing, and the ciphertext data is encrypted based on a preset symmetric key and the header data packet;

[0009] Based on the basic information of the initial task module, the preset symmetric key and the header data packet, the ciphertext data of the initial task module in the application data packet is decrypted to obtain the plaintext data of the initial task module;

[0010] Based on the sub-data signature of the initial task module, use the first public key to decrypt and verify the plaintext data of the initial task module to obtain a first verification result, wherein the first public key and the first private key are a pair of keys generated based on a preset encryption system;

[0011] If the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flashing conditions, the initial task module is upgraded and flashed based on the plaintext data of the initial task module;

[0012] Based on the plaintext data of the initial task module, the ciphertext data of the next task module is decrypted until the plaintext data of all task modules are obtained, and the task modules that meet the upgrade and flash conditions are upgraded and flashed.

[0013] According to the above technical means, the ciphertext data in the application data packet is encrypted based on the preset symmetric key and the header data packet, which effectively prevents the data from being stolen or tampered with during transmission and storage; the task modules are processed in order, and the plaintext data of the initial task module is first decrypted and verified. If the conditions are met, the upgrade is performed, and then the next task module is operated based on this. The step-by-step approach can complete the upgrade of all task modules in an orderly manner, reducing the confusion and error probability that may be caused by processing multiple modules at the same time, and when a problem occurs in the upgrade of a certain module, it can be more convenient to locate and solve it; when the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flushing conditions, the upgrade is performed. The double judgment mechanism can ensure that the upgrade operation is performed when the data is legal and the module really needs to be upgraded, avoiding potential problems caused by unnecessary upgrades, and also preventing illegal upgrades caused by erroneous data or malicious attacks.

[0014] Further, the basic information includes the starting memory address and the memory data length of the task module. Decrypting the ciphertext data of the initial task module in the application program packet based on the basic information of the initial task module, the preset symmetric key, and the header data packet to obtain the plaintext data of the initial task module includes: obtaining the ciphertext data of the initial task module from the application program packet based on the starting memory address and the memory data length of the initial task module; performing a hashing operation on the magic number in the header data packet and the basic information of multiple task modules to obtain the first hash value of the header data packet; generating the decryption key of the initial task module through a key derivation algorithm based on the preset symmetric key and the first hash value; and decrypting the ciphertext data of the initial task module using the decryption key of the initial task module to obtain the plaintext data of the initial task module.

[0015] According to the above technical means, obtaining the ciphertext data from the application program packet based on the starting memory address and the memory data length of the initial task module can accurately locate the data of a specific task module, avoiding unnecessary data reading and processing, and improving the efficiency of the upgrade process; performing a hashing operation on the magic number in the header data packet and the basic information of multiple task modules to obtain the first hash value, and then generating the decryption key of the initial task module through a key derivation algorithm based on the preset symmetric key and the first hash value ensures that the generation of the decryption key is based on specific information related to the upgrade data, increasing the pertinence and security of the key and protecting the security of the ciphertext data.

[0016] Further, there are N task modules, where N is an integer greater than 1. Decrypting the ciphertext data of the next task module based on the plaintext data of the initial task module includes: performing a hashing operation on the plaintext data of the nth task module to obtain the second hash value of the nth task module; where 1 < n < N and n is an integer; generating the decryption key of the nth task module through the key derivation algorithm based on the decryption key of the nth task module and the second hash value of the nth task module; and decrypting the ciphertext data of the nth task module using the decryption key of the nth task module to obtain the plaintext data of the nth task module.

[0017] According to the above technical means, taking the integrity of the data packet of a single module and the decryption key of a single module as factors to derive the decryption key of the next module increases the coupling degree between module packets and ensures the transmission security of the HSM upgrade package.

[0018] Furthermore, the sub-data signature based on the initial task module uses the first public key to decrypt and verify the plaintext data of the initial task module to obtain a first verification result, including: performing a hash operation on the plaintext data of the initial task module to obtain a second hash value; using the first public key to decrypt the sub-data signature of the initial task module to obtain a third hash value; comparing the second hash value and the third hash value to obtain the first verification result.

[0019] According to the above technical means, the plaintext data of the initial task module is hashed to obtain the second hash value, and the sub-data signature of the initial task module is decrypted using the first public key to obtain the third hash value. By comparing these two hash values, the integrity of the data can be effectively verified. If the plaintext data is tampered with during transmission or storage, the calculated second hash value will be different from the third hash value, so that the data can be damaged in time.

[0020] Further, if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flushing conditions, the initial task module is upgraded and flushed based on the plaintext data of the initial task module, including: if the first verification result indicates that the verification is successful, obtaining the upgraded version number of the initial task module in the basic information; obtaining the current version number of the initial task module currently running by the hardware security module; if the upgraded version number is greater than the current version number, determining that the initial task module meets the upgrade and flushing conditions; and upgrading and flushing the initial task module based on the plaintext data of the initial task module.

[0021] According to the above technical means, on the premise that the plaintext data of the initial task module has been successfully verified, the upgrade version number of the initial task module in the basic information and the current running version number of the hardware security module are compared. When the upgrade version number is greater than the current version number, it is determined that the upgrade flashing conditions are met, thereby ensuring that the upgrade operation is performed on the modules that really need to be updated, and no unnecessary operations are performed on modules that are already the latest version or are not suitable for upgrading, reducing the possibility of introducing new problems due to unnecessary upgrades, and at the same time ensuring that the data source used for the upgrade is reliable, reducing the risk of security vulnerabilities or failures in the HSM due to the use of tampered data.

[0022] Furthermore, the multiple task modules are obtained by dividing all functions in the hardware security module based on function types and function associations.

[0023] According to the above technical means, HSM is used to divide the application into multiple relatively independent single modules according to function type and function correlation. Each module is independently version managed and flashed, thereby shortening the flashing operation time and reducing the impact of flashing operation abnormalities caused by high module coupling, thereby improving the security of the flashing operation.

[0024] Furthermore, the method also includes: after upgrading and flashing each of the task modules, encrypting the plaintext data of the task module using a preset secure boot key to obtain a first verification code, and storing the first verification code in a second cache area; when the electronic control unit is restarted, the boot loading module of the hardware security module uses a one-time programmable mode to determine the main task module of the hardware security module; through the boot loading module, using the preset secure boot key to generate a second verification code for the main task module; comparing the second verification code with the first verification code corresponding to the main task module stored in the second cache area to obtain the comparison result; if the comparison result indicates that the main task module is legal, determining that the hardware security module is normally started and jumping to the main task module, and when the main task module is working normally, determining the legitimacy of the remaining task modules in turn according to the order of processing tasks through the main task module; if the comparison result indicates that the main task module is illegal, jumping to the third storage area of ​​the main task module to perform code rollback of the main task module, wherein the third storage area stores data of historical versions of the main task module.

[0025] According to the above technical means, since fast startup is an important communication indicator of the electronic control unit, the boot loading module of the hardware security module adopts the OTP mode to quickly verify the HSM main task module to ensure that the HSM starts normally and quickly, and then the HSM main task module verifies other modules in turn, thus improving the startup speed and processing efficiency.

[0026] Furthermore, before receiving the upgrade flash request sent by the host end, the method includes: receiving a header data packet of the hardware security module sent by the host end; wherein the header data packet is generated by a management server according to the attribute information of the hardware security module and sent to the host end, and the header data packet also includes: a first signature of the application data packet and a second signature of the header data packet, the first signature is obtained by the management server signing the ciphertext data of all task modules based on a second private key, and the second signature is obtained by the management server signing the magic number, the basic information of all task modules and the first signature based on a third private key; using a second public key to decrypt and verify the second signature to obtain a second verification result of the header data packet, wherein The second public key and the second private key are a pair of keys generated based on the preset encryption system; when the second verification result indicates that the verification is successful, the application data packet sent by the host end is received; wherein the application data packet is generated by the management server according to the attribute information and sent to the host end; the first signature is decrypted and verified using the third public key to obtain a third verification result of the application data packet, wherein the third public key and the third private key are a pair of keys generated based on the preset encryption system; when the third verification result indicates that the verification is successful, the header data packet and the application data packet are stored in the first cache area, and the third verification result is sent to the host end, so that the host end sends the upgrade flash request according to the third verification result.

[0027] According to the above technical means, before receiving the upgrade flash request sent by the host, the header data packet and the application data packet are first received, verified and stored. This phased processing method can detect data problems at an early stage and avoid potential risks caused by data errors discovered during the upgrade flash process, such as system failures or security vulnerabilities. The third signature verification result is sent to the host, so that the host sends an upgrade flash request based on this result. This interactive mechanism ensures the coordination between the host and the hardware security module. The upgrade flash process is only started after the data verification is successful, ensuring the consistency and security of the entire upgrade process.

[0028] In a second aspect, the present application provides a flashing device for a hardware security module, the device comprising:

[0029] A receiving module, used to receive an upgrade flashing request sent by a host end, and obtain a header data packet and an application data packet from an upgrade file stored in a first buffer area of ​​the hardware security module; wherein the header data packet includes: a magic number and basic information of multiple task modules, the basic information includes a sub-data signature obtained by signing the sub-data content of the task module based on a first private key; the application data packet includes ciphertext data used by each task module for firmware upgrade flashing, the ciphertext data is encrypted based on a preset symmetric key and the header data packet;

[0030] A processing module, used to decrypt the ciphertext data of the initial task module in the application data packet based on the basic information of the initial task module, the preset symmetric key and the header data packet to obtain the plaintext data of the initial task module;

[0031] The processing module is further used to perform decryption verification on the plaintext data of the initial task module using the first public key based on the sub-data signature of the initial task module to obtain a first verification result, wherein the first public key and the first private key are a pair of keys generated based on a preset encryption system;

[0032] The processing module is further configured to upgrade and rewrite the initial task module based on the plaintext data of the initial task module if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and rewrite conditions;

[0033] The processing module is also used to decrypt the ciphertext data of the next task module based on the plaintext data of the initial task module until the plaintext data of all task modules are obtained, and upgrade and rewrite the task modules that meet the upgrade and rewrite conditions.

[0034] In a third aspect, the present application provides a flashing device for a hardware security module, the device comprising: a memory, a processor, and a transceiver.

[0035] The memory stores a computer program executable on the processor;

[0036] The transceiver is used to perform the operation of receiving data or sending data under the control of the processor;

[0037] When the processor executes the computer program, part or all of the steps in the flashing method of the hardware security module as described in any one of the first aspects are implemented.

[0038] In a fourth aspect, the present application provides a computer-readable storage medium, which stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to implement some or all of the steps in the flashing method of the hardware security module as described in any one of the first aspects.

[0039] In a fifth aspect, the present application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements part or all of the steps in the flashing method of the hardware security module as described in any one of the first aspects.

[0040] This application has the following beneficial effects:

[0041] (1) HSM is used to divide the APP into relatively independent modules according to function type and function correlation. Each module is managed and flashed separately, which shortens the flash operation time as much as possible and reduces the impact of abnormal flash operation.

[0042] (2) The integrity of the module package is used as a factor to derive the decryption key of the next module, which ensures the transmission security of the HSM upgrade package and increases the coupling degree between module packages;

[0043] (3) Since fast startup is an important communication indicator of the ECU, if the HSM bootloader adopts the OTP mode, it quickly verifies the HSM main task module to ensure that the HSM starts normally and quickly, and then the HSM main task module verifies other modules in turn. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

[0045] Figure 1 A schematic diagram of the structure of an optional flashing system for a hardware security module provided in an embodiment of the present application;

[0046] Figure 2 A schematic diagram of an implementation flow of an optional flashing method for a hardware security module provided in an embodiment of the present application;

[0047] Figure 3 A schematic diagram of the composition of an optional header data packet provided in an embodiment of the present application;

[0048] Figure 4 A schematic diagram of an implementation flow of an optional flashing method for a hardware security module provided in an embodiment of the present application;

[0049] Figure 5A schematic diagram of an implementation flow of an optional flashing method for a hardware security module provided in an embodiment of the present application;

[0050] Figure 6 A schematic diagram of an implementation flow of an optional flashing method for a hardware security module provided in an embodiment of the present application;

[0051] Figure 7 A schematic diagram of an implementation flow of an optional flashing method for a hardware security module provided in an embodiment of the present application;

[0052] Figure 8 A schematic diagram of an optional process for decrypting a task module provided in an embodiment of the present application;

[0053] Fig. 9 A schematic diagram of the structure of an optional flashing device for a hardware security module provided in an embodiment of the present application;

[0054] Fig.10 A schematic diagram of the structure of an optional flashing device for a hardware security module provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0056] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific order for the objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing this application and are not intended to limit this application.

[0058] To facilitate understanding of this embodiment, a flashing system for a hardware security module disclosed in an embodiment of the present application is first introduced in detail.

[0059] Reference Figure 1As shown, the embodiment of the present application provides a flashing system for a hardware security module, which may include: a management server 11, a host (Host) end 121 and a hardware security module (HSM) 122 in an electronic control unit ECU12; wherein the host end 121 is respectively connected to the management server 11 and the hardware security module 122 in communication; the host end 121, the hardware security module 122 and the management server 11 can realize the flashing process of the hardware security module through interaction. Of course, the system may also include: a management server 11, a vehicle-side main brush device 13, a host (Host) end 121 and a hardware security module (HSM) 122 in an electronic control unit ECU12, wherein the vehicle-side main brush device 13 is respectively connected to the management server 11 and the host end 121 in communication, and the host end 121 is also connected to the hardware security module 122 in communication; the host end 121, the hardware security module 122, the vehicle-side main brush device 13 and the management server 11 can realize the flashing process of the hardware security module through interaction.

[0060] Among them, the above-mentioned management server 11 can be an Over-the-Air (OTA) server. The management server can be a platform provided by the car company for downloading ECU software packages. The management server can be used to regularly publish OTA upgrade information, wherein the OTA upgrade information includes the upgrade package of the hardware security module in the system.

[0061] Among them, the vehicle-side main brush device 13 is a device located inside the vehicle, which is a key device for communicating with the HSM module through the host end and completing the firmware update process when upgrading and flashing the hardware security module firmware in the electronic control unit; of course, the vehicle-side main brush device 13 is also used to provide a network. It should be noted that when the HSM module itself can provide a network and complete the firmware update process, the upgrade and flashing operation can be performed without the vehicle-side main brush device.

[0062] Among them, the electronic control unit 12, also known as the "on-board computer" of the car, is used to control the driving state of the car and realize its various functions. It mainly uses data collection and exchange of various sensors and buses to judge the vehicle state and the driver's intention and control the car through actuators. ECU data flashing can change the data or program code inside the ECU individually or in batches, and conveniently realize ECU data update, so that the ECU can meet the control requirements of different vehicles.

[0063] The host end 121 is used to communicate with external devices of the ECU (such as sensors, actuators and vehicle-side main brush devices) and internal devices in the ECU (such as hardware security modules).

[0064] Among them, the hardware security module 122 is used to ensure security-related functions such as data security and device identity authentication.

[0065] Here, the flashing process of the hardware security module implemented by the host end 121, the hardware security module 122, the vehicle-end main brush device 13 and the management server 11 includes: the management server 11 regularly publishes OTA upgrade information, and when the host end 121 subscribes to the hardware security module 122 through the vehicle-end main brush device 13 and there is upgrade information, it will establish a two-way authentication of HTTPS with the management server 11, thereby establishing a secure channel to obtain the HSM upgrade file, wherein the HSM upgrade file includes: obtaining the header data packet and the application data packet. Here, obtaining the header data packet and the application data packet includes: the host end 121 receives the header data packet sent by the management server 11 through the vehicle-end main brush device 13, and passes the header data packet to the hardware security module 122, the hardware security module 122 performs a signature verification operation on the header data packet, and sends the signature verification result to the host end 121. Furthermore, if the signature verification result indicates that the signature is successful, the host end 121 receives the application data packet sent by the management server 11 through the vehicle-end main flash device 13, and passes it to the hardware security module 122. The hardware security module 122 performs a signature verification operation on the application data packet and sends the signature verification result to the host end 121. If the signature verification result indicates that the signature is successful, the host end 121 sends an upgrade flash writing request to the hardware security module 122, and the hardware security module 122 performs an upgrade flash writing operation based on the header data packet and the application data packet.

[0066] Reference Figure 2 As shown, Figure 2 A schematic diagram of a flashing method for a hardware security module provided in an embodiment of the present application, the method is applied to Figure 1 The hardware security module in the electronic control unit in the system shown is communicatively connected with the host end in the electronic control unit. The method can be implemented by the following steps:

[0067] Step 201: Receive an upgrade flash request sent by a host, and obtain a header data packet and an application data packet from an upgrade file stored in a first buffer area of ​​a hardware security module.

[0068] Among them, the header data packet includes: the magic number and basic information of multiple task modules, the basic information includes the sub-data signature obtained by signing the sub-data content of the task module based on the first private key; the application data packet includes the ciphertext data used by each task module for firmware upgrade and flashing, and the ciphertext data is encrypted based on the preset symmetric key and the header data packet.

[0069] In the embodiment of the present application, the upgrade flash request is used to upgrade the firmware in the hardware security module.

[0070] In an embodiment of the present application, the first cache area stores an upgrade file of the hardware security module, and the upgrade file includes a header data packet and an application data packet.

[0071] In an embodiment of the present application, the header data packet may include a magic number and basic information of multiple task modules, wherein the magic number is used to identify the type or protocol format of the vehicle's hardware security module, the magic number may be a fixed numerical value or a byte sequence, and the magic number may be one or more, and the present application does not impose any specific restrictions on this. Among them, the basic information of the task module includes the sub-data signature of the task module, where the sub-data signature is obtained by signing the sub-data content of the task module based on the first private key, and the sub-data signatures of different task modules are different. In some embodiments, the basic information of the task module may also include the upgrade version number of the task module, the memory start address of the sub-data content of the task module, and the memory data length occupied by the sub-data content of the task module.

[0072] In some embodiments, the header data packet may further include: a first signature of the application data packet and a second signature of the header data packet, the first signature is obtained by the management server signing the ciphertext data of multiple task modules based on the second private key, and the second signature is obtained by the management server signing the magic number, the basic information of the multiple task modules and the first signature based on the third private key. Exemplarily, the composition of the header data packet is as follows: Figure 3 As shown, it should be noted that the number of bytes occupied by each information in the header data packet is the same or different.

[0073] In some embodiments, the application data packet includes the ciphertext data of each task module, and the ciphertext data is used to upgrade the firmware of the task module, and the ciphertext data is encrypted based on the preset symmetric key and the header data packet. Here, before transmitting data between the hardware security module and the management server, an encryption system will be preset to apply for a preset symmetric key, that is, the preset symmetric key is the key agreed upon by the hardware security module and the management server, and the preset symmetric key can be randomly generated by a symmetric algorithm. Therefore, each time the flash is written, the encrypted flash data is different, and the flash data cannot be reversed through the message recording tool. Even if the flash data is stolen, it cannot be flashed into the ECU, which effectively curbs illegal flashing and greatly improves the confidentiality of the ECU flashing.

[0074] In some embodiments, the multiple task modules are obtained by dividing all functions in the hardware security module based on function types and function associations.

[0075] In practical applications, all functions in the hardware security module can be divided according to the function types and function correlations of all function modules in the hardware security module, so as to obtain multiple task modules with low coupling; wherein, the multiple task modules include but are not limited to: general algorithm module, digital key module, secure communication module, transport layer security module (Transport Layer Security, TLS) module, secure boot module, etc. It should be noted that the above is only an example. In this way, HSM is used to divide the application into multiple relatively independent single modules according to the function type and function correlation, and each module is separately version managed and flashed, thereby shortening the flash operation time, reducing the impact of flash operation abnormalities caused by high module coupling, and thus improving the security of the flash operation.

[0076] In an embodiment of the present application, the hardware security module receives an upgrade flash request sent by the host, and obtains an upgrade file containing a header data packet and an application data packet from a first cache area, so as to use the upgrade file to perform an upgrade flash operation on the firmware of the task module in the hardware security module.

[0077] Step 202: based on the basic information of the initial task module, the preset symmetric key and the header data packet, the ciphertext data of the initial task module in the application data packet is decrypted to obtain the plaintext data of the initial task module.

[0078] In the embodiment of the present application, the initial task module is the task module corresponding to the first basic information in the basic information stored in the header data packet in module order.

[0079] In an embodiment of the present application, the hardware security module receives an upgrade flash request sent by the host, obtains a header data packet and an application data packet from the upgrade file stored in the first cache area of ​​the hardware security module, obtains basic information of the initial task module in the header data packet, and obtains the ciphertext data of the initial task module from the application data packet based on the basic information of the initial task module; further, the ciphertext data of the initial task module is decrypted based on a preset symmetric key and the header data packet to obtain the plaintext data of the initial task module.

[0080] Step 203: Based on the sub-data signature of the initial task module, use the first public key to decrypt and verify the plaintext data of the initial task module to obtain a first verification result.

[0081] The first public key and the first private key are a pair of keys generated based on a preset encryption system.

[0082] In an embodiment of the present application, before transmitting data between the hardware security module and the management server, an application for one or more preset key pairs (such as a public key and a private key) will be made to the preset encryption system, so that the management server digitally signs the plaintext data (sub-data content) of the task module to be transmitted based on the preset first private key. After the hardware security module decrypts the ciphertext data of the task module and obtains the plaintext data of the task module, it uses the first public key corresponding to the first private key to perform decryption verification to verify the integrity of the plaintext data of the task module and the identity of the sender.

[0083] Here, the operation of digital signature may include: using a hash algorithm to perform a hash operation on the plaintext data of the task module to obtain a corresponding hash value, and using the first private key to digitally sign the hash value of the task module to obtain a sub-data signature of the task module. It should be noted that the length of the hash value can be set according to actual conditions.

[0084] Step 204: If the first verification result indicates that the verification is successful and the initial task module meets the upgrade and rewrite conditions, the initial task module is upgraded and rewritten based on the plaintext data of the initial task module.

[0085] In an embodiment of the present application, the upgrade flashing condition includes that the upgrade version number of the task module in the header data packet is greater than the current version number of the task module running in the hardware security module.

[0086] In the embodiment of the present application, if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and rewrite conditions, the initial task module is upgraded and rewritten based on the plaintext data of the initial task module, including:

[0087] If the first verification result indicates that the verification is successful, the upgraded version number of the initial task module in the basic information is obtained; the current version number of the initial task module currently running in the hardware security module is obtained; if the upgraded version number is greater than the current version number, it is determined that the initial task module meets the upgrade and rewrite conditions; based on the plaintext data of the initial task module, the initial task module is upgraded and rewritten. In this way, on the premise that the plaintext data of the initial task module has been successfully verified, the upgraded version number of the initial task module in the basic information and the version number currently running in the hardware security module are compared. When the upgraded version number is greater than the current version number, it is determined that the upgrade and rewrite conditions are met, thereby ensuring that the upgrade operation is performed on the modules that really need to be updated, and no unnecessary operations are performed on the modules that are already the latest version or are not suitable for upgrading, reducing the possibility of introducing new problems due to unnecessary upgrades, while ensuring that the data source used for the upgrade is reliable, and reducing the risk of security vulnerabilities or failures in the HSM due to the use of tampered data.

[0088] Step 205: Based on the plaintext data of the initial task module, the ciphertext data of the next task module is decrypted until the plaintext data of all task modules are obtained, and the task modules that meet the upgrade and flash conditions are upgraded and flashed.

[0089] In the embodiment of the present application, the hardware security module decrypts the ciphertext data of the initial task module in the application data packet based on the basic information of the initial task module, the preset symmetric key and the header data packet, and obtains the plaintext data of the initial task module, and then determines the next task module corresponding to the next basic information in the basic information stored in the header data packet in the order of modules; then, according to the plaintext data of the initial task module, the ciphertext data of the next task module in the application data packet is decrypted to obtain the plaintext data of the next task module; further, based on the sub-data signature of the next task module in the header data packet, the plaintext data of the next task module is decrypted and verified using the first public key corresponding to the next task module to obtain the first verification result of the next task module. Afterwards, if the first verification result of the next task module indicates that the verification is successful, and the next task module meets the upgrade and flushing conditions, the next task module is upgraded and flushed based on the plaintext data of the next task module; this cycle is repeated to obtain the plaintext data of all task modules, and the upgrade and flushing operation of the task modules that meet the upgrade and flushing conditions is completed.

[0090] It should be noted that step 205 can be executed synchronously with step 203 and step 204, step 205 can also be executed before step 203, step 205 can also be executed after step 204, and of course, step 205 can also be executed after step 203 and before step 204. This application does not make any specific restrictions on this.

[0091] The embodiment of the present application provides a flashing method for a hardware security module, which receives an upgrade flashing request sent by a host end, and obtains a header data packet and an application data packet from an upgrade file stored in a first cache area of ​​the hardware security module; wherein the header data packet includes: a magic number and basic information of multiple task modules, the basic information includes a sub-data signature obtained by signing the sub-data content of the task module based on a first private key; the application data packet includes ciphertext data used by each task module for firmware upgrade flashing, the ciphertext data is encrypted based on a preset symmetric key and a header data packet; based on the basic information of the initial task module, the preset symmetric key and the header data packet, the initial task in the application data packet is encrypted. The ciphertext data of the module is decrypted to obtain the plaintext data of the initial task module; based on the sub-data signature of the initial task module, the plaintext data of the initial task module is decrypted and verified using the first public key to obtain the first verification result, wherein the first public key and the first private key are a pair of keys generated based on the preset encryption system; if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flushing conditions, the initial task module is upgraded and flushed based on the plaintext data of the initial task module; based on the plaintext data of the initial task module, the ciphertext data of the next task module is decrypted until the plaintext data of all task modules are obtained, and the task modules that meet the upgrade and flushing conditions are upgraded and flushed. In this way, the sub-data content of the task module is signed using the first private key to generate a sub-data signature, which can ensure the reliability and integrity of the source of the data. At the same time, the ciphertext data in the application data packet is encrypted based on the preset symmetric key and the header data packet, which effectively prevents the data from being stolen or tampered with during transmission and storage. The task modules are processed in sequence. First, the plaintext data of the initial task module is decrypted and verified. If the conditions are met, the upgrade is performed, and then the next task module is operated based on this. The step-by-step approach can complete the upgrade of all task modules in an orderly manner, reducing the confusion and error probability caused by processing multiple modules at the same time, and when problems occur in the upgrade of a module, they can be located and solved more conveniently without affecting the processing flow of other modules. The upgrade is only performed when the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flushing conditions. This dual judgment mechanism can ensure that the upgrade operation is performed when the data is legal and the module really needs to be upgraded, avoiding potential problems caused by unnecessary upgrades, and also preventing illegal upgrades caused by erroneous data or malicious attacks.

[0092] In some embodiments, before step 201 receives the upgrade flash writing request sent by the host, refer to Figure 4 As shown, you can also perform the following steps:

[0093] Step 301: Receive a header data packet of a hardware security module sent by a host.

[0094] Among them, the header data packet is generated by the management server according to the attribute information of the hardware security module and sent to the host end. The header data packet also includes: the first signature of the application data packet and the second signature of the header data packet. The first signature is obtained by the management server signing the ciphertext data of all task modules based on the second private key, and the second signature is obtained by the management server signing the magic number, the basic information of all task modules and the first signature based on the third private key.

[0095] In actual applications, the management server regularly publishes upgrade information of various services (including hardware security modules). When the host side in the electronic control unit subscribes to the upgrade information of the hardware security module, a secure communication channel is established between the management server and the host side for data transmission.

[0096] Here, when the management server obtains the data content of all task modules of the hardware security module, it signs and / or encrypts the data content of the hardware security module according to the data transmission format agreed with the hardware security module. This process can be implemented as follows:

[0097] First, before the header data packet is transmitted between the management server and the hardware security module, one or more preset key pairs (such as public key and private key) will be applied to the preset encryption system; the magic number, the upgrade version number of each task module in multiple task modules, the memory start address where the sub-data content of each task module is stored, and the memory data length occupied by the sub-data content are obtained;

[0098] Secondly, the sub-data content of each task module is hashed to obtain the hash value of the sub-data content of each task module; the preset first private key is used to digitally sign the hash value of the sub-data content of each task module to obtain the sub-data signature of each task module. And based on the upgrade version number, memory start address, memory data length and sub-data signature of each task module, the basic information of each task module is determined.

[0099] Then, the management server performs a hash operation on the ciphertext data of all task modules to obtain the hash values ​​of the ciphertext data of all task modules, and uses a preset second private key to digitally sign the hash values ​​of the ciphertext data of all task modules to obtain a first signature.

[0100] Furthermore, the management server performs a hash operation on the magic number, the basic information of all task modules, and the first signature to obtain a hash value for determining the header data packet, and uses a preset second private key to digitally sign the hash value for determining the header data packet to obtain a second signature. Finally, based on the magic number, the basic information of each task module, the first signature, and the second signature, the data is encapsulated to obtain the header data packet of the hardware security module. In this way, the header data packet contains the first signature of the application data packet and its own second signature. These signatures are generated by different private keys, and the corresponding public keys are used at the receiving end for decryption verification. This multi-layer signature mechanism greatly enhances the security of the data and ensures the integrity and authenticity of the data from the source (management server). Even if the signature verification of a certain layer is breached, there are other layers of verification as a guarantee.

[0101] Step 302: Use the second public key to decrypt and verify the second signature to obtain a second verification result of the header data packet.

[0102] The second public key and the second private key are a pair of keys generated based on a preset encryption system.

[0103] In this way, the public and private key pairs generated based on the preset encryption system are used for signing and decryption operations. This method ensures the standardization and security of the key, and the encryption and decryption operations in the entire system are consistent and compatible, making the secure communication between different links more reliable.

[0104] Step 303: When the second verification result indicates that the verification is successful, an application data packet sent by the host is received.

[0105] The application data packet is generated by the management server according to the attribute information and sent to the host end.

[0106] In an embodiment of the present application, after receiving the header data packet, a hash operation can be performed on all data contents in the header data packet except the second signature to obtain a hash value for verifying the header data packet; further, the second signature can be decrypted and verified using the second public key to obtain a decrypted hash value of the header data packet, and the hash value used to verify the header data packet is compared with the decrypted hash value of the header data packet. If they are consistent, it indicates that the verification of the header data packet is successful, that is, a second verification result indicating successful verification is obtained, and the second verification result is sent to the host side; at this time, the host side receives the application data packet sent by the management server based on the second verification result, and the application data packet can be generated based on the attribute information (such as identification information) of the hardware security module.

[0107] Here, first, before the application data packet is transmitted between the management server and the hardware security module, an application for a preset symmetric key will be made to the preset encryption system, the initial task module arranged in the module order in the header data packet will be obtained, and a hash operation will be performed on the data content in the header data packet to obtain the hash value of the data content in the header data packet; based on the preset symmetric key and the hash value of the data content in the header data packet, the encryption key of the initial task module is obtained through a key derivation algorithm; the sub-data content of the initial task module is encrypted using the encryption key of the initial task module to obtain the ciphertext data of the initial task module; further, the sub-data content of the initial task module is ciphered to obtain the hash value of the sub-data content of the initial task module; based on the encryption key of the initial task module and the hash value of the sub-data content of the initial task module, the encryption key of the next task module is obtained through a key derivation algorithm; the sub-data content of the next task module is encrypted using the encryption key of the next task module to obtain the ciphertext data of the next task module; this cycle is repeated to realize the ciphertext data of all task modules; finally, based on the ciphertext data of all task modules, the data is encapsulated to obtain the application data packet of the hardware security module. In this way, both the header data packet and the application data packet are generated by the management server according to the attribute information of the hardware security module. By verifying the signatures of these data packets, it can be confirmed that the data comes from a legitimate management server. This prevents malicious attackers from forging upgrade data, ensures that the source of the upgrade data is reliable, and protects the hardware security module from the threat of malware or illegal upgrades.

[0108] Step 304: Use the third public key to decrypt and verify the first signature to obtain a third verification result of the application data packet.

[0109] The third public key and the third private key are a pair of keys generated based on a preset encryption system.

[0110] Step 305: When the third verification result indicates that the verification is successful, the header data packet and the application data packet are stored in the first cache area, and the third signature verification result is sent to the host end, so that the host end sends an upgrade flash request according to the third signature verification result.

[0111] In the embodiment of the present application, after receiving the application data packet, the hardware security module can perform a hash operation on the ciphertext data of all task modules in the application data packet to obtain a hash value for verifying the application data packet; further, the first signature can be decrypted and verified using the third public key to obtain a hash value after the application data packet is decrypted, and the hash value used to verify the application data packet is compared with the hash value after the application data packet is decrypted. If they are consistent, the verification of the application data packet is successful, that is, a third verification result representing the successful verification is obtained, and the third verification result is sent to the host end; at this time, the host end sends an upgrade flash write request to the hardware security module according to the third verification result in order to perform an upgrade flash write operation. In this way, before receiving the upgrade flash write request sent by the host end, the receiving, verification and storage process of the header data packet and the application data packet is first performed. This staged processing method can detect data problems at an early stage and avoid potential risks caused by discovering data errors during the upgrade flash write process, such as system failures or security vulnerabilities. The third verification result is sent to the host end, so that the host end sends an upgrade flash write request according to this result. This interactive mechanism ensures the coordination between the host and the hardware security module. The upgrade process is only started after the data verification is successful, ensuring the consistency and security of the entire upgrade process.

[0112] In some embodiments, after completing the upgrade and flashing of each task module, refer to Figure 5 As shown, the following steps 401 to 405, or steps 401 to 404 and 406 may also be performed:

[0113] Step 401: After each task module is upgraded and flashed, the plain text data of the task module is encrypted using a preset secure boot key to obtain a first verification code, and the first verification code is stored in a second cache area.

[0114] In the embodiment of the present application, before the hardware security module upgrades and flashes the task module, it will apply to the preset encryption system for a preset secure boot key, which is used to verify the task module after the upgrade and flash operation, and the various task modules involved in the first restart of the ECU after the upgrade and flash operation. Among them, the preset secure boot key is a symmetric key.

[0115] In the embodiment of the present application, the first verification code may be a Cipher-based Message Authentication Code (CMAC).

[0116] In an embodiment of the present application, after each task module is upgraded and flashed, the plaintext data of the task module is encrypted using a preset secure startup key to obtain a first verification code, and the first verification code is stored in a second cache area so that the task modules involved can be verified when the electronic control unit is restarted for the first time.

[0117] Step 402: When the electronic control unit is restarted, the boot loader module of the hardware security module uses a one-time programmable mode to determine the main task module of the hardware security module;

[0118] Step 403: Generate a second verification code of the main task module by using the preset secure boot key through the boot loading module;

[0119] Step 404: compare the second check code with the first check code corresponding to the main task module stored in the second buffer area to obtain a comparison result.

[0120] Step 405: If the comparison result indicates that the main task module is legal, determine that the hardware security module is started normally and jump to the main task module. When the main task module works normally, determine the legality of the remaining task modules in turn according to the order of processing tasks through the main task module.

[0121] Step 406: If the comparison result indicates that the main task module is illegal, jump to the third storage area of ​​the main task module to roll back the code of the main task module.

[0122] Among them, the third storage area stores data of historical versions of the main task module.

[0123] In some embodiments, the hardware security module may include a boot loader module, a main task module, and other task modules.

[0124] The bootloader module is the first software part that runs when the hardware security module starts. The bootloader module is responsible for initializing the hardware device, including setting the CPU clock frequency, initializing the memory controller, and configuring various on-chip peripherals (such as encryption engines, communication interfaces, etc.). For example, the bootloader module initializes the memory, sets the memory's operating mode and access rights, and ensures that the main task module and other modules have a stable memory environment during operation.

[0125] The main task module is responsible for executing the main security policies and encryption algorithms. For example, in terms of key management, the main task module can generate, store, distribute and update keys. For symmetric keys, it can use a secure random number generator to generate keys and store them in a secure storage area inside the HSM.

[0126] Other task modules can provide some auxiliary security functions. For example, a dedicated logging module can record important security events that occur inside the HSM, such as the use of keys, the processing results of access requests, etc.

[0127] In an embodiment of the present application, when the electronic control unit is restarted, the boot loading module of the hardware security module uses a one-time programmable (OTP) mode to determine the main task module of the hardware security module; through the boot loading module, a preset security startup key is used to generate a second verification code of the main task module; the first verification code of the main task module stored in the second cache area is obtained, and the second verification code is compared with the first verification code to obtain a comparison result; if the comparison result indicates that the main task module is legal, it is determined that the hardware security module is started normally and jumps to the main task module, and when the main task module is working normally, the main task module determines the legitimacy of the remaining task modules in turn according to the order of processing tasks, and checks whether other task modules have been tampered with; if the comparison result indicates that the main task module is illegal, jump to the third storage area of ​​the main task module, roll back the code of the main task module, and send a message of the abnormality of the main task module to the host side.

[0128] Here, when the main task module is working normally, the main task module determines the legitimacy of the remaining task modules in turn according to the order of processing tasks, including: determining the order of each task module according to the order of processing tasks, and calculating the second verification code of the task module currently being processed according to the order of the task modules by adopting a preset security startup key, and comparing the first verification code of the task module currently being processed with the first verification code of the task module stored in the second cache area. If they are inconsistent, the host side is notified that the task module is abnormal, and the third cache area, i.e., the backup partition, is jumped to perform code rollback of the task module.

[0129] From the above, it can be seen that since fast startup is an important communication indicator of the electronic control unit, the boot loading module of the hardware security module adopts the OTP mode to quickly verify the HSM main task module to ensure that the HSM starts normally and quickly, and then the HSM main task module verifies other modules in turn, thus improving the startup speed and processing efficiency.

[0130] Reference Figure 6 As shown, Figure 6 A schematic diagram of a flashing method for a hardware security module provided in an embodiment of the present application, the method is applied to Figure 1 The hardware security module in the electronic control unit in the system shown is communicatively connected with the host end in the electronic control unit. The method can be implemented by the following steps:

[0131] Step 501: Receive an upgrade flash request sent by a host, and obtain a header data packet and an application data packet from an upgrade file stored in a first buffer area of ​​a hardware security module.

[0132] Among them, the header data packet includes: the magic number and basic information of multiple task modules, the basic information includes the sub-data signature obtained by signing the sub-data content of the task module based on the first private key; the application data packet includes the ciphertext data used by each task module for firmware upgrade and flashing, and the ciphertext data is encrypted based on the preset symmetric key and the header data packet.

[0133] The basic information also includes the memory start address and memory data length of the task module.

[0134] Step 502: based on the memory start address and memory data length of the initial task module, obtain the ciphertext data of the initial task module from the application data packet;

[0135] Step 503: Perform a hash operation on the magic number in the header data packet and basic information of multiple task modules to obtain a first hash value of the header data packet;

[0136] Step 504: Generate a decryption key for the initial task module based on the preset symmetric key and the first hash value through a key derivation algorithm;

[0137] Step 505: Use the decryption key of the initial task module to decrypt the ciphertext data of the initial task module to obtain the plaintext data of the initial task module.

[0138] In an embodiment of the present application, the hardware security module receives an upgrade flash request sent by the host, obtains a header data packet and an application data packet from the upgrade file stored in the first cache area of ​​the hardware security module, and then obtains the memory start address and memory data length of the initial task module in the header data packet; according to the memory start address and memory data length of the initial task module, the ciphertext data of the initial task module is obtained from the application data packet; further, a hash operation is performed on the magic number in the header data packet and the basic information of multiple task modules to obtain a first hash value of the header data packet; then, based on the preset symmetric key and the first hash value, a decryption key of the initial task module is generated through a key derivation algorithm; finally, the ciphertext data of the initial task module is decrypted using the decryption key of the initial task module to obtain the plaintext data of the initial task module. In this way, the ciphertext data is obtained from the application data packet based on the memory start address and memory data length of the initial task module, so that the data of the specific task module can be accurately located, unnecessary data reading and processing can be avoided, and the efficiency of the upgrade process is improved; the magic number in the header data packet and the basic information of multiple task modules are hashed to obtain the first hash value, and then the decryption key of the initial task module is generated through a key derivation algorithm based on the preset symmetric key and the first hash value, ensuring that the generation of the decryption key is based on specific information related to the upgrade data, increasing the key's pertinence and security, and even if the attacker obtains the preset symmetric key, it is difficult to generate a valid decryption key without the correct header data packet information, thereby protecting the security of the ciphertext data.

[0139] Step 506: Based on the sub-data signature of the initial task module, use the first public key to decrypt and verify the plaintext data of the initial task module to obtain a first verification result.

[0140] The first public key and the first private key are a pair of keys generated based on a preset encryption system.

[0141] In some embodiments, step 506 is based on the sub-data signature of the initial task module, and uses the first public key to perform decryption verification on the plaintext data of the initial task module to obtain a first verification result. This can be achieved by the following steps: performing a hash operation on the plaintext data of the initial task module to obtain a second hash value; decrypting the sub-data signature of the initial task module using the first public key to obtain a third hash value; comparing the second hash value and the third hash value to obtain a first verification result. In this way, the plaintext data of the initial task module is hashed to obtain the second hash value, and the sub-data signature of the initial task module is decrypted using the first public key to obtain the third hash value. By comparing these two hash values, the integrity of the data can be effectively verified. If the plaintext data is tampered with during transmission or storage, the calculated second hash value will be different from the third hash value, so that the data can be damaged in time.

[0142] Step 507: If the first verification result indicates successful verification and the initial task module meets the upgrade and flashing conditions, upgrade and flash the initial task module based on the plaintext data of the initial task module.

[0143] Step 508: There are N task modules. Perform a hash operation on the plaintext data of the nth task module to obtain the second hash value of the nth task module.

[0144] Where 1 < n < N, n is an integer, and N is an integer greater than 1.

[0145] Step 509: Based on the decryption key of the nth task module and the second hash value of the nth task module, generate the decryption key of the nth task module through a key derivation algorithm.

[0146] Step 510: Use the decryption key of the nth task module to decrypt the ciphertext data of the nth task module to obtain the plaintext data of the nth task module.

[0147] Step 511: Based on the sub-data signature of the nth task module, use the first public key corresponding to the nth task module to perform signature verification on the plaintext data of the nth task module to obtain the first verification result corresponding to the nth task module.

[0148] Step 512: If the first verification result corresponding to the nth task module indicates successful verification and the nth task module meets the upgrade and flashing conditions, upgrade and flash the nth task module based on the plaintext data of the nth task module, thereby completing the upgrade and flashing of the task modules that meet the upgrade and flashing conditions.

[0149] In the embodiments of the present application, during the entire upgrade and flashing process, for each task module, it is necessary to check the first verification result and judge the upgrade and flashing conditions. This multiple verification mechanism includes signature verification of sub-data signatures using public keys and matching checks with upgrade and flashing conditions, which can effectively prevent illegal or tampered data from being used for upgrades. Perform a hash operation on the plaintext data of the previous task module, and based on this and the decryption key of the previous task module, generate the decryption key of the current task module through a key derivation algorithm, so that the decryption key of each task module is related to the hash value and decryption key of the plaintext data of the previous task module, further increasing the confidentiality of the key. In this way, taking the integrity of the data packet of a single module and the decryption key of a single module as factors to derive the decryption key of the next module increases the coupling degree between module packets and ensures the transmission security of the HSM upgrade package.

[0150] Furthermore, by checking whether each task module meets the upgrade and flashing conditions, it is ensured that only the appropriate task modules are upgraded. This can avoid system failures caused by incompatible or incorrect upgrades. Each task module is processed in sequence, from the 1st task module to the Nth task module. This orderly upgrade method can reduce the mutual interference between different task modules and reduce the probability of conflicts that may be caused by upgrading multiple task modules at the same time. Each task module is upgraded only after its previous task module is successfully upgraded or meets the corresponding conditions, which helps maintain the stability of the system during the upgrade process.

[0151] In an example implementation scenario, refer to Figure 7 As shown, Figure 1 The flashing method of the hardware security module is described in the flashing system of the hardware security module composed of the management server (such as OTA server) in the electronic control unit (ECU), the host (Host) end and the hardware security module HSM:

[0152] Step S601: The OTA server regularly publishes OTA upgrade information;

[0153] Step S602: When the host in the ECU subscribes to OTA upgrade information, the host establishes HTTPS two-way authentication with the OTA server, thereby establishing a secure channel to obtain the HSM upgrade package.

[0154] Here, the HSM upgrade package (corresponding to the above-mentioned upgrade file) includes a Header package (corresponding to the above-mentioned header data package) and an APP (application, APP) package (corresponding to the above-mentioned application data package). HTTPS is Hypertext Transfer Protocol Secure.

[0155] Step S603: The Host receives the Header packet sent by the OTA server through a secure channel.

[0156] Here, the Header package consists of: magic number, information of each module, APP package signature and Header package signature; among which, the information of each module includes the version number of the module, the starting address of the module, the data length of the module and the signature of the module.

[0157] Step S604: The Host sends the Header packet to the HSM through the shared memory channel.

[0158] Here, the shared memory channel can be implemented through the inter-process communication (IPC) mechanism of shared memory, so that processes can exchange data, synchronize operations, and control each other. It should be noted that shared memory, as one of the efficient IPC methods, allows multiple processes to access the same memory area to achieve data sharing and interaction.

[0159] Step S605: HSM performs signature verification operation on the Header package.

[0160] Here, the HSM can perform a signature verification operation on the Header package using the pre-made public key of the asymmetric algorithm - PK0 to obtain the signature verification result of the Header package.

[0161] Step S606: The HSM sends a successful signature verification result of the Header packet to the Host.

[0162] Here, the Host determines whether to receive the APP package sent by the OTA server based on the verification result of the Header package. Here, if the verification result indicates that the verification is successful, the Header package is considered to be legal, and the Host side can receive the APP package sent by the OTA server.

[0163] Here, a full-function analysis of the hardware security module is conducted based on the function type and function correlation, and the APP package is split into modules with very low coupling, including but not limited to: general algorithm module, digital key module, secure communication module, TLS module, secure boot module, etc. Each module is version managed and flashed separately.

[0164] Step S607: The Host receives the APP package sent by the OTA server through a secure channel;

[0165] Step S608: The Host transmits the APP package to the HSM through the IPC channel;

[0166] Step S609: HSM performs signature verification operation on the APP package.

[0167] Here, after obtaining the complete APP package, the HSM uses the pre-made asymmetric algorithm public key PK0 to perform a signature verification operation on the APP package. If the signature verification is successful, the APP package is considered to be legal, and the Host side can subsequently trigger the HSM side to perform a flash operation.

[0168] Step S610: HSM sends the verification result of the successful verification of the APP package to the Host side.

[0169] Here, the Host determines whether to trigger the HSM to perform a flash operation based on the signature verification result of the APP package. Here, if the signature verification result indicates that the verification is successful, the APP package is considered to be legal, and the Host can subsequently send an upgrade flash request to the HSW, thereby triggering the HSM to perform a flash operation.

[0170] Step S611: The Host sends an upgrade flash request to the HSM.

[0171] Step S612: HSM obtains the version number of the module in the Header package. If the version number of the module is greater than the local module version number, it determines that the corresponding module is the target module that needs to perform a flash operation.

[0172] Here, HSM obtains the version information of each module in the Header package in turn and compares the version numbers. If the version number of the module in the upgrade package is greater than the local module version number, the module is the target module that needs to be flashed.

[0173] Step S613, HSM obtains the encrypted data content of the target module in the APP package according to the address and length of the target module in the Header package, and uses the decryption key -K1 to decrypt the data content of the target module to obtain the decrypted content of the target module.

[0174] Here, HSM will extract the magic, version information and / or basic information of each module from the Header package to form a set of serial data, and obtain a 32-byte hash value through the hash algorithm. HSM will use the preset symmetric algorithm key -K0 and the hash value to generate the symmetric algorithm decryption key -K1 of the initial module in the APP package, that is, the target module, through the KDF algorithm. HSM takes out the encrypted data content of the module in the APP package according to the address and length of the module in the Header package, and uses the decryption key -K1 to decrypt the encrypted data content of the module to obtain the decrypted content of the module and the target module.

[0175] Step S614: The HSM performs a signature verification operation on the decrypted content of the target module using the pre-made public key of the asymmetric algorithm - PK0 to obtain a signature verification result.

[0176] Here, if the signature verification result is successful, execute step 615; if the signature verification result indicates a failure, execute step 616.

[0177] Here, the HSM side verifies the decrypted content of the target module through the pre-made asymmetric algorithm public key -PK0. If the verification fails, the reason for the flash failure can be recorded and the HSM flash failure information can be returned to the Host. If the signature verification succeeds, the module is flashed based on the decrypted data content.

[0178] Step S615: The HSM performs an upgrade and flash operation on the target module based on the decrypted content of the target module.

[0179] Step S616: The HSM returns the HSM flash failure information of the module to the Host.

[0180] Here, the HSM can record the reason for the flash failure and return the HSM flash failure information to the Host.

[0181] Step S617, HSM will extract the decrypted content of the current module, process the decrypted content of the current module through the hash algorithm, and obtain a 32-byte hash value; use the decryption key - K1 and hash value of the current module, through the KDF algorithm, to generate the symmetric algorithm decryption key - K2 of the next module, and the subsequent modules will be carried out in sequence.

[0182] For example, the decryption process of multiple modules in the APP package is as follows: Figure 8 shown.

[0183] Here, step S617 is performed after step S615.

[0184] Step S618: When the HSM completes the flash operation on a single module, the HSM will use the preset secure boot key -KS to calculate the CMAC value of the module and update it in DataFlash.

[0185] Here, DataFlash is a data flash memory area, corresponding to the second cache area mentioned above.

[0186] Here, after a single module completes the flash operation, the HSM will use the preset secure boot key -KS to calculate the CMAC value of the module and update it in DataFlash. The following modules will be updated in sequence until all modules are updated, and then the startup verification will begin.

[0187] Step S619: After the ECU is restarted, the HSM bootloader generates the CMAC of the main task module and compares it with the CMAC of the main task module stored in DataFlash.

[0188] Here, if they are inconsistent, execute step 620 to step 621; if they are consistent, execute step 622.

[0189] Here, after the ECU is restarted, the HSM bootloader will first check the CMAC of the main task module, generate a CMAC for verification with the startup CMAC in DataFlash, if they are consistent, the HSM starts normally and jumps to the main task module of the HSM APP; otherwise, it jumps to the backup partition and rolls back the code of the main task module.

[0190] Step S620: HSM sends information about the abnormality of the module currently being processed to the Host;

[0191] Step S621: Jump to the standby partition to obtain the historical version data of the module currently being processed.

[0192] Here, if the CMAC value of a single module is inconsistent, the Host is notified of the single module abnormality, and the backup partition is jumped to perform code rollback of the single module.

[0193] Here, step S621 is performed after step S620.

[0194] Step S622, HSM starts normally and jumps to the main task module of the HSM APP; after the APP main task module works normally, the main task module verifies the legitimacy of other modules in turn according to the processing tasks, checks whether the APP has been tampered with, and calculates the CMAC value of the module by using the preset secure startup key -KS, and compares it with the CMAC value saved in DataFlash.

[0195] Here, if they are inconsistent, return to steps 620 and 621 for execution; if they are consistent, continue to verify the legality of the next module according to the processing task sequence in step 622.

[0196] Here, after the APP main task module works normally, the main task module will have a task to verify the legitimacy of other modules in turn to see if the APP has been tampered with. The CMAC value of the module is calculated using the preset secure boot key -KS, and compared with the CMAC value saved in DataFlash. If the CMAC value of a single module is inconsistent, the Host is notified of the single module abnormality, and the backup partition is jumped to perform a code rollback of the single module.

[0197] From the above, it can be seen that the embodiment of the present application adopts HSM to divide the APP into relatively independent single modules according to the function type and the correlation of the functions, and each module performs independent version management and flashing, which shortens the Flash operation time as much as possible and reduces the impact of abnormal Flash operations; the integrity of the module package is used as a factor to derive the decryption key of the next module, which ensures the transmission security of the HSM upgrade package and increases the coupling degree between module packages; because fast startup is an important communication indicator of ECU, if the HSM bootloader adopts the OTP mode, the HSM main task module is quickly verified to ensure the normal and fast startup of the HSM, and then the HSM main task module verifies other modules in turn.

[0198] The present application embodiment provides a flashing device for a hardware security module, referring to Fig. 9 As shown, Fig. 9 A schematic diagram of the structure of a flashing device for a hardware security module provided in an embodiment of the present application, wherein the flashing device 8 for the hardware security module comprises:

[0199] The receiving module 801 is used to receive an upgrade flashing request sent by the host end, and obtain a header data packet and an application data packet from the upgrade file stored in the first buffer area of ​​the hardware security module; wherein the header data packet includes: a magic number and basic information of multiple task modules, the basic information includes a sub-data signature obtained by signing the sub-data content of the task module based on the first private key; the application data packet includes ciphertext data used by each task module for firmware upgrade flashing, and the ciphertext data is encrypted based on the preset symmetric key and the header data packet;

[0200] The processing module 802 is used to decrypt the ciphertext data of the initial task module in the application data packet based on the basic information of the initial task module, the preset symmetric key and the header data packet to obtain the plaintext data of the initial task module;

[0201] The processing module 802 is further used to perform decryption verification on the plaintext data of the initial task module based on the sub-data signature of the initial task module using the first public key to obtain a first verification result, wherein the first public key and the first private key are a pair of keys generated based on a preset encryption system;

[0202] The processing module 802 is further configured to upgrade and rewrite the initial task module based on the plaintext data of the initial task module if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and rewrite conditions;

[0203] The processing module 802 is also used to decrypt the ciphertext data of the next task module based on the plaintext data of the initial task module until the plaintext data of all task modules are obtained, and to upgrade and rewrite the task modules that meet the upgrade and rewrite conditions.

[0204] The present application embodiment provides a flashing device for a hardware security module, the device comprising: a transceiver, a memory and a processor.

[0205] The memory stores a computer program executable on the processor;

[0206] The transceiver is used to perform the operation of receiving data or sending data under the control of the processor;

[0207] When the processor executes the computer program, part or all of the steps in the flashing method of the hardware security module described in the above embodiment are implemented.

[0208] The embodiment of the present application provides a computer-readable storage medium, which stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to implement some or all of the steps in the above method. The storage medium can be transient or non-transient.

[0209] An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is run in a flashing device of a hardware security module, a processor in the flashing device of the hardware security module executes some or all of the steps for implementing the above method.

[0210] The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0211] It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the device, storage medium, computer program and computer program product of this application, please refer to the description of the method embodiment of this application for understanding.

[0212] A hardware entity diagram of a flashing device for a hardware security module provided in an embodiment of the present application is as follows: Fig.10 As shown, the hardware entity of the flashing device 9 of the hardware security module includes: a processor 901, a memory 902 and a transceiver 903, wherein the memory 902 stores a computer program that can be run on the processor 901, and the transceiver 903 is used to perform operations of receiving data or sending data under the control of the processor; the processor 901 executes part or all of the steps in the flashing method of the hardware security module described above.

[0213] Among them, the memory 902 stores a computer program that can be run on the processor. The memory 902 is configured to store instructions and applications executable by the processor 901. It can also cache data to be processed or processed by each module in the processor 901 and the flash device 9 of the hardware security module (for example, image data, audio data, voice communication data, and video communication data), which can be implemented through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0214] The processor 901 implements any of the above steps of the flashing method for the hardware security module when executing the program. The processor 901 usually controls the overall operation of the flashing device 9 for the hardware security module.

[0215] The transceiver 903 receives data or sends data under the control of the processor.

[0216] An embodiment of the present application provides a storage medium, which stores one or more computer programs. The one or more computer programs can be executed by one or more processors to implement the steps of the flashing method of the hardware security module of any of the above embodiments.

[0217] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0218] The processor may be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understandable that the electronic device that implements the functions of the processor may also be other, and the embodiments of the present application are not specifically limited.

[0219] The above-mentioned computer storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0220] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0221] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0222] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0223] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple convolutional network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0224] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0225] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0226] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a vehicle-mounted terminal (which can be a personal computer, server, or network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0227] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A flashing method for a hardware security module, characterized in that: The method is applied to a hardware security module in an electronic control unit. The hardware security module is communicatively connected to a host side in the electronic control unit. The method includes: Receiving an upgrade flashing request sent by the host side, and obtaining a header data packet and application program data packets from upgrade files stored in a first buffer area of the hardware security module. Wherein, the header data packet includes: a magic number and basic information of multiple task modules. The basic information includes a sub-data signature obtained by signing sub-data content of the task module based on a first private key. The application program data packets include ciphertext data for firmware upgrade flashing of each task module, and the ciphertext data is encrypted based on a preset symmetric key and the header data packet; Based on the basic information of the initial task module, the preset symmetric key, and the header data packet, decrypting the ciphertext data of the initial task module in the application program data packets to obtain the plaintext data of the initial task module; Based on the sub-data signature of the initial task module, using a first public key to perform signature verification on the plaintext data of the initial task module to obtain a first verification result. Wherein, the first public key and the first private key are a pair of keys generated based on a preset encryption system; If the first verification result indicates successful verification and the initial task module meets the upgrade flashing condition, perform upgrade flashing on the initial task module based on the plaintext data of the initial task module; Based on the plaintext data of the initial task module, decrypt the ciphertext data of the next task module until the plaintext data of all task modules is obtained, and perform upgrade flashing on the task modules that meet the upgrade flashing condition.

2. The method according to claim 1, characterized in that The basic information includes the memory start address and memory data length of the task module. The decrypting the ciphertext data of the initial task module in the application program data packets based on the basic information of the initial task module, the preset symmetric key, and the header data packet to obtain the plaintext data of the initial task module includes: Based on the memory start address and memory data length of the initial task module, obtaining the ciphertext data of the initial task module from the application program data packets; Performing a hash operation on the magic number and the basic information of multiple task modules in the header data packet to obtain a first hash value of the header data packet; Based on the preset symmetric key and the first hash value, generating a decryption key for the initial task module through a key derivation algorithm; Using the decryption key of the initial task module to decrypt the ciphertext data of the initial task module to obtain the plaintext data of the initial task module.

3. The method according to claim 2, characterized in that There are N task modules, where N is an integer greater than 1. The decrypting the ciphertext data of the next task module based on the plaintext data of the initial task module includes: Performing a hash operation on the plaintext data of the nth task module to obtain a second hash value of the nth task module. Wherein, 1 < n < N and n is an integer; Based on the decryption key of the nth task module and the second hash value of the nth task module, generating a decryption key for the nth task module through the key derivation algorithm; The decryption key of the nth task module is used to decrypt the ciphertext data of the nth task module to obtain the plaintext data of the nth task module.

4. The method according to claim 1, characterized in that: The sub-data signature based on the initial task module uses the first public key to perform decryption verification on the plaintext data of the initial task module to obtain a first verification result, including: Performing a hash operation on the plaintext data of the initial task module to obtain a second hash value; Decrypting the sub-data signature of the initial task module using the first public key to obtain a third hash value; The second Hash value and the third Hash value are compared to obtain the first verification result.

5. The method according to claim 1, characterized in that If the first verification result indicates that the verification is successful and the initial task module meets the upgrade and flashing condition, upgrading and flashing the initial task module based on the plaintext data of the initial task module includes: If the first verification result indicates that the verification is successful, obtaining an upgraded version number of the initial task module in the basic information; Obtaining a current version number of the initial task module currently running in the hardware security module; If the upgraded version number is greater than the current version number, it is determined that the initial task module meets the upgrade flashing condition; Based on the plaintext data of the initial task module, the initial task module is upgraded and rewritten.

6. The method according to any one of claims 1 to 5, characterized in that: The multiple task modules are obtained by dividing all functions in the hardware security module based on function types and function associations.

7. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: After each of the task modules is upgraded and flashed, the plaintext data of the task module is encrypted using a preset secure startup key to obtain a first verification code, and the first verification code is stored in a second cache area; In the case where the electronic control unit is restarted, the boot loading module of the hardware security module adopts a one-time programmable mode to determine the main task module of the hardware security module; Generate a second verification code of the main task module by using the preset secure startup key through the boot loading module; Compare the second check code with the first check code corresponding to the main task module stored in the second buffer area to obtain the comparison result; If the comparison result indicates that the main task module is legal, determine that the hardware security module is started normally and jump to the main task module, and when the main task module works normally, determine the legality of the remaining task modules in turn according to the order of processing tasks through the main task module; If the comparison result indicates that the main task module is illegal, jump to the third storage area of ​​the main task module to roll back the code of the main task module, wherein the third storage area stores data of historical versions of the main task module.

8. The method according to any one of claims 1 to 5, characterized in that: Before receiving the upgrade flashing request sent by the host, the method includes: Receive a header data packet of the hardware security module sent by the host end; wherein the header data packet is generated by a management server according to the attribute information of the hardware security module and sent to the host end, and the header data packet also includes: a first signature of the application data packet and a second signature of the header data packet, the first signature is obtained by the management server signing the ciphertext data of all the task modules based on the second private key, and the second signature is obtained by the management server signing the magic number, the basic information of all the task modules and the first signature based on the third private key; Decrypting and verifying the second signature using a second public key to obtain a second verification result of the header data packet, wherein the second public key and the second private key are a pair of keys generated based on the preset encryption system; When the second verification result indicates that the verification is successful, receiving the application data packet sent by the host end; wherein the application data packet is generated by the management server according to the attribute information and sent to the host end; Decrypting and verifying the first signature using a third public key to obtain a third verification result of the application data packet, wherein the third public key and the third private key are a pair of keys generated based on the preset encryption system; When the third verification result indicates that the verification is successful, the header data packet and the application data packet are stored in the first cache area, and the third signature verification result is sent to the host end, so that the host end sends the upgrade flash request according to the third signature verification result.

9. A flashing device for a hardware security module, characterized in that: The device comprises: A receiving module, used to receive an upgrade flashing request sent by a host end, and obtain a header data packet and an application data packet from an upgrade file stored in a first buffer area of ​​the hardware security module; wherein the header data packet includes: a magic number and basic information of multiple task modules, the basic information includes a sub-data signature obtained by signing the sub-data content of the task module based on a first private key; the application data packet includes ciphertext data used by each task module for firmware upgrade flashing, the ciphertext data is encrypted based on a preset symmetric key and the header data packet; A processing module, used to decrypt the ciphertext data of the initial task module in the application data packet based on the basic information of the initial task module, the preset symmetric key and the header data packet to obtain the plaintext data of the initial task module; The processing module is further used to perform decryption verification on the plaintext data of the initial task module using the first public key based on the sub-data signature of the initial task module to obtain a first verification result, wherein the first public key and the first private key are a pair of keys generated based on a preset encryption system; The processing module is further configured to upgrade and rewrite the initial task module based on the plaintext data of the initial task module if the first verification result indicates that the verification is successful and the initial task module meets the upgrade and rewrite conditions; The processing module is also used to decrypt the ciphertext data of the next task module based on the plaintext data of the initial task module until the plaintext data of all task modules are obtained, and upgrade and rewrite the task modules that meet the upgrade and rewrite conditions.

10. A flashing device for a hardware security module, characterized in that: The device comprises a memory, a processor and a transceiver, The memory stores a computer program executable on the processor; The transceiver is used to perform the operation of receiving data or sending data under the control of the processor; When the processor executes the computer program, the flashing method of the hardware security module according to any one of claims 1 to 8 is implemented.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to implement the flashing method of the hardware security module as described in any one of claims 1 to 8.

12. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the flashing method of the hardware security module according to any one of claims 1 to 8 is implemented.

Images