A hardware security module flashing method, device, equipment, medium and product

Abstract

The application discloses a kind of hardware security module's method of writing, method includes: receiving the upgrade writing request sent by host end, obtains header packet and application packet;Based on the basic information of initial task module, preset symmetric key and header packet, the ciphertext data of initial task module in application packet is decrypted, and the plaintext data of initial task module is obtained;Based on the sub-data signature of initial task module, the plaintext data of initial task module is verified using the first public key, and the first verification result is obtained;If the first verification result represents that verification is successful and initial task module satisfies upgrade writing condition, based on the plaintext data of initial task module, initial task module is upgraded and written;Based on the plaintext data of initial task module, the ciphertext data of next task module is decrypted, until the plaintext data of all task modules is obtained, and the task module satisfying upgrade writing condition is upgraded and written.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and in particular to a method, apparatus, device, medium, and product for flashing a hardware security module. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, the security risks faced by automotive software are becoming increasingly severe. Information security issues such as data breaches, malicious attacks, unauthorized access, and the illegal acquisition or alteration of sensitive information are emerging one after another. In existing Electronic Control Units (ECUs), to effectively protect the confidentiality and integrity of assets, customizable Hardware Security Modules (HSMs) are typically used to protect related assets in the ECU's timing sequence. As specialized encryption devices, HSMs support various secure cryptographic services, possess robust security mechanisms and key management functions, and can establish secure communication channels between ECUs within the vehicle, ensuring the secure operation of the firmware.

[0003] However, with the widespread application of HSMs in numerous scenarios and their increasingly complex functions, the "never update" firmware strategy for HSMs can no longer be maintained. Therefore, how to safely, conveniently, and quickly update the firmware of HSMs while ensuring the safety of the vehicle's ECUs has become a pressing issue that needs to be addressed. Summary of the Invention

[0004] One of the purposes of this application is to provide a method, apparatus, device, medium, and product for flashing a hardware security module, so as to ensure that the vehicle ECU security is not affected while the HSM can be updated safely, conveniently, and quickly.

[0005] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows:

[0006] In a first aspect, this application provides a method for flashing 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 in the electronic control unit, the method comprising:

[0007] The system receives an upgrade flashing request sent by the host and retrieves a header data packet and an application data packet from the upgrade file stored in the first cache of the hardware security module. The header data packet includes a magic number and basic information about multiple task modules, the basic information including a sub-data signature obtained by signing the sub-data content of the task modules 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 being encrypted based on a preset symmetric key and the header data packet.

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

[0009] Based on the sub-data signature of the initial task module, the plaintext data of the initial task module is de-signed and verified 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;

[0010] If the first verification result indicates successful verification 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.

[0011] 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 is obtained, and the task modules that meet the upgrade and flashing conditions are upgraded and flashed.

[0012] Based on the aforementioned technical means, the encrypted data in the application data packet is encrypted using a pre-set symmetric key and header data packet, effectively preventing data from being stolen or tampered with during transmission and storage. Task modules are processed sequentially: first, the plaintext data of the initial task module is decrypted and verified; if the conditions are met, an upgrade is performed, and then the next task module is operated on based on this. This step-by-step approach ensures the orderly completion of upgrades for all task modules, reducing the probability of confusion and errors that may result from processing multiple modules simultaneously. Furthermore, it facilitates easier location and resolution of problems encountered during the upgrade of a particular module. The upgrade only occurs when the first verification result indicates successful verification and the initial task module meets the upgrade conditions. This dual-judgment mechanism ensures that the upgrade operation is performed only when the data is legitimate and the module genuinely needs an upgrade, avoiding potential problems caused by unnecessary upgrades and preventing illegal upgrades due to erroneous data or malicious attacks.

[0013] Further, the basic information includes the memory start 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 memory start address and the memory data length of the initial task module; performing a hash 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.

[0014] According to the above technical means, obtaining the ciphertext data from the application program packet based on the memory start 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 hash 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.

[0015] 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 hash 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.

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

[0017] Furthermore, the step of designing and verifying 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 the first verification result includes: 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; and comparing the second hash value and the third hash value to obtain the first verification result.

[0018] Based on the aforementioned technical methods, a second hash value is obtained by hashing the plaintext data of the initial task module. Simultaneously, a third hash value is obtained by decrypting the sub-data signature of the initial task module using the first public key. By comparing these two hash values, data integrity can be effectively verified. If the plaintext data is tampered with during transmission or storage, the calculated second hash value will differ from the third hash value, thus enabling timely detection of data corruption.

[0019] Furthermore, if the first verification result indicates successful verification and the initial task module meets the upgrade flashing conditions, upgrading and flashing the initial task module based on the plaintext data of the initial task module includes: if the first verification result indicates successful verification, obtaining the upgrade version number of the initial task module in the basic information; obtaining the current version number of the initial task module currently running on the hardware security module; if the upgrade version number is greater than the current version number, determining that the initial task module meets the upgrade flashing conditions; and upgrading and flashing the initial task module based on the plaintext data of the initial task module.

[0020] Based on the aforementioned technical means, assuming 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 is compared with the current running version number of the hardware security module. Only when the upgrade version number is greater than the current version number is it determined that the upgrade flashing conditions are met. This ensures that the upgrade operation is performed on the modules that truly need updating, and avoids unnecessary operations on modules that are already the latest version or are not suitable for upgrading. This reduces the possibility of introducing new problems due to unnecessary upgrades, while also ensuring the reliability of the data source used for upgrades and reducing the risk of security vulnerabilities or failures in the HSM due to the use of tampered data.

[0021] Furthermore, the multiple task modules are obtained by dividing all functions in the hardware security module based on function type and function relevance.

[0022] Based on the above technical means, HSM is used to divide the application into multiple relatively independent single modules according to the function type and the degree of correlation between functions. Each module is managed and flashed separately, thereby shortening the flashing operation time, reducing the impact of flashing operation anomalies caused by high module coupling, and thus improving the security of flashing operation.

[0023] Furthermore, the method further includes: after upgrading and flashing each of the task modules, encrypting the plaintext data of the task modules 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 restarts, 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, a second verification code of the main task module is generated using the preset secure boot key; the second verification code is compared 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 legitimate, the hardware security module is determined to start normally and jumps to the main task module, and under the condition that the main task module is working normally, the legitimacy of the remaining task modules is determined sequentially by the main task module according to the order of task processing; if the comparison result indicates that the main task module is illegitimate, the process jumps 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 the data of the historical version of the main task module.

