Key encryption registration method of lightweight hardware security module

Abstract

This invention discloses a key encryption registration method for a lightweight hardware security module, belonging to the field of information security technology. This invention achieves end-to-end encrypted key exchange through a hardware-isolated four-level Flash security partition, a three-level hierarchical key trust system, a key registration and update mechanism based on M1-M5 encrypted messages, and LC_CTRL full lifecycle permission control logic. Key updates can be completed using only the system SRAM, eliminating the need for a large-capacity dedicated cache built into the HSM, and also includes built-in key call integrity verification. This invention, while ensuring a high level of security, is compatible with lightweight chips with extremely low resource consumption and can be widely applied in low-power security scenarios such as the Internet of Things and automotive-grade control units.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a key encryption registration method for a lightweight hardware security module. Background Technology

[0002] With the rapid development of the Internet of Things, industrial control, and smart terminals, the application scenarios of lightweight computing nodes such as MCUs are becoming increasingly widespread. These nodes are typically deployed at the edge and lack robust physical security protection, facing complex cybersecurity risks such as data eavesdropping, unauthorized tampering, and identity forgery. Currently, mainstream lightweight HSM key management solutions in the industry are generally designed based on the AUTOSAR "Specification of Secure Hardware Extensions" standard. However, when adapting to lightweight, low-cost MCU nodes, two significant technical bottlenecks exist:

[0003] First, the cache resource requirements for key updates are too high. In existing solutions, keys are usually stored centrally in the same sector of non-volatile memory (such as Flash). When updating a single key, all keys in the entire sector need to be cached before the erase operation is performed. However, lightweight, low-cost chips are often limited by cost and hardware size and do not have enough dedicated cache space to store the key data of the entire sector, making it difficult for this solution to be implemented on low-configuration, lightweight nodes.

[0004] Secondly, key integrity is difficult to guarantee under low-cost Flash. During key updates and subsequent use, it is necessary to ensure the integrity of the key information stored in Flash for reading; otherwise, incorrect authentication and encryption / decryption results will be output. However, low-cost Flash typically does not have a robust hardware error correction mechanism, making the probability of information reading errors relatively higher. The reliability of key integrity is highly dependent on the chip manufacturer's process implementation quality, making it difficult to guarantee stable security performance across all scenarios.

[0005] Chinese Patent CN121770738A discloses a local key security storage method based on a virtualized cryptographic module, aiming to solve the problem of balancing security, cost, and flexibility in existing solutions. The method creates a highly isolated Virtualized Cryptographic Module (VCM) using CPU hardware virtualization technology, constructing a secure execution environment to achieve secure generation, encapsulation, storage, and decapsulation operations for master and working keys. The device includes a hardware layer, a virtualization layer, a VCM, and a communication interface, with each layer cooperating and having isolated permissions. The solution supports automatic loading at system startup or dynamic loading on demand, combined with TPM enhanced encapsulation and strong encryption mechanisms to resist various types of attacks. Verified in a 110kV smart substation scenario, it requires no additional dedicated hardware, costs only 0.1% of traditional HSM solutions, and its computational response latency meets real-time requirements, making it suitable for key security storage scenarios in various types of devices. However, this method relies on the logical isolation provided by CPU hardware virtualization and lacks a physical security boundary. If the CPU has hardware vulnerabilities or an attacker gains the highest CPU privileges, they can bypass the virtualization isolation layer to directly access and export all keys. Therefore, those skilled in the art urgently need to solve these technical problems. Summary of the Invention

[0006] To address the technical problems in the prior art, this invention completes key storage and computation entirely within an independent physical HSM module, with a hardware-level security boundary between it and the CPU. Plaintext keys will never be exported from the physical scope of the HSM. At the same time, it incorporates security mechanisms such as hardware lifecycle management and integrity verification, completely blocking unauthorized access and key leakage risks at the physical level, thus making up for the fundamental security deficiencies of pure software virtualization solutions.

[0007] To achieve the above technical objectives, this invention is implemented through the following technical solution: a key encryption registration method for a lightweight hardware security module, applied to a lightweight microcontroller unit (MCU) integrating a hardware security module (HSM), wherein the HSM and CPU share the on-chip Flash storage of the MCU, characterized in that, in the MCU on which the method is based, the Flash controller front end is provided with a command arbitrator that prioritizes responding to HSM requests, and the HSM has a built-in LC_CTRL lifecycle controller and a 24-bit monotonic counter, the method comprising the following steps:

[0008] After S1 and HSM complete CMD_INIT initialization and pass the secure boot verification, they enter the secure working state. They receive the CMD_LOAD_KEY command sent by the CPU and the corresponding M1, M2 and M3 messages. First, they verify the key update permission under the current life cycle through the LC_CTRL controller. If the permission verification fails, the request is directly rejected.

[0009] S2, HSM parses the M1 message to obtain the KEYID of the key to be registered and the device UID carried in the request, and verifies that the UID carried in the request is consistent with the device UID stored in the HSM's built-in storage. If they are inconsistent, the request is rejected.

[0010] S3 and HSM call the pre-stored MASTER_ECU_KEY to derive the encryption key K1 and the verification key K2. Use K2 to calculate the CMAC value of the concatenated data of M1 and M2 messages. Compare the calculated CMAC value with the received M3 message to verify consistency. If the verification fails, the request is rejected.

[0011] S4. After successful verification, HSM uses K1 to decrypt the M2 message, obtains the new Counter value, KEY_FLAG flag and plaintext key carried in it, and verifies that the current stored Counter value of the key to be updated is less than the new Counter value and that the write protection bit in the KEY_FLAG flag is not set. If any verification fails, the request is rejected.

[0012] S5. After the verification is successful, the HSM calculates the M5 verification value based on the current key information to be registered and returns it to the CPU. The CPU compares the received M5 verification value with the pre-generated M5 verification value. If they match, the CPU returns a verification success signal to the HSM. After receiving the signal, the HSM enters the key update state and initiates a high-priority write request to the Flash command arbitrator.

[0013] S6, the Flash command arbitrator suspends the Flash access operation on the CPU side, and the HSM writes the new M2 message and M3 message in pairs into the independent storage bit of the corresponding KEYID in the Flash. The writing process does not require reading or caching other key data in the Flash sector to which the storage bit belongs.

[0014] S7. After writing is complete, HSM verifies the consistency of the M2 and M3 data read back from Flash. If the verification passes, it updates the Counter value of the corresponding key, returns a key registration success response to the CPU, restores the CPU's Flash access permissions, and returns to a secure working state.