[0024] Based on 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, ensuring that the HSM starts up normally and quickly. Then, the HSM main task module verifies other modules in turn. In this way, the startup speed is improved and the processing efficiency is increased.

[0025] Further, before receiving the upgrade / flash request sent by the host, the method includes: receiving the header data packet of the hardware security module sent by the host; wherein 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, and the header data packet further includes: a first signature of the application data packet and a second signature of the header data packet, wherein the first signature is obtained by the management server signing the encrypted 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; and the second signature is de-signed and verified 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 key pair generated based on the preset encryption system; upon successful verification of the second verification result, the application data packet sent by the host is received; wherein the application data packet is generated by the management server according to the attribute information and sent to the host; the first signature is de-signed and verified using the third public key to obtain a third verification result for the application data packet, wherein the third public key and the third private key are a key pair generated based on the preset encryption system; upon successful verification of the third verification result, the header data packet and the application data packet are stored in the first buffer, and the third verification result is sent to the host so that the host sends the upgrade flashing request based on the third verification result.

[0026] Based on the aforementioned technical methods, before receiving the upgrade / flash request from the host, a process of receiving, verifying, and storing header data packets and application data packets is first performed. This phased processing method can detect data problems early, avoiding potential risks such as system failures or security vulnerabilities caused by discovering data errors only during the upgrade / flash process. A third verification result is sent to the host, enabling the host to send the upgrade / flash request based on this result. This interaction mechanism ensures coordinated work between the host and the hardware security module, and the upgrade / flash process is only initiated after successful data verification, ensuring the continuity and security of the entire upgrade process.

[0027] Secondly, this application provides a flashing device for a hardware security module, the device comprising:

[0028] The receiving module is used to receive upgrade flashing requests sent by the host, and to obtain header data packets and application data packets from the upgrade file stored in the first cache of the hardware security module. The header data packet includes a magic number and basic information of multiple task modules, the basic information including a sub-data signature obtained by signing the sub-data content of the task modules 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 being encrypted based on a preset symmetric key and the header data packet.

[0029] The processing module 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.

[0030] The processing module is further configured to design and verify the plaintext data of the initial task module based on the sub-data signature of the initial task module using the first public key, and 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.

[0031] 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 successful verification and the initial task module meets the upgrade and rewrite conditions.

[0032] The processing module is further configured 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.

[0033] Thirdly, this application provides a hardware security module flashing device, the device comprising: a memory, a processor, and a transceiver.

[0034] The memory stores computer programs that can run on a processor;

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

[0036] When the processor executes the computer program, it implements some or all of the steps in the method for flashing the hardware security module as described in any of the first aspects.

[0037] Fourthly, this application provides a computer-readable storage medium storing one or more computer programs, which can be executed by one or more processors to implement some or all of the steps in the hardware security module flashing method as described in any of the first aspects.

[0038] Fifthly, this application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the flashing method for a hardware security module as described in any of the first aspects.

[0039] This application has the following beneficial effects:

[0040] (1) Using HSM, the APP is divided into relatively independent single modules according to the function type and the degree of function correlation. Each module is managed and flashed separately, which shortens the Flash operation time as much as possible and reduces the impact of Flash operation abnormalities.

[0041] (2) Using the integrity of the module package as a factor to derive the decryption key of the next module ensures the transmission security of the HSM upgrade package and increases the coupling between module packages;

[0042] (3) Since fast startup is an important communication indicator of ECU, if HSM bootloader adopts OTP mode, it can quickly verify the HSM main task module to ensure that HSM starts up normally and fast, and then the HSM main task module can verify other modules in turn. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0044] Figure 1 A schematic diagram of the structure of an optional hardware security module flashing system provided in an embodiment of this application;

[0045] Figure 2 A schematic diagram illustrating the implementation process of an optional hardware security module flashing method provided in this application embodiment;

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

[0047] Figure 4 A schematic diagram illustrating the implementation process of an optional hardware security module flashing method provided in this application embodiment;

[0048] Figure 5A schematic diagram illustrating the implementation process of an optional hardware security module flashing method provided in this application embodiment;

[0049] Figure 6 A schematic diagram illustrating the implementation process of an optional hardware security module flashing method provided in this application embodiment;

[0050] Figure 7 A schematic diagram illustrating the implementation process of an optional hardware security module flashing method provided in this application embodiment;

[0051] Figure 8 This is a schematic diagram illustrating an optional process for decrypting a task module, provided as an embodiment of this application.

[0052] Figure 9 A schematic diagram of the structure of an optional hardware security module flashing device provided in an embodiment of this application;

[0053] Figure 10 This is a schematic diagram of the structure of an optional hardware security module flashing device provided in an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

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

[0056] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0057] To facilitate understanding of this embodiment, a detailed description of a hardware security module flashing system disclosed in this application embodiment will be provided first.

[0058] Reference Figure 1As shown, this application embodiment provides a hardware security module flashing system, which may include: a management server 11, a host terminal 121 in an electronic control unit (ECU) 12, and a hardware security module (HSM) 122; wherein the host terminal 121 is communicatively connected to both the management server 11 and the hardware security module 122; the host terminal 121, the hardware security module 122, and the management server 11 can interact to realize the flashing process of the hardware security module. Alternatively, the system may also include: a management server 11, a vehicle-side master flashing device 13, a host terminal 121 in the ECU 12, and a hardware security module (HSM) 122, wherein the vehicle-side master flashing device 13 is communicatively connected to both the management server 11 and the host terminal 121, and the host terminal 121 is also communicatively connected to the hardware security module 122; the host terminal 121, the hardware security module 122, the vehicle-side master flashing device 13, and the management server 11 can interact to realize the flashing process of the hardware security module.

[0059] The aforementioned management server 11 can be an Over-the-Air (OTA) server. The management server can be a platform provided by the car manufacturer for downloading ECU software packages. The management server can be used to periodically release OTA upgrade information, which includes upgrade packages for the hardware security modules in the system.

[0060] The vehicle-side master flashing device 13 is a device located inside the vehicle. It is a key device used to communicate with the HSM module and complete the firmware update process when upgrading and flashing the firmware of the hardware security module in the electronic control unit. Of course, the vehicle-side master flashing device 13 is also used to provide network access. It should be noted that when the HSM module itself can provide network access and complete the firmware update process, the upgrade and flashing operation can be performed without the vehicle-side master flashing device.

[0061] The Electronic Control Unit (ECU) 12, also known as the vehicle's "on-board computer," is used to control the vehicle's driving status and perform its various functions. It primarily utilizes data acquisition and exchange from various sensors and buses to determine the vehicle's status and the driver's intentions, and then controls the vehicle via actuators. ECU data rewriting allows for individual or batch modification of the data or program code within the ECU, conveniently updating ECU data and enabling the ECU to meet the control requirements of different vehicles.

[0062] The host unit 121 is used to communicate with external devices of the ECU (such as sensors, actuators, and vehicle-side master brushing devices) and internal devices of the ECU (such as hardware security modules).

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

[0064] Here, the flashing process of the hardware security module implemented by the host 121, hardware security module 122, vehicle-side main flashing device 13, and management server 11 includes: the management server 11 periodically publishes OTA upgrade information; when the host 121 subscribes to the hardware security module 122's upgrade information through the vehicle-side main flashing device 13, it establishes a two-way HTTPS authentication with the management server 11 to establish a secure channel for obtaining the HSM upgrade file. The HSM upgrade file includes: obtaining the header data packet and the application data packet. Obtaining the header data packet and the application data packet includes: the host 121 receiving the header data packet sent by the management server 11 through the vehicle-side main flashing device 13 and passing the header data packet to the hardware security module 122; the hardware security module 122 performing a signature verification operation on the header data packet and sending the signature verification result back to the host 121; the signature verification result is also called the verification result. Furthermore, if the signature verification result indicates successful verification, the host terminal 121 receives the application data packet sent by the management server 11 through the vehicle-side main flashing 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 terminal 121. If the signature verification result indicates successful verification, the host terminal 121 sends an upgrade flashing request to the hardware security module 122, and the hardware security module 122 performs the upgrade flashing operation based on the header data packet and the application data packet.

[0065] Reference Figure 2 As shown, Figure 2 This application provides a flowchart illustrating a method for flashing a hardware security module, which is applied to... Figure 1 The hardware security module in the electronic control unit of the system shown communicates with the host unit in the electronic control unit. This method can be implemented through the following steps:

[0066] Step 201: Receive the upgrade flashing request sent by the host, and obtain the header data packet and application data packet from the upgrade file stored in the first cache of the hardware security module.

[0067] 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 flashing. The ciphertext data is encrypted based on the preset symmetric key and the header data packet.

[0068] In this embodiment of the application, the upgrade flashing request is used to upgrade the firmware in the hardware security module.

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

[0070] In this embodiment, the header data packet may include a magic number and basic information of multiple task modules. The magic number is used to identify the type or protocol format of the vehicle's hardware security module. The magic number can be a fixed numerical value or a sequence of bytes, and there may be one or more magic numbers; this application does not impose specific limitations on this. The basic information of each task module includes its sub-data signature. Here, the sub-data signature is obtained by signing the sub-data content of the task module based on a first private key, and different task modules have different sub-data signatures. In some embodiments, the basic information of a task module may also include the upgrade version number of the task module, the memory starting 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.

[0071] 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 encrypted data of multiple 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 the multiple task modules, and the first signature based on a third private key. Exemplarily, the header data packet is composed as follows: Figure 3 As shown, it should be noted that the number of bytes occupied by each piece of information in the header data packet may be the same or different.

[0072] In some embodiments, the application data packet includes encrypted data of each task module, which is used to upgrade and flash the firmware of that task module. This encrypted data is encrypted based on a preset symmetric key and a header data packet. Here, before transmitting data, the hardware security module and the management server request a preset symmetric key from the encryption system. This preset symmetric key is an agreement between the hardware security module and the management server, and it can be randomly generated using a symmetric algorithm. Therefore, each flashing operation produces different encrypted flashing data, making it impossible to deduce the flashing data using message logging tools. Even if the flashing data is stolen, it cannot be flashed into the ECU, effectively curbing illegal flashing and significantly improving the confidentiality of ECU flashing.

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

[0074] In practical applications, all functions within a hardware security module can be divided based on their functional types and interrelationships, resulting in multiple task modules with low coupling. These task modules include, but are not limited to, a general algorithm module, a digital key module, a secure communication module, a Transport Layer Security (TLS) module, and a secure boot module. It should be noted that the above is merely an example. Thus, by using HSM to divide the application into multiple relatively independent single modules based on functional type and interrelationships, each module undergoes separate version management and flashing, thereby shortening flashing operation time, reducing the impact of flashing operation anomalies caused by high module coupling, and ultimately improving the security of flashing operations.

[0075] In this embodiment, the hardware security module receives an upgrade flashing request sent by the host, retrieves an upgrade file containing a header data packet and an application data packet from the first cache, and uses the upgrade file to perform an upgrade flashing operation on the firmware of the task module in the hardware security module.

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

[0077] In this embodiment, the initial task module is the task module corresponding to the first piece of basic information stored in the basic information in the header data packet according to the module order.

[0078] In this embodiment, the hardware security module receives an upgrade flashing request sent by the host. After obtaining the header data packet and application data packet from the upgrade file stored in the first cache of the hardware security module, it obtains the 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, it decrypts the ciphertext data of the initial task module based on the preset symmetric key and the header data packet to obtain the plaintext data of the initial task module.

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

[0080] The first public key and the first private key are a pair of keys generated based on a pre-set encryption system.

[0081] In this embodiment, before transmitting data, the hardware security module and the management server apply for one or more preset key pairs (such as public and private keys) from the preset encryption system. The management server then digitally signs the plaintext data (sub-data content) of the task module to be transmitted based on the preset first private key. After decrypting the ciphertext data of the task module to obtain the plaintext data, the hardware security module uses the first public key corresponding to the first private key to perform designing verification to verify the integrity of the plaintext data of the task module and the sender's identity.

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

[0083] Step 204: 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.

[0084] In this embodiment of the application, the upgrade flashing conditions include 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.

[0085] In this embodiment of the application, if the first verification result indicates successful verification and the initial task module meets the upgrade and flashing conditions, the initial task module is upgraded and flashed based on its plaintext data, including:

[0086] If the first verification result indicates successful verification, the upgrade 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 upgrade version number is greater than the current version number, it is determined that the initial task module meets the upgrade flashing conditions; based on the plaintext data of the initial task module, the initial task module is upgraded and flashed. Thus, under 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 version number of the currently running hardware security module are compared. Only when the upgrade version number is greater than the current version number is it determined that the upgrade flashing conditions are met. This ensures that the upgrade operation is performed on the module that truly needs updating, avoiding unnecessary operations on modules that are already the latest version or unsuitable for upgrading. This reduces the possibility of introducing new problems due to unnecessary upgrades, while ensuring the reliability of the data source used for the upgrade, reducing the risk of security vulnerabilities or failures in the HSM due to the use of tampered data.

[0087] Step 205: 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 are obtained, and upgrade and rewrite the task modules that meet the upgrade and rewrite conditions.

[0088] In this embodiment, 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, a preset symmetric key, and a header data packet to obtain the plaintext data of the initial task module. Then, it determines the next task module corresponding to the next piece of basic information stored in the header data packet according to module order. Next, based on the plaintext data of the initial task module, it decrypts the ciphertext data of the next task module in the application data packet 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, it uses the first public key corresponding to the next task module to design and verify the plaintext data of the next task module, obtaining the first verification result of the next task module. Afterwards, if the first verification result of the next task module indicates successful verification and the next task module meets the upgrade / flash conditions, it performs an upgrade / flash based on the plaintext data of the next task module. This process is repeated to obtain the plaintext data of all task modules and complete the upgrade / flash operation for task modules that meet the upgrade / flash conditions.

[0089] It should be noted that step 205 can be executed simultaneously with steps 203 and 204, or step 205 can be executed before step 203, or step 205 can be executed after step 204. Of course, step 205 can also be executed after step 203 and before step 204. This application does not impose any specific restrictions on this.

[0090] This application provides a method for flashing a hardware security module. The method receives an upgrade flashing request from a host and retrieves a header data packet and an application data packet from an upgrade file stored in the first cache of the hardware security module. The header data packet includes a magic number and basic information about multiple task modules. The basic information includes a sub-data signature obtained by signing the sub-data content of the task modules 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. Based on the basic information of the initial task module, the preset symmetric key, and the header data packet, the initial task data in the application data packet is flashed. The encrypted 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 de-signed and verified using the first public key to obtain the first verification result. The first public key and the first private key are a key pair generated based on a pre-configured encryption system. If the first verification result indicates successful verification and the initial task module meets the upgrade and flashing conditions, the initial task module is upgraded and flashed based on its plaintext data. The encrypted data of the next task module is decrypted based on the plaintext data of the initial task module, until the plaintext data of all task modules is obtained, and the task modules that meet the upgrade and flashing conditions are upgraded and flashed. Thus, using the first private key to sign the sub-data content of the task module generates a sub-data signature, which ensures the reliability and integrity of the data source. Simultaneously, the encrypted data in the application data packet is encrypted based on a pre-configured symmetric key and header data packet, effectively preventing data from being stolen or tampered with during transmission and storage. The task modules are processed sequentially. First, the plaintext data of the initial task module is decrypted and verified. If the conditions are met, an upgrade and rewrite are performed. Then, the next task module is operated on based on this. This step-by-step approach ensures that all task modules are upgraded in an orderly manner, reducing the probability of confusion and errors that may be caused by processing multiple modules simultaneously. Furthermore, if a problem occurs during the upgrade of a certain module, it is easier to locate and resolve it without affecting the processing flow of other modules. An upgrade is only performed when the first verification result indicates successful verification and the initial task module meets the upgrade and rewrite conditions. This dual-judgment mechanism ensures that the upgrade operation is performed only when the data is legitimate and the module truly needs to be upgraded, avoiding potential problems caused by unnecessary upgrades and preventing illegal upgrades due to erroneous data or malicious attacks.

[0091] In some embodiments, before receiving the upgrade / flash request sent by the host in step 201, refer to Figure 4 As shown, the following steps can also be performed:

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

[0093] The header data packet is generated by the management server based on the attribute information of the hardware security module and sent to the host. 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 encrypted data of all task modules based on the second private key. 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.

[0094] In practical applications, the management server periodically publishes upgrade information for various services (including hardware security modules). When the host in the electronic control unit subscribes to the upgrade information for the hardware security module, a secure communication channel is established between the management server and the host to transmit data.

[0095] Here, when the management server obtains data from 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 upon with the hardware security module. This process can be implemented as follows:

[0096] First, before the management server transmits header data packets with the hardware security module, it requests one or more pre-set key pairs (such as public and private keys) from the pre-set encryption system; it obtains the magic number, the upgrade version number of each task module in multiple task modules, the memory starting address where the sub-data content of each task module is stored, and the memory data length occupied by the sub-data content.

[0097] 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; a pre-set first private key is used to digitally sign the hash value of the corresponding sub-data content of each task module to obtain the sub-data signature of each task module. Based on the upgrade version number, memory starting address, memory data length, and sub-data signature of each task module, the basic information of each task module is determined.

[0098] Then, the management server performs a hash operation on the encrypted data of all task modules to obtain the hash value of the encrypted data of all task modules. It then uses a preset second private key to digitally sign the hash value of the encrypted data of all task modules to obtain the first signature.

[0099] 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 used to determine the header data packet. It then uses a pre-set second private key to digitally sign this hash value, obtaining 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 for the hardware security module. Thus, the header data packet contains the first signature of the application data packet and its own second signature. These signatures are generated using different private keys, and are de-signed and verified at the receiving end using the corresponding public key. This multi-layered signature mechanism greatly enhances data security, ensuring data integrity and authenticity from the source (the management server). Even if the signature verification at one layer is breached, other layers of verification provide further protection.

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

[0101] The second public key and the second private key are a pair of keys generated based on a pre-set encryption system.

[0102] In this way, public and private key pairs generated based on a pre-built encryption system are used for signing and designing. This method ensures the standardization and security of the keys, and the encryption and decryption operations throughout the system are consistent and compatible, making secure communication between different stages more reliable.

[0103] Step 303: The second verification result indicates successful verification, and the application data packet sent by the host is received.

[0104] The application data package is generated by the management server based on attribute information and sent to the host.