[0015] Furthermore, the permission verification rules for the LC_CTRL controller in step S1 are as follows: when the LC_CTRL value is 0x00, write operations for all types of keys are allowed; when it is 0x05, write operations for BOOT_KEY, MASTER_ECU_KEY, and user keys are allowed; when it is 0x0F, write operations for MASTER_ECU_KEY and user keys are allowed; when it is 0x50, only user key update operations are allowed; and when it is 0x55, all key write operations are prohibited.

[0016] Furthermore, in step S3, the derivation method of encryption key K1 and verification key K2 is as follows: using the AES-MP key derivation algorithm, with MASTER_ECU_KEY as the root key, and using the fixed parameters KEY_UPDATE_ENC_C and KEY_UPDATE_MAC_C preset inside the HSM as derivation factors, respectively, a 128-bit encryption key K1 and a 128-bit verification key K2 are generated.

[0017] Furthermore, in step S4, if the current storage Counter value of the key to be updated reaches the maximum value of 24 bits and overflows, the storage slot corresponding to the key becomes permanently invalid, and the HSM rejects all subsequent update requests for that slot; if the WRITE_PROTECTION flag in the KEY_FLAG flag of the key to be updated is 1, the update request for that key is rejected.

[0018] Furthermore, in step S6, the Flash command arbitrator is configured with a two-level access priority scheduling rule: the priority of the Flash operation request of the HSM is always higher than that of the Flash operation request of the CPU; if the CPU is performing a Flash operation when the HSM initiates a write request, the arbitrator waits for the CPU to complete its current single-step atomic operation and then immediately executes the HSM's write request, blocking all CPU-side Flash access requests during this period. After the HSM write is completed, the CPU access blocking is automatically released.

[0019] Furthermore, the storage size of each user key in the Flash is 64 bytes, storing only the M2 message and the M3 message. The M2 message is ciphertext data containing Counter, KEY_FLAG, and plaintext key, encrypted using encryption key K1. The M3 message is the CMAC checksum of the concatenated data of the M1 message and the M2 message.

[0020] Furthermore, the method also includes a key usage verification step: when the HSM receives a key operation request carrying a KEYID, it first reads the corresponding M2 and M3 messages from the Flash according to the KEYID, generates a standard M1 message based on the current device UID and KEYID, calculates the CMAC value of the concatenated data of the standard M1 message and the read M2 message using the currently valid K2, and compares it with the read M3 message. If they match, the plaintext key is decrypted to obtain the M2 message for subsequent operations. If they do not match, the key data is determined to be corrupted and an error response is returned.

[0021] Furthermore, in step S6, the erasure of the Flash sector and the write-back of non-key data during key update are assisted by the CPU. The sector data containing the encryption key is temporarily stored in the system RAM on the CPU side, without occupying the dedicated cache resources of the HSM, and the CPU cannot access the plaintext key throughout the process.

[0022] Furthermore, after decrypting to obtain the plaintext key, the HSM reads the KEY_FLAG flag corresponding to the key and verifies that the current operation type matches the purpose limited by the KEY_USAGE flag and that the current secure boot state matches the requirements of the BOOT_PROTECTION flag. Only after both verifications pass can the key be used to perform the corresponding operation.

[0023] Furthermore, if the Flash readback data verification fails in step S7, the HSM will perform a maximum of 3 retry write operations. If the retry still fails, a key write failure alarm will be triggered, and the Counter value of the corresponding key will be rolled back to the value before the current update request was initiated. At the same time, the incomplete M2 and M3 data that have been written will be erased to avoid invalid key residue.

[0024] The beneficial effects of this invention are as follows:

[0025] 1. This invention uses a scheduling design that prioritizes the response of HSM write requests by the Flash command arbitrator and allows for independent writing of single keys without caching the entire sector of data. Combined with a collaborative mechanism that assists the CPU in completing sector erase and write-back and temporarily stores the encryption key in the system RAM, this invention significantly reduces the HSM's dependence on dedicated cache resources and is suitable for resource-constrained application scenarios of various lightweight MCUs.

[0026] 2. This invention employs a multi-layered security verification mechanism, including LC_CTRL lifecycle permission verification, UID identity verification, M2+M3 integrity verification, and monotonic counter anti-replay measures, to ensure the security of key registration and update processes across the entire chain from hardware architecture to protocol flow, effectively resisting various security risks such as unauthorized access, identity forgery, data tampering, and replay attacks.

[0027] 3. This invention uses a lightweight storage structure that stores only the ciphertext M2 and the checksum M3 in Flash, combined with real-time CMAC integrity verification during key invocation and a KEY_FLAG flag usage and secure boot status matching verification mechanism. This simplifies the key storage structure and reduces unnecessary Flash storage resource usage while ensuring the integrity of key data and compliance with usage regulations.

[0028] 4. This invention effectively avoids data corruption and state inconsistency problems during key update by using fault-tolerance mechanisms such as automatic retry for key writing failure, automatic rollback of counter values, and automatic erasure of invalid key data, combined with priority scheduling and atomicity guarantee rules for Flash operations, thus significantly improving the reliability and operational stability of lightweight HSM key management. Attached Figure Description

[0029] Figure 1This is a schematic diagram of the hardware device for interaction between the HSM and the Flash memory according to the present invention.

[0030] Figure 2 This is a schematic diagram of the Flash security area of ​​the present invention;

[0031] Figure 3 This is a schematic diagram of the SECRET_KEY format of the present invention;

[0032] Figure 4 This is a schematic diagram of the encryption keys M1-M5 of this invention;

[0033] Figure 5 This is a schematic diagram of the state and transition methods of the internal state machine of the HSM of the present invention;

[0034] Figure 6 This is a flowchart of the encrypted key registration process of the present invention;

[0035] Figure 7 This is a flowchart of the key usage method of the present invention. Detailed Implementation

[0036] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] Reference Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 and Figure 7 As can be seen, the present invention provides a key encryption registration method for a lightweight hardware security module, applied to a lightweight microcontroller unit (MCU) integrating a hardware security module (HSM). The HSM shares the on-chip Flash memory of the MCU with the CPU. In the MCU on which the method is based, the Flash controller has a command arbitrator that prioritizes responding to HSM requests. The HSM has a built-in LC_CTRL lifecycle controller and a 24-bit monotonic counter. The method includes the following steps:

[0038] After S1 and HSM complete CMD_INIT initialization and pass the secure boot verification, they enter the secure working state. They receive the CMD_LOAD_KEY command sent by the CPU and the corresponding M1, M2 and M3 messages. First, they verify the key update permission under the current life cycle through the LC_CTRL controller. If the permission verification fails, the request is directly rejected.

[0039] S2, HSM parses the M1 message to obtain the KEYID of the key to be registered and the device UID carried in the request, and verifies that the UID carried in the request is consistent with the device UID stored in the HSM's built-in storage. If they are inconsistent, the request is rejected.

[0040] S3 and HSM call the pre-stored MASTER_ECU_KEY to derive the encryption key K1 and the verification key K2. Use K2 to calculate the CMAC value of the concatenated data of M1 and M2 messages. Compare the calculated CMAC value with the received M3 message to verify consistency. If the verification fails, the request is rejected.

[0041] S4. After successful verification, HSM uses K1 to decrypt the M2 message, obtains the new Counter value, KEY_FLAG flag and plaintext key carried in it, and verifies that the current stored Counter value of the key to be updated is less than the new Counter value and that the write protection bit in the KEY_FLAG flag is not set. If any verification fails, the request is rejected.

[0042] S5. After the verification is successful, the HSM calculates the M5 verification value based on the current key information to be registered and returns it to the CPU. The CPU compares the received M5 verification value with the pre-generated M5 verification value. If they match, the CPU returns a verification success signal to the HSM. After receiving the signal, the HSM enters the key update state and initiates a high-priority write request to the Flash command arbitrator.

[0043] S6, the Flash command arbitrator suspends the Flash access operation on the CPU side, and the HSM writes the new M2 message and M3 message in pairs into the independent storage bit of the corresponding KEYID in the Flash. The writing process does not require reading or caching other key data in the Flash sector to which the storage bit belongs.

[0044] S7. After writing is complete, HSM verifies the consistency of the M2 and M3 data read back from Flash. If the verification passes, it updates the Counter value of the corresponding key, returns a key registration success response to the CPU, restores the CPU's Flash access permissions, and returns to a secure working state.

[0045] In one embodiment, refer to Figure 1 and Figure 2As can be seen, the key encryption registration method of the lightweight hardware security module described in this embodiment is applied to the built-in lightweight MCU of the automotive-grade body control unit (BCM). This MCU adopts a Cortex-M0+ core, with built-in 128KB on-chip Flash, 8KBSRAM and an independent physical HSM module. The Flash controller front end integrates a command arbitrator, supports HSM access request priority scheduling, and the Flash physical layer is divided into 4 hardware-isolated security areas according to security level. The core control commands of this embodiment are shown in Table 1:

[0046] Table 1

[0047]

[0048] Power-on initialization and safe startup phase:

[0049] After the MCU is powered on and reset, it automatically executes the first-level bootloader stored in Flash secure area 1:

[0050] First, write the command value 0x01 (CMD_INIT command) to the HSM's CMD_REG command register to complete the hardware initialization of the HSM's DATA_REG data register and CryptoCore encryption / decryption core;

[0051] After initialization, the command value 0x02 (CMD_SECURE_BOOT command) is written to CMD_REG to perform secure boot verification. HSM calls CryptoCore to calculate the SM3 hash value of the first-level bootloader firmware. After comparing it with the baseline check value derived from BOOT_KEY stored in security zone 3, the command value 0x05 (CMD_BOOT_OK command) is written to CMD_REG, and HSM officially enters the secure working state.

[0052] At this time, the HSM reads the LFCY lifecycle value stored in security zone 2 as 0x50 (mass production state), and the LC_CTRL controller outputs the corresponding permission control signal, allowing only user key update operations and prohibiting modification of core trust anchors such as root key and BOOT_KEY.

[0053] Key registration request reception and authorization verification phase:

[0054] When the body control unit application layer needs to update the user key KEY3 (KEYID is 0x03) used for CAN bus message encryption:

[0055] The CPU writes command value 0x06 (CMD_LOAD_KEY command) to the HSM's CMD_REG via the bus interface, and at the same time sends M1, M2 and M3 messages sequentially via DATA_REG. The M1 message contains the KEYID=0x03 of the key to be updated and the 120-bit unique UID pre-stored in MCU security area 2.

[0056] After receiving the CMD_LOAD_KEY command, the HSM first verifies the key operation permissions under the current 0x50 lifecycle through the LC_CTRL controller. If the permission verification is successful, the subsequent message parsing process will begin.

[0057] If the key to be updated in this request is the MASTER_ECU_KEY (KEYID=0x01) stored in security zone 3, then because root key operations are not allowed in mass production mode, HSM will directly return a 0xF0 permission denial error code via DATA_REG, terminating the key registration process.

[0058] In this embodiment, the Flash command arbitrator is configured with two priority levels by default: the Flash access request of HSM always has a higher priority than the access request of CPU. If the CPU is performing a Flash user data write operation when HSM initiates a key write request, the arbitrator will wait for the CPU to complete the current single-step atomic write, block all Flash access requests on the CPU side, and respond to the key write operation of HSM first. After the write is completed, the CPU access block will be automatically released.

[0059] The KEY3 to be written is stored in the address range 0x00018000-0x0001803F of the Flash security area 4. This area is logically isolated by the Flash controller and can only be directly accessed by the HSM. The CPU / DMA has no direct read / write permissions, thus ensuring the security of key storage at the hardware level.

[0060] In one embodiment, refer to Figure 3 , Figure 4 and Figure 5 As can be seen, this embodiment is applied to the built-in lightweight MCU of a low-power BLE smart door lock. The MCU adopts a Cortex-M0+ core, with built-in 128KB on-chip Flash, 8KBSRAM and independent physical HSM module. The Flash controller front end integrates a command arbitrator. The Flash physical layer is divided into 4 hardware-isolated security areas according to the security level, which fully matches the hardware architecture and security mechanism described in the technical solution.

[0061] Key programming and LC_CTRL status transition during chip manufacturing:

[0062] During the chip manufacturing process, the initial value of LC_CTRL is 0x00 (the chip's original factory state). At this time, the CPU has read and write permissions to all Flash secure areas.

[0063] First, write a 120-bit globally unique UID and LFCY lifecycle value to Flash secure area 2. Once written, these two parameters are permanently unmodifiable.

[0064] Write three ROM keys, SECRET_KEY (KEYID=0H), BOOT_KEY (KEYID=2H), and MASTER_ECU_KEY (KEYID=1H), to Flash secure area 3. Each key is stored in the format of 1 byte of flag bit and 16 bytes of plaintext key. Writing 0x00 to the flag bit indicates that the key is valid.

[0065] After each type of root key is burned, the LC_CTRL value is updated to 0x05 and 0x0F respectively. Finally, after all root keys are burned, the LC_CTRL value is set to 0x50 (mass production state). At this time, the Flash controller automatically disables the CPU's read and write permissions to all root key areas, and only retains the HSM's temporary write permission to the user key area in the key update process, which meets the requirements of the Flash controller isolation rules in the technical solution.

[0066] HSM initialization and extended key derivation:

[0067] After the door lock is powered on, the first-level bootloader stored in Flash secure area 1 is executed, sending the 0x01 command (CMD_INIT) to the HSM's CMD_REG command register, and the HSM enters the INIT_state state.

[0068] HSM automatically reads the root key, UID, and LFCY parameters stored in the Flash security area, and derives extended keys K1 and K2 based on MASTER_ECU_KEY:

[0069] K1 uses the AES-MP key derivation algorithm, and the derivation factor is a fixed value defined by the technical solution:

[0070] KEY_UPDATE_ENC_C=128'h0101534845008000000000000000000B0, generating a 128-bit encryption key;

[0071] K2 uses the same AES-MP algorithm, with a fixed derivation factor:

[0072] KEY_UPDATE_MAC_C=128'h010253484500800000000000000000B0 generates a 128-bit verification key. The derivation process fully conforms to the Miyaguchi-Preneel compression algorithm rules defined in the technical solution. The detailed steps of the Miyaguchi-Preneel compression algorithm are as follows:

[0073] Before being fed to the compression algorithm, messages must be preprocessed, meaning they must be padded and parsed into 128-bit blocks. Padding is done by appending a "1" to a message M of length l, followed by k "0" bits, where k is the length of the first digit. The smallest nonnegative solution.

[0074] Finally, an unsigned binary representation of the number l is appended, with a bit width of 40, i.e., 40'b1. Before the padded message is provided to the compression function, it must be parsed into n 128-bit blocks x1, x2, ..., xn.

[0075] The AES-MP expression can be written as follows, with encryption using the AES-128 algorithm and the key being... :

[0076]

[0077] .

[0078] After initialization, HSM performs CMD_SECURE_BOOT security boot verification. After verifying that the CMAC value of the application boot code is consistent with the pre-stored baseline value, it enters the Secure_Working_state state and waits for upper-layer business requests.

[0079] The KEY3 used for BLE communication encryption (corresponding to KEYID=5H) needs to be updated. The device has a built-in 120-bit unique UID of 0x123456789ABCDEF012345678. The current Counter value stored in KEY3 is 0x000001. The extended keys K1 and K2 have been derived based on MASTER_ECU_KEY according to the technical solution rules. The entire key registration process strictly follows the M1~M5 message format specifications.

[0080] Key registration request message (M1 / M2 / M3) generation:

[0081] When the platform issues a key update command, it first generates a request segment message:

[0082] M1 message (128-bit plaintext): Concatenate according to the format M1=UID||ID||4'h0. The 120-bit UID0x123456789ABCDEF012345678 and the 4-bit KEYID0b0101+4-bit padding value 0b0000 are concatenated to obtain the complete 128-bit M1 plaintext, which is used for device identity verification.

[0083] M2 message (384-bit ciphertext): Plaintext segments are concatenated according to the following rules: 24-bit Counter value 0x000002 (greater than the currently stored 0x000001, meeting the anti-replay requirement), 96-bit zero padding, 8-bit KEY_FLAG value 0x49 (WP bit is 0 to allow rewriting, BP bit is 1 to be restricted by secure boot, KU bit is 01 only for encryption and decryption, AU bit is 001 corresponding to a 128-bit key length), 128-bit plaintext BLE key (low-order bits padded with 0 to 256 bits); AES-CBC encryption is performed using the derived K1 as the encryption key and IV=0 to obtain 384-bit M2 ciphertext.

[0084] M3 message (128-bit checksum): The 128-bit M1 is concatenated with the 384-bit M2, and the CMAC value of the concatenated data is calculated using the derived K2 as the key to obtain the 128-bit M3 message, which is used for integrity verification.

[0085] Device-side verification and response message (M4 / M5) generation:

[0086] After receiving messages M1, M2, and M3, the HSM performs verification sequentially. Upon successful verification, a response message is generated.

[0087] First, verify that the UID carried by M1 is consistent with the device's built-in UID. Then, verify that the Counter value 0x000002 after decryption of M2 is greater than the currently stored 0x000001. Next, use K2 to recalculate the CMAC value of the concatenated data of M1 and M2, which is completely consistent with the received M3. The verification is successful.

[0088] M4 message (128-bit checksum message):

[0089] It is generated according to the format UID||ID||4'h0||ENC_CBC(K1,IV=0,{Counter24||96'h0||KEY_FLAG}), where the encrypted segment only contains Counter, padding value and KEY_FLAG, and does not carry plaintext key information.

[0090] M5 message (128-bit checksum): The CMAC value of the M4 message is calculated using K2 as the key, and the 128-bit M5 message is returned to the main CPU. After the main CPU verifies that the M5 message is consistent with the local calculation result, it sends an acknowledgment signal to the HSM and enters the key writing process.

[0091] Key storage and exception handling:

[0092] During key writing, only the M2 and M3 messages are written in pairs to the 64-byte storage space corresponding to KEY3 in Flash security area 4. There is no need to store the M1, M4, and M5 messages, thus reducing Flash storage resource consumption. If the Counter value carried in this key update is 0xFFFFFF (maximum 24 bits), the Counter for that key slot will overflow after the update, permanently invalidating it. All subsequent update requests will be rejected, fully complying with the anti-replay mechanism defined in the technical solution.

[0093] KEYID serves as a mapping for key access and is used in HSM operations to indicate which key to select. The keys represented by KEYID in HSM are shown in Table 2 below:

[0094] Table 2

[0095]

[0096] Key writing and exception handling:

[0097] Upon entering Key_Update_state, the HSM initiates a high-priority write request to the Flash command arbitrator. The arbitrator suspends Flash access operations on the CPU side and writes the M2 and M3 messages in pairs into the 64-byte independent storage location corresponding to KEY3 in Flash security area 4. The write process does not require caching other key data in the same sector.

[0098] After the write operation is completed, the HSM reads back the Flash data to verify consistency. If the verification is successful, the Counter value corresponding to KEY3 is updated to 0x000002, a registration success response is returned to the CPU, the CPU's Flash access permissions are restored, and the state is rolled back to Secure_Working_state.

[0099] If the Counter value carried in this request is 0x000001 (less than the current stored value), the HSM will directly determine it as a replay attack and reject the request; if the Counter value reaches the maximum 24-bit value of 0xFFFFFF, the key slot will be permanently invalidated, and all subsequent update requests will be rejected, which fully complies with the anti-replay rules defined in the technical solution.

[0100] Two types of user keys need to be registered: KEY2 (KEYID=4H) for CAN FD bus data encryption and KEY4 (KEYID=6H) for bus message authentication. The key registration process is completed through the CMD_LOAD_KEY command. The KEY_FLAG attribute of the key is configured during registration and stored in the corresponding NVM key slot, which fully matches the flag bit definition rules of the technical solution.

[0101] KEY_FLAG configuration during the key registration phase:

[0102] The two types of keys are configured with corresponding KEY_FLAG values ​​according to business security requirements, and each flag bit strictly follows the functional definition of the technical solution:

[0103] For KEY2 (CAN bus encryption key): Configure KEY_FLAG value to 0x09, with the following bit-by-bit correspondence rules:

[0104] The 7th bit WRITE_PROTECTION(WP) = 0: disables the key's rewriting and erasure functions. It cannot be updated after registration to prevent the key from being maliciously tampered with.

[0105] The 6th bit BOOT_PROTECTION(BP) = 0: The key is not restricted by the secure boot result. Even if the secure boot is downgraded to an insecure state, the key can still be used to encrypt basic diagnostic messages.

[0106] The 5th bit is reserved and is always set to 0;

[0107] The 4th to 3rd bits KEY_USAGE(KU) = 01: This specifies that the key can only be used for encryption and decryption operations and cannot be used for MAC operations, thus achieving the minimum permission isolation for key usage;

[0108] Bit 2-0 KEY_SIZE(AU) = 001: Specifies a key length of 128-bit, matching the AES-128 encryption algorithm requirement.

[0109] For KEY4 (bus message authentication key): Configure KEY_FLAG value to 0xC4, with the following bit-by-bit correspondence rules:

[0110] 7th WP bit = 1: Enables the key rewriting and erasure function, supporting subsequent periodic key rotation;

[0111] The 6th BP bit = 1: Key usage is restricted by the secure boot result. This key can only be used for MAC calculation when the secure boot verification passes and the secure working state is entered, to prevent unverified malicious firmware from stealing the authentication key.

[0112] The 5th bit is reserved and is always set to 0;

[0113] The 4th-3rd KU bit = 10: This specifies that the key can only be used for MAC operations and cannot be used for encryption and decryption operations, to prevent the key from being used for unauthorized purposes;

[0114] Bit 2-0 AU = 100: Specifies the key length as 256 bits, meeting the high-security CMAC authentication requirements.

[0115] Furthermore, the RAM_KEY temporarily generated internally by the HSM is only stored in an internal register and is automatically cleared after the operation is completed. It does not have the KEY_FLAG attribute and has no persistent configuration. The KEY_FLAG description is shown in Table 3:

[0116] Table 3

[0117] Flag verification process during the key retrieval phase:

[0118] When the HSM receives a key operation request from the upper-layer service, it first reads the KEY_FLAG stored in the corresponding key slot for permission verification:

[0119] If an upper-layer service requests to use KEY2 to calculate the CMAC value of a CAN message, the HSM reads that the KU bit of KEY_FLAG is 01 (encryption and decryption only), determines that the purpose of the operation does not match the key's limited range, and directly returns an error response, rejecting the operation request;

[0120] If the security startup verification fails and the system enters an insecure working state, the upper layer requests to call KEY4 for message authentication. The HSM reads that the BP bit of KEY_FLAG is 1, and the current security status does not meet the requirements, so the key call is directly rejected.

[0121] If the KU bit of the KEY_FLAG stored in the key slot is 11 or the AU bit is 000, which are not defined valid values, the HSM will directly determine that the key is invalid and reject all call requests.

[0122] Flag verification in key update scenarios:

[0123] When the business layer initiates an update request for KEY2, the HSM reads that the WP bit of the corresponding KEY_FLAG is 0, determines that the key has disabled the rewrite and erase function, and directly rejects the update request; when an update request for KEY4 is initiated, the WP bit is 1 to allow the update. After verifying that the new Counter value is greater than the current stored value, the key rotation can be completed. During the update, the KEY_FLAG configuration can be modified synchronously, and the new flag bit is written to the key slot for persistent storage along with the ciphertext key.

[0124] In one embodiment, this embodiment applies to a lightweight MCU built into an automotive-grade telematics processor (T-BOX). This MCU integrates an independent physical HSM module, fully matching the state machine transition rules and Flash access isolation mechanism described in the technical solution. The state transition and operation flow throughout the entire lifecycle are as follows:

[0125] Status transitions and LC_CTRL configuration during the chip manufacturer's programming phase:

[0126] When the chip leaves the factory, the HSM is in the Start_state by default, waiting for the initialization command:

[0127] The chip manufacturer's test engineer sends the CMD_INIT command (command value 0x01) to the HSM via the debug interface. The HSM enters the INIT_state initialization state, at which point the initial value of LC_CTRL is 0x00 (the chip manufacturer's initial state). The CPU has read and write permissions to all Flash secure areas and sequentially completes the programming of SECRET_KEY, BOOT_KEY, and MASTER_ECU_KEY. After each type of root key is programmed, the LC_CTRL value is updated according to the following rules:

[0128] After the SECRET_KEY is successfully burned, LC_CTRL is updated to 0x05. At this time, the Flash controller automatically disables the CPU's read and write permissions to the SECRET_KEY area, while retaining write permissions for BOOT_KEY, MASTER_ECU_KEY, and user keys.

[0129] After the BOOT_KEY is successfully burned, LC_CTRL is updated to 0x0F. The Flash controller disables the CPU's read and write permissions to the BOOT_KEY area, and only retains write permissions to MASTER_ECU_KEY and the user key.

[0130] After the MASTER_ECU_KEY and default user keys KEY1~KEY3 are successfully burned, LC_CTRL is updated to 0x50 (mass production state). The Flash controller disables the CPU's read and write permissions to all root key and user key areas. Only the HSM can temporarily obtain user key write permissions through a legitimate key update process, which fully matches the isolation rules of the Flash controller in the technical solution.