[0105] In this embodiment, after receiving the header data packet, a hash operation can be performed on all data content in the header data packet except for the second signature to obtain a hash value used to verify the header data packet. Further, the second signature is de-signed using the second public key to obtain the hash value of the de-signed header data packet. The hash value used to verify the header data packet is compared with the hash value of the de-signed header data packet. If they match, it indicates that the signature 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. At this time, the host receives the application data packet sent by the management server according to the second verification result. The application data packet can be generated according to the attribute information (such as identification information) of the hardware security module.

[0106] Here, firstly, before the management server transmits application data packets between itself and the hardware security module, it requests a pre-set symmetric key from the pre-set encryption system, obtains the initial task modules arranged in module order from the header data packet, performs a hash operation 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 pre-set symmetric key and the hash value of the data content in the header data packet, an encryption key for the initial task module is obtained through a key derivation algorithm; the encryption key of the initial task module is used to encrypt the sub-data content 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 encrypted 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, an encryption key for the next task module is obtained through a key derivation algorithm; the encryption key of the next task module is used to encrypt the sub-data content of the next task module to obtain the ciphertext data of the next task module; this process is repeated to obtain 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 based on the attribute information of the hardware security module. By verifying the signatures of these data packets, it can be confirmed that the data originates from the legitimate management server. This prevents malicious attackers from forging upgrade data, ensures the reliability of the upgrade data source, and protects the hardware security module from threats of malware or unauthorized upgrades.

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

[0108] The third public key and the third private key are a pair of keys generated based on a pre-set encryption system.

[0109] Step 305: If the third verification result indicates successful verification, store the header data packet and application data packet in the first buffer and send the third verification result to the host so that the host can send an upgrade flashing request based on the third verification result.

[0110] In this embodiment, after receiving the application data packet, the hardware security module performs a hash operation on the encrypted data of all task modules in the application data packet to obtain a hash value used to verify the application data packet. Further, it uses a third public key to design and verify the first signature, obtaining the designed hash value of the application data packet. The hash value used to verify the application data packet is compared with the designed hash value. If they match, it indicates successful verification of the application data packet, resulting in a third verification result, which is then sent to the host. At this point, the host sends an upgrade / flash request to the hardware security module based on the third verification result to perform the upgrade / flash operation. Thus, before receiving the upgrade / flash request from the host, the header data packet and application data packet are received, verified, and stored. This phased processing method can detect data problems early, avoiding potential risks such as system failures or security vulnerabilities caused by discovering data errors only during the upgrade / flash process. The third verification result is sent to the host, causing the host to send the upgrade / flash request based on this result. This interaction mechanism ensures coordinated operation between the host and the hardware security module, and the upgrade flashing process is only initiated after successful data verification, ensuring the continuity and security of the entire upgrade process.

[0111] In some embodiments, after upgrading and flashing each task module, refer to Figure 5 As shown, the following steps can also be performed: steps 401 to 405, or steps 401 to 404 and step 406:

[0112] Step 401: After upgrading and flashing each task module, the plaintext data of the task module is encrypted using a preset secure boot key to obtain the first verification code, and the first verification code is stored in the second cache area.

[0113] In this embodiment, before performing an upgrade and rewrite operation on the task module, the hardware security module requests a preset secure boot key from the preset encryption system. This key is used to verify the task module after the upgrade and rewrite operation, as well as the various task modules involved during the first restart of the ECU after the upgrade and rewrite operation. The preset secure boot key is a symmetric key.

[0114] In this embodiment of the application, the first verification code can be a ciphertext-based CAPTCHA (Cipher Verification Code). basedMessage Authentication Code, CMAC).

[0115] In this embodiment of the application, after upgrading and flashing each task module, the plaintext data of the task module is encrypted using a preset security startup key to obtain a first verification code, and the first verification code is stored in the second cache area so that the relevant task modules can be verified when the electronic control unit restarts for the first time.

[0116] Step 402: When the electronic control unit restarts, 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;

[0117] Step 403: Generate the second verification code of the main task module using the preset secure boot key through the bootloader module;

[0118] Step 404: Compare the second check code with the first check code corresponding to the main task module stored in the second cache to obtain the comparison result.

[0119] Step 405: If the comparison result indicates that the main task module is valid, the hardware security module is confirmed to have started normally and the system jumps to the main task module. Under the condition that the main task module is working normally, the system determines the validity of the remaining task modules in turn according to the order of task processing.

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

[0121] The third storage area stores historical versions of the main task module.

[0122] In some embodiments, the hardware security module may include a bootloader module, a main task module, and other task modules.

[0123] The bootloader module is the first software component to run when the hardware security module starts. It 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 the encryption engine and communication interfaces). For example, the bootloader module initializes the memory, sets its operating mode and access permissions, and ensures a stable memory environment for the main task module and other modules during runtime.

[0124] The main task module is responsible for executing the primary security policies and encryption algorithms. For example, in 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 within the HSM.

[0125] Other task modules can provide auxiliary security functions. For example, a dedicated logging module can record important security events occurring within the HSM, such as key usage and the processing results of access requests.

[0126] In this embodiment, when the electronic control unit restarts, the boot loading module of the hardware security module adopts a one-time programmable (OTP) mode to determine the main task module of the hardware security module; the boot loading module generates a second verification code of the main task module using a preset security boot key; the first verification code of the main task module stored in the second cache is obtained, and the second verification code and the first verification code are compared to obtain a comparison result; if the comparison result indicates that the main task module is legitimate, the hardware security module is determined to have started normally and jumps to the main task module. Under the condition that the main task module is working normally, the legitimacy of the remaining task modules is determined sequentially according to the order of task processing, and it is checked whether other task modules have been tampered with; if the comparison result indicates that the main task module is illegitimate, the system jumps to the third storage area of ​​the main task module, performs code rollback of the main task module, and sends a message of abnormality of the main task module to the host.

[0127] Here, under normal working conditions, the main task module determines the legitimacy of the remaining task modules in the order of task processing. This includes: determining the order of each task module according to the order of task processing; calculating the second checksum of the currently processed task module using a preset secure startup key according to the order of task modules; comparing the first checksum of the currently processed task module with the first checksum of the same task module stored in the second cache; if they do not match, the host is notified that the task module is abnormal, and the process jumps to the third cache, i.e., the backup partition, to roll back the code of the task module.

[0128] As can be seen from the above, 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, ensuring that the HSM starts up normally and quickly. Then, the HSM main task module verifies other modules in turn. In this way, the startup speed and processing efficiency are improved.

[0129] Reference Figure 6 As shown, Figure 6 This application provides a flowchart illustrating a method for flashing a hardware security module, which is applied to... Figure 1 The hardware security module in the electronic control unit of the system shown communicates with the host unit in the electronic control unit. This method can be implemented through the following steps:

[0130] Step 501: Receive the upgrade flashing request sent by the host, and obtain the header data packet and application data packet from the upgrade file stored in the first cache of the hardware security module.

[0131] 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 flashing. The ciphertext data is encrypted based on the preset symmetric key and the header data packet.

[0132] The basic information also includes the starting address of the task module's memory and the length of the memory data.

[0133] Step 502: Based on the memory start address and memory data length of the initial task module, obtain the encrypted data of the initial task module from the application data packet;

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

[0135] Step 504: Based on the preset symmetric key and the first hash value, generate the decryption key for the initial task module through a key derivation algorithm;

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

[0137] In this embodiment, the hardware security module receives an upgrade / flash request sent by the host. After obtaining the header data packet and application data packet from the upgrade file stored in the first cache of the hardware security module, it obtains the memory start address and memory data length of the initial task module in the header data packet. Based on the memory start address and memory data length of the initial task module, it obtains the ciphertext data of the initial task module from the application data packet. Further, it performs a hash 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. Then, based on the preset symmetric key and the first hash value, it generates a decryption key for the initial task module through a key derivation algorithm. Finally, it uses 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. In this way, by retrieving ciphertext data from the application data packet based on the initial memory starting address and memory data length of the initial task module, the data of a specific task module can be accurately located, avoiding unnecessary data reading and processing and improving the efficiency of the upgrade process. The first hash value is obtained by hashing the magic number in the header data packet and the basic information of multiple task modules. Then, the decryption key of the initial task module is generated by the key derivation algorithm based on the preset symmetric key and the first hash value. This ensures that the generation of the decryption key is based on specific information related to the upgrade data, increasing the relevance and security of the key. Even if an attacker obtains the preset symmetric key, it will be difficult to generate a valid decryption key without the correct header data packet information, thus protecting the security of the ciphertext data.

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

[0139] The first public key and the first private key are a pair of keys generated based on a pre-set encryption system.

[0140] In some embodiments, step 506, based on the sub-data signature of the initial task module, uses the first public key to design and verify the plaintext data of the initial task module to obtain a first verification result. This can be achieved through 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; and comparing the second and third hash values ​​to obtain the first verification result. Thus, a second hash value is obtained by hashing the plaintext data of the initial task module, and a third hash value is obtained by decrypting the sub-data signature of the initial task module using the first public key. By comparing these two hash values, data integrity can be effectively verified. If the plaintext data is tampered with during transmission or storage, the calculated second hash value will differ from the third hash value, thereby enabling timely detection of data corruption.

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

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

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

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

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

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

[0147] 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 rewrite conditions, upgrade and rewrite the nth task module based on the plaintext data of the nth task module, thereby completing the upgrade and rewrite of the task modules that meet the upgrade and rewrite conditions.

[0148] In the embodiments of the present application, during the entire upgrade and rewrite process, for each task module, it is necessary to check the first verification result and judge the upgrade and rewrite conditions. This multiple verification mechanism includes signature verification of sub-data signatures using public keys and matching checks with upgrade and rewrite 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.

[0149] Furthermore, by checking whether each task module meets the upgrade and flashing conditions, it is ensured that only suitable task modules are upgraded. This avoids system failures caused by incompatible or incorrect upgrades. Task modules are processed sequentially, from the first to the Nth task module. This orderly upgrade method reduces interference between different task modules and lowers the probability of conflicts that may arise from simultaneously upgrading multiple task modules. Each task module is upgraded only after its preceding task module has successfully upgraded or met its corresponding conditions, which helps maintain system stability during the upgrade process.

[0150] In an example implementation scenario, refer to Figure 7 As shown, with Figure 1 This document describes a flashing system for a hardware security module, consisting of a management server (such as an OTA server), a host unit in an electronic control unit (ECU), and a hardware security module (HSM). The flashing method for the hardware security module is explained below.

[0151] Step S601: The OTA server periodically publishes OTA upgrade information;

[0152] In step S602, when the host in the ECU subscribes to OTA upgrade information, the host establishes a two-way HTTPS authentication with the OTA server to establish a secure channel in order to obtain the HSM upgrade package.

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

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

[0155] 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 module version number, module starting address, module data length, and module signature.

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

[0157] Here, shared memory channels can be used for inter-process communication (IPC) mechanisms implemented through shared memory, allowing processes to exchange data, synchronize operations, and control each other. It's important to note that shared memory, as a highly efficient IPC method, allows multiple processes to access the same memory region to achieve data sharing and interaction.

[0158] Step S605: HSM performs signature verification on the Header packet.

[0159] Here, HSM can perform signature verification on the Header packet using a pre-built public key-PK0 of an asymmetric algorithm to obtain the signature verification result of the Header packet.

[0160] Step S606: The HSM sends a successful signature verification result to the Host side via a Header packet.

[0161] Here, the Host determines whether to receive the APP packet sent by the OTA server based on the signature verification result of the Header packet. If the signature verification result indicates successful verification, the Header packet is considered valid, and the Host can then receive the APP packet sent by the OTA server.

[0162] Here, a full-function analysis of the hardware security module was conducted based on the function type and the degree of functional correlation. The APP package was 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 managed and flashed separately.

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

[0164] Step S608: The Host side transmits the APP packet to the HSM via the IPC channel;

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

[0166] Here, after obtaining the complete APP package, HSM performs a signature verification operation on the APP package using the pre-built public key PK0 of the asymmetric algorithm. If the signature verification is successful, the APP package is considered to be legitimate, and the Host side can then trigger the HSM side to perform a flashing operation.

[0167] Step S610: HSM sends the successful signature verification result of the APP packet to the Host side.

[0168] Here, the Host determines whether to trigger the HSM to perform a flashing operation based on the signature verification result of the APP package. If the signature verification result indicates successful verification, the APP package is considered legitimate, and the Host can subsequently send an upgrade flashing request to the HSW, thereby triggering the HSM to perform the flashing operation.

[0169] Step S611: The Host sends an upgrade flashing request to the HSM;