[0131] In the INIT_state (initialization state), the HSM enters this state after the main CPU sends the CMD_INIT command to the HSM. This command is used to initialize the internal state of the HSM. In this state, the HSM directly reads the key information, UID, and LFCY, then calculates the extended keys K1 and K2 for later use, and outputs LC_CTRL according to the key registration status. The isolation behavior of LC_CTRL and FlashController on the CPU is shown in Table 4.

[0132] Safety startup status transition during equipment mass production phase:

[0133] Upon first power-on after T-BOX assembly, the first-stage bootloader sends the CMD_SECURE_BOOT command (command value 0x02) to the HSM, and the HSM transitions from INIT_state to Secure_Boot_state.

[0134] If the verification is successful: HSM calls the built-in BOOT_KEY to calculate the CMAC value of the application boot code. If it matches the baseline verification value pre-stored in the Flash secure area, the boot code is determined to be complete and trustworthy. HSM then jumps to the Secure_Working_state, at which point all encryption, decryption, MAC generation, and key update functions are fully enabled and available.

[0135] If verification fails: The boot code has been maliciously modified, causing CMAC verification to fail. The HSM sets a secure boot error flag and jumps to the NonSecure_Working_state, which is an insecure working state. Only basic encryption and decryption operations are allowed using externally passed keys. Access to all internally stored ROM keys and NVM keys is prohibited to prevent the leakage of sensitive information.

[0136] State transitions during the key update phase:

[0137] During operation, T-BOX needs to periodically update KEY3 (KEYID=5H) used for cloud communication encryption.

[0138] When the HSM in Secure_Working_state receives the CMD_LOAD_KEY command (command value 0x06) sent by the CPU, it completes the lifecycle permission verification, UID verification, CMAC integrity verification, and monotonic counter anti-replay verification in sequence. After all these verifications are passed, it jumps to the Key_Update_state key update state. At this time, the Flash controller temporarily grants write permission to the storage slot corresponding to KEY3.

[0139] HSM atomically writes the new M2 and M3 messages, KEY_FLAG, and Counter value to the KEY3 storage slot. After writing, it returns a success response to the CPU and jumps back to the Secure_Working_state via the CMD_WK_DONE command. The Flash controller restores CPU access isolation for the user key area.

[0140] If the CPU sends a CMD_CANCLE command to cancel the request during the key update process, the HSM will directly roll back the current operation and jump back to Secure_Working_state without modifying the original key data.

[0141] Status handling during the return-to-factory repair phase:

[0142] When a device malfunctions and needs to be returned to the factory for repair, the manufacturer sets LC_CTRL to 0x55 (return to factory status) using a dedicated debugging command. At this time, the Flash controller automatically deletes all stored data for user keys KEY1~KEY10 and disables CPU access permissions for all root key areas, retaining only read permissions for Boot_param, the first-level Bootloader, and UID. This prevents the leakage of sensitive keys during the repair process and fully complies with the security rules of the technical solution.

[0143] In one embodiment, refer to Figure 6 and Figure 7 As can be seen, this embodiment is applied to the built-in low-power lightweight MCU of the NB-IoT smart gas meter. This MCU adopts a Cortex-M0+ core, with 128KB NOR Flash, 8KB system SRAM and an independent physical HSM module. The HSM does not have a built-in large-capacity dedicated cache, which fully matches the applicable scenario of the technical solution of this invention. The specific implementation process is as follows:

[0144] ROM KEY registration process:

[0145] During the chip manufacturing process, the initial value of LC_CTRL is 0x00. At this time, the CPU has read and write permissions to all Flash areas. Engineers directly write the three types of ROM keys into the Flash OTP area in a secure programming environment. Each key is stored in the format of 1 byte flag bit + 128 bits of key value. The flag bit is set to 0x00 to indicate that it is valid.

[0146] Write SECRET_KEY, BOOT_KEY, and MASTER_ECU_KEY sequentially. After each type of ROM key is burned, the LC_CTRL value is updated to 0x05 and 0x0F respectively. After the burning is completed, LC_CTRL is set to 0x50 (mass production state). The Flash controller automatically disables the CPU's read and write permissions to all ROM key areas. The ROM key is permanently unmodifiable after being written and can only be accessed internally by the HSM.

[0147] NVM KEY registration and update process:

[0148] This registration requires KEY2 (KEYID=4H) for NB-IoT uplink data encryption, and can only be executed after the HSM enters the Secure_Working_state:

[0149] The cloud platform cryptographic machine pre-calculates and generates messages M1, M2, M3, and M5, which are then sent to the main CPU of the gas meter. The CPU then passes M1 to M3 to the HSM and sends the CMD_LOAD_KEY command.

[0150] HSM sequentially verifies: the current working state is secure, the target key WRITE_PROTECTION bit is not enabled, and the Counter value 0x000002 carried by M2 is greater than the currently stored 0x000001. After the verification is successful, M5 is calculated and generated and returned to the CPU.

[0151] The CPU compares the M5 returned by the HSM with the pre-received M5. After the verification is successful, the encrypted key data of the sector corresponding to KEY2 in the Flash is temporarily stored in the system SRAM (without occupying the HSM's dedicated cache). After erasing the old sector, new M2 and M3 messages are written. After completion, the CPU sends the CMD_WK_DONE command to the HSM. The HSM returns the Secure_Working_state. Throughout the entire process, the CPU does not access the plaintext key and only processes the encrypted messages.

[0152] Key usage process:

[0153] When the gas meter reports data that requires encryption using KEY2:

[0154] HSM reads the stored M2 and M3 messages from the Flash secure area based on KEYID=4H, constructs the M1 message by combining it with the built-in UID, and calls Crypto Core to calculate the CMAC value of the M1+M2 concatenated data to obtain M3'. The value is consistent with the read M3 value, confirming that the key storage is intact and has not been tampered with.

[0155] HSM uses K1 to decrypt M2 to obtain the plaintext key, reads the corresponding KEY_FLAG bit, confirms that the encryption operation is consistent with the key's intended use, and performs the encryption operation to avoid incorrect encryption / decryption output.

[0156] In one embodiment, the present invention can also use the HSM's internal 8-bit lifecycle register and Flash access control list (ACL) to implement access control:

[0157] Configure ACL rule tables in the Flash controller in advance to define CPU read and write permissions corresponding to different lifecycle values ​​for the Boot parameter area, SECRET_KEY area, BOOT_KEY area, MASTER_ECU_KEY area, and user key area.

[0158] The HSM's internal lifecycle register values ​​are updated sequentially during chip manufacturing, root key programming, mass production, and return to the factory. The Flash controller reads the register values ​​in real time and matches them with ACL rules to achieve access control for each security zone. When the lifecycle enters the scrapping stage, the ACL automatically triggers the Flash controller to clear all user key data, achieving the same lifecycle security control effect as the original solution.

[0159] In one embodiment, for scenarios where the HSM has no dedicated cache, Flash small sector segmentation storage is used to optimize cache requirements:

[0160] KEY1~KEY10 are stored in 10 independent 128B sectors, with each key occupying an independent sector and not needing to share sectors with other keys;

[0161] When updating KEY2, only the encrypted data of the 128B small sector corresponding to KEY2 needs to be erased and cached. There is no need to cache all the key data of the entire large sector, reducing the cache requirement from 2KB to 128B. This adapts to the SRAM resource limitations of lightweight chips. The CPU still only assists in completing the sector erasure and write-back operations and cannot obtain the plaintext key. The security level is consistent with the original solution.

[0162] In one embodiment, a two-way verification mechanism using CPU and HSM is employed to enhance the tamper-proof capability of the registration process.

[0163] The cloud platform sends all the pre-calculated M1~M5 to the CPU. The CPU then sends M1~M5 to the HSM. The HSM calculates local M4 and M5 based on the received M1~M3 and compares them with the M4 and M5 sent by the CPU. Only after all the two-way verifications pass can the key update be performed in Key_Update_state.

[0164] Adding an extra step of HSM to verify the checksum passed to the CPU can further avoid the risk of tampering during message transmission and also achieve secure key registration, making it suitable for application scenarios with higher security requirements.

[0165] Working principle:

[0166] As an independent physical hardware module, the HSM connects to the Flash controller via a dedicated encrypted bus. The Flash controller integrates a command arbitrator at its front end, which sets HSM access requests to the highest priority by default. When the HSM performs operations, it automatically blocks Flash access requests from the CPU or other bus master devices, preventing race conditions and unauthorized access at the hardware level. The Flash physical layer is divided into four hardware-isolated secure zones. The CPU / DMA read / write permissions for each zone are dynamically controlled by the LC_CTRL signal output by the HSM. The core key zone can only be directly accessed by the HSM, achieving physical isolation between secure and insecure resources.

[0167] A closed trust chain is constructed using a three-level key system, with the root key never exposed to the external bus throughout the process.

[0168] The underlying ROM key (SECRET_KEY, BOOT_KEY, MASTER_ECU_KEY) is written into the OTP storage area as the root trust anchor during the factory stage. It is permanently unmodifiable and can only be read by the internal logic of HSM.

[0169] The intermediate layer consists of extended keys K1 and K2, which are generated within the HSM based on MASTER_ECU_KEY using the AES-MP key derivation algorithm. They serve as the encryption key and verification key for key updates, respectively, thus preventing the root key from directly participating in business operations.

[0170] The upper layer consists of NVM business keys (KEY1~KEY10), which are stored in an encrypted format of M2 ciphertext + M3 checksum. Only HSM can decrypt them to obtain the plaintext key, thus achieving hierarchical control and minimum access isolation of keys.

[0171] The key registration and update process employs a lightweight mechanism involving encrypted interaction, multiple verifications, and CPU assistance, ensuring that no plaintext keys are exposed throughout the entire process.

[0172] The key update message adopts the standardized format of M1~M5: M1 is bound to the device's unique UID to realize identity verification, M2 uses AES-CBC to encrypt the plaintext of the key and attribute information, M3 is the CMAC integrity check value of M1+M2, and M4~M5 are two-way confirmation messages;

[0173] After HSM completes the full-process verification (lifecycle permissions, UID matching, Counter anti-replay, CMAC integrity), the CPU assists in temporarily storing the encryption key data of the corresponding sector of Flash to the system SRAM, completing the old sector erasure and new key write-back operation. It does not occupy the dedicated cache resources of HSM. The CPU only processes encrypted messages throughout the process and cannot obtain plaintext keys.

[0174] Each time the key is invoked to perform encryption / decryption / MAC operations, the HSM automatically performs triple verification to avoid erroneous calculations.

[0175] First, read M2 and M3 from the Flash storage, construct M1 by combining the built-in UID, recalculate CMAC to get M3', and compare it with the stored M3 to verify the integrity of the key storage;

[0176] Decrypt M2 to obtain the plaintext key and KEY_FLAG attribute, verify that the current operation matches the purpose and key length specified by KEY_FLAG to prevent unauthorized use;

[0177] Verify that the current security state matches the requirements of the BOOT_PROTECTION bit, and only perform the operation if the security state meets the requirements.

[0178] By linking the LC_CTRL signal with the Flash controller, fine-grained access control is achieved throughout the entire lifecycle: depending on the different stages of the chip such as factory programming, root key writing, mass production, and return to the factory, the LC_CTRL outputs corresponding control values, the Flash controller dynamically adjusts the CPU read and write permissions of each security area, and automatically triggers the user key clearing operation at the end of the lifecycle, covering the access control needs of the entire lifecycle.

[0179] By storing the user key in encrypted form, the CPU can assist in the temporary storage and erasure / write operations of sector data, directly reusing system SRAM resources and eliminating the need for a large-capacity dedicated cache built into the HSM. During key updates, the CPU only processes encrypted messages and cannot obtain the plaintext key, thus avoiding any security risks. This design reduces the dedicated cache requirement of the HSM to ≤256B, making it directly adaptable to MCU scenarios with extremely low resource requirements, such as Cortex-M0+, thereby reducing hardware costs.

[0180] An end-to-end integrity verification mechanism is built into the key storage and retrieval process: each user key corresponds to a stored M3CMAC checksum. Each time a key is retrieved, the HSM recalculates M3' and compares it with the stored value. If a bit flip occurs in the Flash memory, the verification will fail immediately, and the operation will be rejected. This mechanism does not rely on the hardware verification capabilities of the Flash memory; it can be implemented purely logically and adapted to all types of low-cost Flash memory, thus reducing the key operation error rate.

[0181] The M1 message binds a unique UID to the device, allowing key updates only to the corresponding device and preventing malicious key injection across devices. A 24-bit monotonically increasing Counter value is introduced, ensuring that updates are only performed when the new Counter value is greater than the stored value, thus completely preventing replay attacks at the protocol level. Dual protection through AES-CBC encryption and CMAC integrity verification ensures that keys are not tampered with during transmission and storage. Furthermore, LC_CTRL enables fine-grained access control throughout the entire lifecycle, granting only necessary Flash access permissions at each stage. KEY_FLAG further restricts key usage to the minimum required permissions, building a complete security system from hardware to protocol levels and reducing the key update attack surface.

[0182] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various equivalent changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A key encryption registration method for a lightweight hardware security module, applied to a lightweight microcontroller unit (MCU) integrating a hardware security module (HSM), wherein the HSM shares the on-chip Flash storage of the MCU with the CPU, characterized in that, The method is based on an MCU in which the Flash controller front end is equipped with a command arbiter that prioritizes responding to HSM requests. The HSM has a built-in LC_CTRL lifecycle controller and a 24-bit monotonic counter. The method includes the following steps: After S1 and HSM complete CMD_INIT initialization and pass the secure boot verification, they enter the secure working state. They receive the CMD_LOAD_KEY command sent by the CPU and the corresponding M1, M2 and M3 messages. First, they verify the key update permission under the current life cycle through the LC_CTRL controller. If the permission verification fails, the request is directly rejected. S2, HSM parses the M1 message to obtain the KEYID of the key to be registered and the device UID carried in the request, and verifies that the UID carried in the request is consistent with the device UID stored in the HSM's built-in storage. If they are inconsistent, the request is rejected. S3 and HSM call the pre-stored MASTER_ECU_KEY to derive the encryption key K1 and the verification key K2. Use K2 to calculate the CMAC value of the concatenated data of M1 and M2 messages. Compare the calculated CMAC value with the received M3 message to verify consistency. If the verification fails, the request is rejected. S4. After successful verification, HSM uses K1 to decrypt the M2 message, obtains the new Counter value, KEY_FLAG flag and plaintext key carried in it, and verifies that the current stored Counter value of the key to be updated is less than the new Counter value and that the write protection bit in the KEY_FLAG flag is not set. If any verification fails, the request is rejected. S5. After the verification is successful, the HSM calculates the M5 verification value based on the current key information to be registered and returns it to the CPU. The CPU compares the received M5 verification value with the pre-generated M5 verification value. If they match, the CPU returns a verification success signal to the HSM. After receiving the signal, the HSM enters the key update state and initiates a high-priority write request to the Flash command arbitrator. S6, the Flash command arbitrator suspends the Flash access operation on the CPU side, and the HSM writes the new M2 message and M3 message in pairs into the independent storage bit of the corresponding KEYID in the Flash. The writing process does not require reading or caching other key data in the Flash sector to which the storage bit belongs. S7. After writing is complete, HSM verifies the consistency of the M2 and M3 data read back from Flash. If the verification passes, it updates the Counter value of the corresponding key, returns a key registration success response to the CPU, restores the CPU's Flash access permissions, and returns to a secure working state.

2. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, The permission verification rules for the LC_CTRL controller in step S1 are as follows: when the LC_CTRL value is 0x00, write operations for all types of keys are allowed; when it is 0x05, write operations for BOOT_KEY, MASTER_ECU_KEY, and user keys are allowed; when it is 0x0F, write operations for MASTER_ECU_KEY and user keys are allowed; when it is 0x50, only user key update operations are allowed; and when it is 0x55, all key write operations are prohibited.

3. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, The derivation method of encryption key K1 and verification key K2 in step S3 is as follows: using the AES-MP key derivation algorithm, with MASTER_ECU_KEY as the root key, and using the fixed parameters KEY_UPDATE_ENC_C and KEY_UPDATE_MAC_C preset in HSM as derivation factors, respectively, a 128-bit encryption key K1 and a 128-bit verification key K2 are generated.

4. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, In step S4, if the current storage Counter value of the key to be updated reaches the maximum value of 24 bits and overflows, the storage slot corresponding to the key becomes permanently invalid, and the HSM rejects all subsequent update requests for that slot; if the WRITE_PROTECTION flag in the KEY_FLAG flag of the key to be updated is 1, the update request for that key is rejected.

5. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, In step S6, the Flash command arbitrator is configured with a two-level access priority scheduling rule: the Flash operation request priority of HSM is always higher than the Flash operation request of CPU; if the CPU is performing a Flash operation when HSM initiates a write request, the arbitrator waits for the CPU to complete its current single-step atomic operation and then immediately executes the HSM's write request, blocking all CPU-side Flash access requests during this period. After the HSM write is completed, the CPU access blocking is automatically released.

6. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, The Flash memory stores 64 bytes of data for each user key, storing only the M2 and M3 messages. The M2 message is encrypted data containing Counter, KEY_FLAG, and plaintext key, encrypted with encryption key K1. The M3 message is the CMAC checksum of the concatenated M1 and M2 messages.

7. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, The method also includes a key usage verification step: when the HSM receives a key operation request carrying a KEYID, it first reads the corresponding M2 and M3 messages from the Flash according to the KEYID, generates a standard M1 message based on the current device UID and KEYID, calculates the CMAC value of the concatenated data of the standard M1 message and the read M2 message using the currently valid K2, and compares it with the read M3 message. If they match, the plaintext key is decrypted to obtain the plaintext key for subsequent operations. If they do not match, the key data is determined to be corrupted and an error response is returned.

8. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, In step S6, the erasure of the Flash sector and the write-back of non-key data during key update are completed with the assistance of the CPU. The sector data containing the encryption key is temporarily stored in the system RAM on the CPU side, without occupying the dedicated cache resources of the HSM, and the CPU cannot access the plaintext key throughout the process.

9. The key encryption registration method for a lightweight hardware security module according to claim 7, characterized in that, After decrypting to obtain the plaintext key, the HSM reads the KEY_FLAG flag corresponding to the key and verifies that the current operation type matches the purpose limited by the KEY_USAGE flag and that the current secure boot state matches the requirements of the BOOT_PROTECTION flag. Only after both verifications pass can the key be used to perform the corresponding operation.

10. The key encryption registration method for a lightweight hardware security module according to claim 1, characterized in that, If the Flash readback data verification fails in step S7, the HSM will perform a maximum of 3 retry write operations. If the retry still fails, a key write failure alarm will be triggered, and the Counter value of the corresponding key will be rolled back to the value before the current update request was initiated. At the same time, the incomplete M2 and M3 data that have been written will be erased to avoid invalid key residue.

Images