[0170] Step S612: HSM obtains the module version number in the Header packet. If the module version number is greater than the local module version number, the corresponding module is determined to be the target module for which the flashing operation needs to be performed.

[0171] Here, HSM retrieves the version information of each module sequentially in the Header package, compares the version numbers, and if the version number of the module in the upgrade package is greater than the local module version number, then that module is the target module for which a flashing operation needs to be performed.

[0172] Step S613: HSM obtains the encrypted data content of the target module in the APP package based on the address and length of the target module in the Header package, and decrypts the data content of the target module using the decryption key -K1 to obtain the decrypted content of the target module.

[0173] Here, HSM extracts magic, version information of each module, and / or basic information from the Header packet to form a set of serial data, and obtains a 32-byte hash value through a hash algorithm. HSM uses a pre-set symmetric algorithm key -K0 and this hash value to generate a symmetric algorithm decryption key -K1 for the initial module (i.e., the target module) in the APP packet using the KDF algorithm. Based on the address and length of the module in the Header packet, HSM retrieves the encrypted data content of the module in the APP packet, and uses the decryption key -K1 to decrypt the encrypted data content of the module, obtaining the decrypted content of the module and the target module.

[0174] Step S614: HSM performs a signature verification operation on the decrypted content of the target module using the pre-prepared asymmetric algorithm public key - PK0, and obtains the signature verification result.

[0175] Here, if the verification result indicates success, proceed to step 615; if the verification result indicates failure, proceed to step 616.

[0176] Here, the HSM side verifies the decrypted content of the target module using the pre-built asymmetric algorithm public key - PK0. If the verification fails, the reason for the failure is recorded, and an HSM failure message is returned to the Host. If the verification succeeds, the module is then written based on the decrypted data.

[0177] Step S615: Based on the decrypted content of the target module, HSM performs an upgrade and flashing operation on the target module.

[0178] Step S616: The HSM returns an HSM flashing failure message to the Host for this module.

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

[0180] Step S617: HSM will extract the decrypted content of the current module, process the decrypted content of the current module using a hash algorithm to obtain a 32-byte hash value; using the decryption key -K1 of the current module and the hash value, the KDF algorithm will be used to generate the symmetric algorithm decryption key -K2 for the next module, and so on for subsequent modules.

[0181] For example, the decryption process of multiple modules in the APP package can be referenced. Figure 8 As shown.

[0182] Here, step S617 is executed after step S615.

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

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

[0185] Here, after a single module completes its flashing operation, the HSM uses the pre-set secure boot key -KS to calculate the module's CMAC value and updates and saves it in the DataFlash. Subsequent modules are processed sequentially until all modules have been updated, at which point boot verification begins.

[0186] Step S619: After the ECU restarts, 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.

[0187] If there is a discrepancy, proceed to steps 620 to 621; if there is a discrepancy, proceed to step 622.

[0188] Here, after the ECU restarts, the HSM bootloader first verifies the CMAC of the main task module and generates a CMAC to be used for verification with the boot CMAC in the DataFlash. If they match, the HSM starts normally and jumps to the main task module of the HSM APP; otherwise, it jumps to the backup partition and performs code rollback of the main task module.

[0189] Step S620: The HSM sends information about the currently processed module exception to the Host;

[0190] Step S621: Jump to the backup partition to obtain the historical version data of the currently processed module.

[0191] Here, if the CMAC values ​​of a single module are inconsistent, the host is notified that the single module is abnormal, and the system is redirected to the backup partition to roll back the code of the single module.

[0192] Here, step S621 is executed after step S620.

[0193] Step S622: HSM starts normally and jumps to the main task module of the HSM APP. After the main task module of the APP is working normally, the main task module checks the legitimacy of other modules in turn according to the processing tasks, checks whether the APP has been tampered with, calculates the CMAC value of the module by using the preset security startup key -KS, and compares it with the CMAC value stored in DataFlash.

[0194] If there is a discrepancy, return to steps 620 and 621; if there is a discrepancy, continue to verify the validity of the next module according to the processing task order in step 622.

[0195] Here, after the main task module of the APP is working normally, the main task module will have a task to verify the legitimacy of other modules in turn, check whether the APP has been tampered with, calculate the CMAC value of the module by using the preset security startup key -KS, and compare it with the CMAC value stored in DataFlash. If the CMAC value of a single module is inconsistent, the Host will be notified that the single module is abnormal and jump to the backup partition to perform code rollback of the single module.

[0196] As described above, this application embodiment uses HSM to divide the APP into relatively independent single modules based on function type and functional correlation. Each module is managed and flashed separately, minimizing Flash operation time and reducing the impact of Flash operation anomalies. The integrity of the module package is used as a factor to derive the decryption key of the next module, ensuring the transmission security of the HSM upgrade package and increasing the coupling between module packages. Since fast startup is an important communication indicator for the ECU, if the HSM bootloader adopts OTP mode, it can quickly verify the HSM main task module to ensure normal and fast startup of HSM, and then the HSM main task module will sequentially verify other modules.

[0197] This application provides a hardware security module flashing device, referring to... Figure 9 As shown, Figure 9 This is a schematic diagram of a hardware security module flashing device provided in an embodiment of this application. The hardware security module flashing device 8 includes:

[0198] The receiving module 801 is used to receive the upgrade flashing request sent by the host, and to obtain the header data packet and application data packet from the upgrade file stored in the first buffer of the hardware security module. 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. The ciphertext data is encrypted based on a preset symmetric key and the header data packet.

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

[0200] The processing module 802 is also used to design and verify the plaintext data of the initial task module based on the sub-data signature of the initial task module, and obtain the first verification result by using the first public key. The first public key and the first private key are a pair of keys generated based on a preset encryption system.

[0201] The processing module 802 is also used to upgrade and rewrite the initial task module based on the plaintext data of the initial task module if the first verification result indicates successful verification and the initial task module meets the upgrade and rewrite conditions.

[0202] 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 flash the task modules that meet the upgrade and flashing conditions.

[0203] This application provides a hardware security module flashing device, the device comprising: a transceiver, a memory, and a processor.

[0204] The memory stores computer programs that can run on a processor;

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

[0206] When the processor executes the computer program, it implements some or all of the steps in the hardware security module flashing method described in the above embodiments.

[0207] This application provides a computer-readable storage medium storing one or more computer programs, which can be executed by one or more processors to implement some or all of the steps in the above-described method. The storage medium can be transient or non-transient.

[0208] This application provides a computer program including computer-readable code. When the computer-readable code runs in a hardware security module flashing device, the processor in the hardware security module flashing device executes some or all of the steps in the above method.

[0209] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0210] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. 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 descriptions of the method embodiments of this application for understanding.

[0211] This application provides a hardware entity diagram of a hardware security module flashing device, as shown in the embodiments below. Figure 10 As shown, the hardware entity of the hardware security module flashing device 9 includes: a processor 901, a memory 902, and a transceiver 903. The memory 902 stores a computer program that can run on the processor 901, and the transceiver 903 is used to perform the operation of receiving or sending data under the control of the processor. The processor 901 executes some or all of the steps in the above-described hardware security module flashing method.

[0212] The memory 902 stores computer programs that can run on the processor. The memory 902 is configured to store instructions and applications that can be executed by the processor 901. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the various modules of the flashing device 9 of the processor 901 and the hardware security module. It can be implemented by flash memory or random access memory (RAM).

[0213] Specifically, the processor 901 executes the program to implement the flashing method for the hardware security module described above. The processor 901 typically controls the overall operation of the hardware security module flashing device 9.

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

[0215] This application provides a storage medium storing one or more computer programs that can be executed by one or more processors to implement the steps of the hardware security module flashing method as described in any of the above embodiments.

[0216] It should be noted that the descriptions of the storage medium and device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0217] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0218] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0219] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; 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 embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0220] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

[0222] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple convolutional network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0223] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0224] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0225] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an in-vehicle terminal (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0226] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for flashing a hardware security module, characterized in that, The method is applied to a hardware security module in an electronic control unit, and the hardware security module is communicatively connected to a host side in the electronic control unit. The method includes: Receiving an upgrade and flashing request sent by the host side, and obtaining a header data packet and an application program data packet from an upgrade file stored in a first buffer area of the hardware security module. 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 packet includes ciphertext data for firmware upgrade and 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, decrypt the ciphertext data of the initial task module in the application program data packet to obtain the plaintext data of the initial task module. Based on the sub-data signature of the initial task module, use a first public key to perform signature verification on the plaintext data of the initial task module to obtain a first verification result. 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 and flashing conditions, upgrade and flash 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 upgrade and flash the task modules that meet the upgrade and flashing conditions.

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. Based on the basic information of the initial task module, the preset symmetric key, and the header data packet, decrypt the ciphertext data of the initial task module in the application program data packet to obtain the plaintext data of the initial task module, including: 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 program data packet. Perform a hash operation 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. Based on the preset symmetric key and the first hash value, generate a decryption key for the initial task module through a key derivation algorithm. 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.

3. The method according to claim 2, characterized in that, There are N task modules, where N is an integer greater than 1. Based on the plaintext data of the initial task module, decrypt the ciphertext data of the next task module, including: Perform a hash operation on the plaintext data of the nth task module to obtain a second hash value of the nth task module. Here, 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, generate a decryption key for the nth task module through the key derivation algorithm. The ciphertext data of the nth task module is decrypted using the decryption key 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, using the first public key to design and verify the plaintext data of the initial task module, yields a first verification result, including: A hash operation is performed on the plaintext data of the initial task module to obtain a second hash value; The first public key is used to decrypt the sub-data signature of the initial task module to obtain the 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 successful verification and the initial task module meets the upgrade and flashing conditions, the initial task module is upgraded and flashed based on its plaintext data, including: If the first verification result indicates successful verification, the upgrade version number of the initial task module in the basic information is obtained; Obtain the current version number of the initial task module currently running by the hardware security module; If the upgrade version number is greater than the current version number, it is determined that the initial task module meets the upgrade flashing conditions; 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 derived by dividing all functions in the hardware security module based on function type and function relevance.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: After upgrading and flashing each of the task modules, the plaintext data of the task modules is encrypted using a preset secure boot key to obtain a first verification code, and the first verification code is stored in the second cache area. When the electronic control unit restarts, 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; The bootloader module generates a second verification code for the main task module using the preset secure boot key. The second check code is compared with the first check code corresponding to the main task module stored in the second cache to obtain the comparison result; If the comparison result indicates that the main task module is legitimate, it is determined that the hardware security module has started normally and jumps to the main task module. Under the condition that the main task module is working normally, the legitimacy of the remaining task modules is determined sequentially by the main task module according to the order of processing tasks. If the comparison result indicates that the main task module is invalid, the system jumps to the third storage area of ​​the main task module to perform a code rollback of the main task module. The third storage area stores data of the 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 / flash request sent by the host, the method includes: The system receives the header data packet of the hardware security module sent by the host terminal; wherein 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 terminal, and the header data packet further includes: a first signature of the application data packet and a second signature of the header data packet, wherein the first signature is obtained by the management server signing the encrypted 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; The second signature is de-signed and verified using the second public key to obtain the 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; The second verification result indicates successful verification, and the application data packet sent by the host is received; wherein the application data packet is generated by the management server according to the attribute information and sent to the host. The first signature is de-signed and verified using the third public key to obtain the 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; Upon successful verification of the third verification result, 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, so that the host sends the upgrade flashing request based on the third verification result.

9. A device for flashing and writing a hardware security module, characterized in that, The device includes: The receiving module is used to receive upgrade flashing requests sent by the host, and to obtain header data packets and application data packets from the upgrade file stored in the first cache of the hardware security module. The header data packet includes a magic number and basic information of multiple task modules, the basic information including a sub-data signature obtained by signing the sub-data content of the task modules 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 being encrypted based on a preset symmetric key and the header data packet. The processing module 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. The processing module is further configured to design and verify the plaintext data of the initial task module based on the sub-data signature of the initial task module using the first public key, and 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 successful verification and the initial task module meets the upgrade and rewrite conditions. The processing module is further configured 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.

10. A device for flashing and rewriting a hardware security module, characterized in that, The device includes a memory, a processor, and a transceiver. The memory stores computer programs that can run on a processor; The transceiver is used to perform the operation of receiving or sending data under the control of the processor; When the processor executes the computer program, it implements the flashing method for the hardware security module as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more computer programs, which 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 instructions are executed by the processor, the flashing method of the hardware security module as described in any one of claims 1 to 8 is implemented.

Images