Key processing method, device, equipment, module, control unit, vehicle, medium and program product
By generating the encryption operation and decryption process of M1, M2 and M3, the problem of single key types in the prior art is solved, and flexible recording of symmetric and asymmetric keys is realized, and the adaptability of encryption is improved.
Patent Information
- Application Number
- CN202510390839.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-28
- Publication Date
- 2025-08-15
AI Technical Summary
In the prior art, the CSE module can only burn a single type of key, resulting in poor encryption flexibility and cannot meet the flexible burning requirements of symmetric keys and asymmetric keys.
By encrypting the target key, M1, M2 and M3 are generated, where M1 indicates the key type, M2 indicates the encryption key, M3 indicates the signature information, and the key user side performs integrity verification and decrypts and burns, supporting burns of different types of keys.
Improves the flexibility of key processing, can burn different types of keys, and enhances the adaptability of encryption.
Smart Images
Figure CN120498654A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of information security, and in particular to a key processing method, apparatus, device, module, control unit, vehicle, medium and program product. Background Art
[0002] As automotive functions become increasingly intelligent and automated, the security requirements for vehicle systems are also increasing. Ensuring hardware security is particularly important in advanced driver assistance systems and autonomous driving systems.
[0003] The Cryptographic Service Engine (CSE) is a lightweight Hardware Security Module (HSM) used for cryptographic acceleration and key protection, and can be used in vehicle systems. To ensure key integrity, confidentiality, and authenticity, and to prevent replay attacks, CSE modules don't burn keys directly in plaintext. Instead, they use the protocol defined in the Safety Hardware Extension (SHE) specification.
[0004] However, the above burning method can only burn a single type of key, and the encryption flexibility is poor. Summary of the Invention
[0005] Embodiments of the present application provide a key processing method, apparatus, device, module, control unit, vehicle, medium, and program product to improve the flexibility of encryption.
[0006] In a first aspect, an embodiment of the present application provides a key processing method, which is used at a key sending end and includes:
[0007] Performing an encryption operation on the target key to generate M1, M2, and M3 of the target key; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key;
[0008] A key burning request for a target key is sent to a key user, where the key burning request includes M1, M2, and M3, so that the key user, after passing an integrity check on M2 based on M3, decrypts M2 based on the type of the target key parsed from M1, obtains the target key, and burns the target key into a storage device.
[0009] In a possible implementation, performing an encryption operation on the target key to generate M1, M2, and M3 of the target key includes:
[0010] Generate M1 based on identification information of the key user, identification information of the target key, and first information, wherein the first information is used to indicate a type of the target key;
[0011] Encrypting the target key to obtain M2;
[0012] Based on the M1 and the M2, the M3 is generated.
[0013] In a possible implementation, generating M1 based on the identification information of the key user, the identification information of the target key, and the first information includes:
[0014] The identification information of the key user, the identification information of the target key, and the first information are concatenated to obtain M1.
[0015] In a possible implementation, encrypting the target key to obtain M2 includes:
[0016] Filling the target key with a number of padding bits corresponding to the type of the target key to obtain a padded target key;
[0017] The padded target key is encrypted based on a first subkey derived from the authorization key and a preset initial vector value to obtain M2.
[0018] In a second aspect, an embodiment of the present application provides a key processing method, which is used on a key user terminal and includes:
[0019] Receive a key burning request for a target key, the key burning request including: M1, M2, and M3; wherein, M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key;
[0020] Based on M3, perform integrity check on M2;
[0021] If the integrity check passes, the type of the target key is parsed from M1, and based on the type of the target key, M2 is decrypted to obtain the target key;
[0022] Burn the target key into a storage device.
[0023] In a possible implementation, parsing the type of the target key from M1 includes:
[0024] Parsing first information from M1 based on the identification information of the key user and the identification information of the target key;
[0025] Based on the mapping relationship between the first information and the key type, the type of the target key is obtained.
[0026] In a possible implementation, decrypting M2 based on the type of the target key to obtain the target key includes:
[0027] Decrypting M2 based on a first subkey derived from the authorization key and a preset initial vector value to obtain a padded target key;
[0028] A number of padding bits corresponding to the type of the target key is deleted from the padded target key to obtain the target key.
[0029] In a possible implementation, burning the target key into a storage device includes:
[0030] The target key is burned into a one-time programmable memory.
[0031] In one possible implementation, the method further includes:
[0032] Reading the target key from the storage device and verifying the read target key;
[0033] If the verification is successful, the target key is loaded into the key register.
[0034] In a possible implementation, verifying the target key includes:
[0035] Perform ECC check and / or inverse code check on the target key.
[0036] In one possible implementation, the method further includes:
[0037] If the loading of the target key is not completed when the preset time is reached, output a first prompt message, where the first prompt message is used to indicate that the loading of the target key has failed;
[0038] If the loading of the target key is completed within the preset time period, a second prompt information is output, where the second prompt information is used to indicate that the loading of the target key is completed.
[0039] In a third aspect, an embodiment of the present application provides a key processing device, which is applied to a key sending end and includes:
[0040] An encryption module, configured to perform encryption operation on a target key to generate M1, M2, and M3 of the target key; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key;
[0041] The sending module is used to send a key burning request of a target key to a key user end, wherein the key burning request includes: M1, M2 and M3, so that the key user end decrypts M2 based on the type of the target key parsed from M1, obtains the target key, and burns the target key into a storage device when the integrity check of M2 passes based on M3.
[0042] In a fourth aspect, an embodiment of the present application provides a key processing device, which is applied to a key user terminal and includes:
[0043] A receiving module, configured to receive a key burning request for a target key, wherein the key burning request includes: M1, M2, and M3; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate the signature information of the encrypted target key;
[0044] A verification module, configured to perform integrity verification on M2 based on M3;
[0045] a decryption module, configured to parse the type of the target key from M1 if the integrity check passes, and decrypt M2 based on the type of the target key to obtain the target key;
[0046] The burning module burns the target key into a storage device.
[0047] In a fourth aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;
[0048] The memory stores computer-executable instructions;
[0049] The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method as described in any one of the first aspect or the second aspect above.
[0050] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method described in any one of the first or second aspects above.
[0051] In a sixth aspect, an embodiment of the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the method described in any one of the first or second aspects above.
[0052] The embodiments of the present application provide a key processing method, device, equipment, module, control unit, vehicle, medium and program product. Compared with the existing technology, different types of keys can be burned through encryption of the target key by the key sending end and decryption and burning of the target key by the key using end, thereby improving the flexibility of encryption. BRIEF DESCRIPTION OF THE DRAWINGS
[0053] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0054] Figure 1 A schematic diagram of the process of generating a key M value according to the SHE protocol in the prior art;
[0055] Figure 2 A schematic diagram of a key update process according to the SHE protocol in the prior art;
[0056] Figure 3 A schematic diagram of a flow chart of message verification according to the SHE protocol in the prior art;
[0057] Figure 4 A flowchart of a key processing method provided in an embodiment of the present application;
[0058] Figure 5 A schematic diagram of the encryption process provided in this application embodiment;
[0059] Figure 6 A schematic diagram of the process of loading a target key provided in an embodiment of the present application;
[0060] Figure 7 A schematic diagram of a key loading process provided in an embodiment of the present application;
[0061] Figure 8 A schematic diagram of the structure of a key processing device provided in this application;
[0062] Figure 9 A schematic diagram of the structure of a key processing device provided in this application;
[0063] Figure 10 This is a schematic diagram of the structure of an electronic device provided in this application.
[0064] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION
[0065] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
[0066] In this application, the term "include" and its variations may refer to non-restrictive inclusion; the term "or" and its variations may refer to "and / or". In this application, the terms "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. In this application, "plurality" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship.
[0067] As automotive features become increasingly intelligent and automated, control units (ECUs) need to communicate with other vehicles or infrastructure to share information. To ensure data security and privacy during communication, encryption is widely used. Therefore, encryption keys must be burned into control units.
[0068] The following describes the architecture of the control unit, which can be, for example, a microcontroller unit (MCU) equipped with a hardware security module (HSM). The HSM is a hardware device used for cryptographic acceleration and key protection, providing a highly secure environment to ensure the confidentiality, integrity, and availability of keys and data. The Cryptographic Service Engine (CSE) is a lightweight HSM that lacks a separate central processing unit (CPU) as a separate subsystem and supports hardware acceleration of cryptographic algorithms.
[0069] In the existing technology, in order to ensure the integrity, confidentiality, and authenticity of the key and prevent replay attacks, when the CSE module burns the key, it does not directly burn the key in plain text. Instead, it follows the protocol defined in the Safety Hardware Extension (SHE) specification, which focuses on the functions and standards of security-related hardware.
[0070] In the SHE protocol, a series of calculations are performed on the original key to generate five sets of data, M1 to M5. M1 to M3 serve as input, and M4 and M5 serve as verification. Because the calculation of M1-M5 values from the key to be added or updated is irreversible, the entire process is secure. It should be noted that this calculation process can be performed offline by hardware with computing capabilities according to a predefined software program. The following describes the SHE protocol's generation of M1-M5 from the key to be added or updated. It should be understood that the key to be added can represent the initial key burn-in, while the key to be updated can represent a key update.
[0071] Figure 1 The figure is a flow chart of the prior art for generating a key M value according to the SHE protocol. Figure 1 As shown, the process of generating the key M value according to the SHE protocol is:
[0072] 11. Calculate K1 and K2.
[0073] The Key Derive Function (KDF) is a utility function used to calculate the values of M1 to M5. The general formula of the KDF function is as follows:
[0074] K_out=KDF(AuthKey,Constant)
[0075] The parameters AuthKey and Constant are both 16-byte input parameters, and K_out is a 16-byte output parameter. The KDF function concatenates the parameters AuthKey and Constant, uses a compression algorithm, and obtains the output K_out.
[0076] The calculation formula for K1 and K2 using the KDF function is as follows:
[0077] K1=KDF(AuthKey,KEY_UPDATE_ENC_C)
[0078] K2=KDF(AuthKey,KEY_UPDATE_MAC_C)
[0079] Among them, AuthKey is used as the authorization key. In the factory state, an empty key with all bits set to 1 can be used as the authorization key.
[0080] KEY_UPDATE_ENC_C may be defined as 0x01015348_45008000_00000000_000000B0 according to the Hardware Interface Specification-Safety Hardware Extension (HIS-SHE) specification.
[0081] KEY_UPDATE_MAC_ can be defined as 0x01025348_45008000_00000000_000000B0 according to the HIS-SHE specification.
[0082] As described above, K_out calculated by the KDF function is an output parameter with a length of 16 bytes. Therefore, the lengths of K1 and K2 are both 16 bytes.
[0083] 12. Calculate M1 to M3.
[0084] (1) The length of M1 is usually 128 bits. The calculation formula of M1 is as follows:
[0085] M1=UID||ID||AuthKeyID
[0086] The unique identifier (UID) may represent a 120-bit unique identifier of a control unit (eg, MCU). In factory-installed state or when the wildcard attribute (WILDCARD) of the key is not enabled, the UID may be replaced by 0.
[0087] The identifier (ID) may indicate the key ID of the key to be added or updated, and has a length of 4 bits.
[0088] AuthKeyID may represent the ID of the authorization key.
[0089] In the scenario of updating the key, if the key before the update is used as the authorization key, the value of the ID parameter can be consistent.
[0090] If MASTER_ECU_KEY is used as the authorization key, AuthKeyID is the ID of MASTER_ECU_KEY (KeyID=0x1), and is 4 bits long.
[0091] || can represent bitwise concatenation of data, i.e., concatenating the UID, ID, and AuthKeyID bit by bit to obtain M1. For example, concatenation here means connecting the last character of one data point with the first character of another data point to form a single data point. For example, the concatenation of 0xF5||0xA produces the data point 0xF5A.
[0092] (2) The length of M2 is usually 256 bits. The calculation formula of M2 is as follows:
[0093] If D-Flash partitioning is performed and SFE == 0x0 is set, then:
[0094] M2=ENC CBC (K1, IV=0, (CID||FID||0bit1...0bit95||KEY))
[0095] If D-Flash partitioning is performed and SFE == 0x1 is set, then:
[0096] M2=ENC CBC (K1, IV=0, (CID||FID||0bit1...0bit94||KEY))
[0097] Among them, CID is the value of the key counter (Counter for Identification, CID) (28 bits), which starts counting from 1. The counter value is increased by 1 each time the key is updated. If the key is restored to factory settings, the counter value starts counting from 1 again.
[0098] The Field Identifier (FID) can represent the key attributes. When SFE is 0, the FID is 5 bits and can be calculated using the following formula:
[0099] FID=WRITE_PROT||BOOT_PROT||DEBUG_PROT||KEY_USAGE||
[0100] WILD_CARD
[0101] When SFE is 1, FID is 6 bits and can be calculated using the following formula: FID = WRITE_PROT | | BOOT_PROT | | DEBUG_PROT | | KEY_USAGE | | WILDCARD | | VERIFY_ONLY
[0102] The WRITE_PROT attribute represents write protection, and the key with this attribute cannot be modified.
[0103] The BOOT_PROT attribute indicates that if the control unit fails to boot securely, the key becomes invalid. Unless the key is replaced, the control unit cannot be successfully booted securely.
[0104] The DEBUG_PROT property represents debug port protection. After the next reset, if a debugger is connected, this key cannot be used.
[0105] The KEY_USAGE attribute distinguishes whether the key is used to generate / verify a Cipher Block Chaining-Message Authentication Code (CMAC) based on a symmetric key block encryption algorithm, or for encryption / decryption.
[0106] The WILDCARD attribute indicates that the UID of the control unit (such as MCU) must be used to update the key. If this attribute is not set, 0 can be used as the UID.
[0107] The VERIFY_ONLY attribute indicates that the key is used only for CMAC verification and cannot be used for CMAC generation.
[0108] 0bit1...0bit94 / bit95: If SFE is equal to 0, 95 zero-filling bits are added; if it is equal to 1, 94 zero-filling bits are added.
[0109] KEY may indicate the key to be added or updated (128 bits).
[0110] CID||FID||0bit1...0bit94||KEY is the concatenated data consisting of CID, FID, 0 padding bits, and KEY.
[0111] The value of M2 is obtained by encrypting the concatenated data using the Advanced Encryption Standard (AES) in 128-bit Cipher Block Chaining (CBC) mode with K1 as the encryption key and the Initialized Value (IV) set to 0.
[0112] (3) The length of M3 is 128 bits. The calculation formula of M3 is as follows:
[0113] M3=CMAC K2 (M1||M2)
[0114] Concatenate M1 and M2, use K2 as the key, and calculate the CMAC value, which is the value of M3. M3 is used to verify the integrity of M1 and M2.
[0115] 13. Calculate K3 and K4.
[0116] The formula for calculating K3 and K4 using the KDF function is as follows:
[0117] K3=KDF(KEY ID ,KEY_UPDATE_ENC_C)
[0118] K4=KDF(KEY ID ,KEY_UPDATE_MAC_C)
[0119] Among them, KEY ID It can indicate the ID of the key to be updated.
[0120] 14. Calculate M4 and M5.
[0121] (1) The length of M4 is usually 256 bits. The calculation formula of M4 is as follows:
[0122] M4=UID||ID||AuthKey ID ||M4^
[0123] Among them, AuthKey ID Can indicate the authorization code needed to update the key.
[0124] The calculation formula of M4^ is as follows:
[0125] M4^=ENC ECB (K3, (CID||1bit1||0bit1...0bit99))
[0126] That is, K3 is used as the encryption key, one padding bit with a value of 1 and 99 padding bits with a value of 0 are added after CID, and the AES-128 Electronic Code Book (ECB) mode encryption operation is performed.
[0127] (2) The length of M5 is usually 128 bits. The calculation formula of M5 is as follows:
[0128] M5=CMAC K4 (M4)
[0129] Use K4 as the key to obtain the CMAC value of M4, that is, the value of M5.
[0130] The above describes the process of generating M1 to M5 using the key to be added or updated according to the SHE protocol. When the CSE module burns the encrypted key to be added or updated, it can include two parts: a key update and a verification message. The key update is the actual memory update used to complete the burning process of the key to be added or updated. The verification part is used to confirm whether the key update is successful.
[0131] It should be understood that the key update mentioned here includes the scenario of burning a key for the first time and updating a previously burned key.
[0132] Take the control unit as MCU as an example, Figure 2 The flowchart of the key update process according to the SHE protocol in the prior art is as follows: Figure 2 As shown, the process of key update of the CSE module according to the SHE protocol is as follows:
[0133] 21. Obtain the offline M value. That is, the M value calculated offline using the above method.
[0134] 22. Load the M value.
[0135] 23. Determine KEY ID Whether it is write protected needs to be specified, here KEY ID Indicates the address of the MCU to which the key to be added or updated needs to be burned. If yes, this MCU address does not allow the key to be added or updated to be written, and proceed to step 20. If no, this MCU address allows the key to be added or updated to be written, and proceed to step 24.
[0136] 24. Read Authkey ID .
[0137] 25. Calculate M3*. The calculation formula for M3* is as follows:
[0138] M3*=CMAC K2 (M1||M2)
[0139] 26. Determine whether M3* is equal to M3. If so, it indicates that the key to be added or updated has not been tampered with, and then proceed to step 27; if not, it indicates that the key to be added or updated has been tampered with, and then proceed to step 20.
[0140] 27. Decryption. The decryption formula is as follows:
[0141] KEY=DEC CBC，K1，IV＝0 (M2)
[0142] 28. Determine whether CID* is greater than CID. If so, steps 21-27 are valid, and then proceed to step 29; if not, steps 21-27 fail, and then proceed to step 20.
[0143] 29. Burn KEY, CID, and FID. CID and FID can be obtained by decrypting M2 in step 27.
[0144] 20. Stop key update.
[0145] Currently, after burning KEY, CID, and FID into the CSE module, you can verify whether the key has been burned correctly by following the steps below: Figure 3 FIG. 1 is a flow chart of a message verification process according to the SHE protocol in the prior art, as shown in FIG. Figure 3 As shown, the process includes:
[0146] 31. Read ID, CID, UID, and get KEY ID .
[0147] 32. According to KEY ID Calculate K3. The calculation formula is the same as the above calculation formula for K3 and K4, and will not be repeated here.
[0148] 33. Calculate M4^ based on K3. The formula for calculating M4^ is the same as the formula for calculating M4^ above and will not be repeated here.
[0149] 34. Calculate M4* based on M4^. The formula for calculating M4* is the same as the formula for calculating M4 above and will not be repeated here.
[0150] 35. Determine whether M4* is equal to M4. If so, it indicates that the key to be added or updated has not been attacked by a replay attack, and then proceed to step 36. If not, it indicates that the key to be added or updated has been attacked by a replay attack, and then proceed to step 38.
[0151] 36. Calculate M5* based on M4*. The formula for calculating M5* is the same as the formula for calculating M5 above and will not be repeated here.
[0152] 37. Determine whether M5* and M5 are equal. If so, the CID integrity check of the key to be added or updated succeeded, and proceed to step 38. If not, the CID integrity check of the key to be added or updated failed, indicating that the key to be added or updated was not correctly burned, and proceed to step 39.
[0153] 38. Output verification prompt information, which is used to indicate that the key to be added or updated is burned correctly.
[0154] 39. Output verification prompt information, which is used to indicate that the key to be added or updated is incorrectly burned.
[0155] The above describes the process of burning the key to be added or updated according to the SHE protocol. Because this process is computationally irreversible, it can prevent the leakage of the key to be added or updated to a certain extent. However, the above method can only burn symmetric keys with a length of 128 bits. In actual applications, in addition to symmetric keys, asymmetric keys are also used. This method cannot meet the requirements of burning asymmetric private keys of varying lengths, resulting in poor encryption flexibility.
[0156] Therefore, the present application proposes a key processing method, device, equipment, module, control unit, vehicle, medium and program product, which can burn different types of keys while ensuring the integrity, confidentiality and authenticity of the key, thereby improving the flexibility of encryption.
[0157] The encryption of the key in this application involves interaction between two parties. One party is the key sender, whose execution subject can be a hardware device with encryption capabilities; the other party is the key user, whose execution subject can be a hardware device with storage and decryption capabilities. This application does not limit this.
[0158] For example, the key sending end can be a key burning control end, or a key burning host computer, etc. The control end mentioned here can be a device located in the same local area network as the key user end, or a device, platform or cluster that communicates remotely with the key user end, such as a server located in the cloud, without limitation.
[0159] The key using end may be, for example, the aforementioned control unit, or a CSE module in the control unit.
[0160] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0161] Figure 4 This is a flow chart of the key processing method provided in the embodiment of the present application. The method mainly involves the key sending end and the key using end. Figure 4 As shown, the method includes:
[0162] S101: The key sending end performs encryption operation on the target key to generate M1, M2 and M3 of the target key, where M1 is used to indicate the type of the target key, M2 is used to indicate the encrypted target key, and M3 is used to indicate the signature information of the encrypted target key.
[0163] Compared with the prior art, the present application improves M1 so that M1 can be used to indicate the type of the target key. The type of the target key can be, for example, a symmetric key, an asymmetric SM2 key, an asymmetric RSA (Rivest-Shamir-Adleman) key, etc.
[0164] M2 indicates the target key for encryption. Compared to existing technologies, M2 can be fixed in length. Without changing the SHE protocol's M2 length requirement, encryption can be performed using specific characters of varying lengths for different target keys, enabling the burning of different types of keys. The specific characters mentioned here can be, for example, 0, 1, or English letters.
[0165] Alternatively, the SHE protocol can be further modified to fill specific character filling bits of the same length for different types of target keys, so that M2 corresponding to different types of target keys has different lengths. In this implementation, M1 can indicate the type of target key, or it can be constructed using the existing technology and not be used to indicate the type of target key. The length of M2 is directly used to implicitly indicate the type of target key.
[0166] M3 is used to indicate the signature information of the encrypted target key, which can be used to verify the integrity of the target key. For example, M3 can be generated using the method described in the prior art.
[0167] Optionally, encryption can be the process of converting the target key from plaintext to ciphertext to ensure the confidentiality of the target key during transmission. For example, AES encryption method or Elliptic Curve Cryptography (ECC) encryption method can be selected, and this application does not limit this.
[0168] S102: The key sending end sends a key burning request of the target key to the key using end. The key burning request includes: M1, M2 and M3.
[0169] Optionally, the key sending end and the key using end may be connected via a wired connection, such as a direct connection via an interface, or may be connected wirelessly, such as via Bluetooth, which is not limited in this application.
[0170] Optionally, the key sending end may send the key burning request to the key using end via wired communication, for example, via a serial interface, or via wireless communication, which is not limited in this application.
[0171] S103. The key user performs an integrity check on M2 based on M3.
[0172] For example, integrity verification can be a verification method to ensure that the target key has not been tampered with during transmission. For example, M3 can be verification information attached to M2. If the verification information is consistent, it can be said that the integrity of M2 is guaranteed and the target key has not been tampered with during transmission.
[0173] In one embodiment, the integrity check may be performed by a cryptographic accelerator in the CSE module.
[0174] For example, using existing technology Figure 2 In the manner of steps 25 and 26 shown, integrity check is performed on M2.
[0175] S104. When the integrity check passes, the key user parses the type of the target key from M1 and decrypts M2 based on the type of the target key to obtain the target key.
[0176] Optionally, as described above, when the integrity check passes, the key user can obtain the type of the target key by parsing M1, and decrypt M2 based on the type of the target key to obtain the target key.
[0177] Optionally, if M2 can adopt a fixed length and adopt specific character padding bits of different lengths to encrypt different types of target keys, correspondingly, the padding bits of corresponding lengths can be removed during decryption to obtain the target key.
[0178] If M2 uses different lengths, that is, when different types of target keys are encrypted using specific character padding bits of a fixed length, the padding bits of the fixed corresponding length can be removed during decryption to obtain the target key.
[0179] In one embodiment, this step may be performed by an encryption accelerator in the CSE module.
[0180] S105: The key user burns the target key into a storage device.
[0181] Optionally, taking a vehicle as an example, the storage device may be the aforementioned MCU. The key user may directly burn the target key, or may verify the target key multiple times before burning it, which is not limited in this application.
[0182] The storage device may be, for example, an Electrically Erasable Programmable Read-Only Memory (EEPROM). In this implementation, after storing the data in the storage device, the data may be further stored in the storage device. Figure 2 Verify in the manner shown to ensure burning.
[0183] The storage device can be, for example, an OTP. Due to the unique one-time programming feature of OTP, once the target key is written into the OTP memory, it is permanently stored there and cannot be erased or modified. In this implementation, integrity verification of the key counter is not necessary, M4 and M5 are eliminated, simplifying the programming process and improving programming efficiency. In this implementation, the key user can also program different types of target keys into different storage areas of the OTP.
[0184] Compared with the prior art, the process of encrypting the target key by the key sending end and decrypting and burning the target key by the key using end in the embodiment of the present application can burn different types of keys, thereby improving the flexibility of encryption.
[0185] The following describes in detail how the key transmitter performs encryption operations on the target key to generate M1, M2, and M3 of the target key. Here, M2 is described using an example of using a fixed length and AES-128 CBC encryption for different types of target keys.
[0186] Figure 5 The flowchart of the encryption operation provided in the embodiment of the present application is as follows: Figure 5 As shown, the method includes:
[0187] S201. The key sending end generates M1 based on identification information of the key using end, identification information of the target key, and first information, where the first information is used to indicate the type of the target key.
[0188] Optionally, the identification information of the key user may be the above-mentioned UID.
[0189] Optionally, the identification information of the target key may be the above-mentioned target key ID.
[0190] Optionally, the first information may be used to indicate the type of the target key, such as a symmetric key, an asymmetric SM2 key, an asymmetric RSA key, etc. The first information may also include a mapping relationship between key types, such as 0x0 representing a symmetric key, 0x1 representing an asymmetric SM2 key, and 0x2 representing an asymmetric RSA key.
[0191] Optionally, M1 can be generated by processing or combining the key sending end's identification information of the key user, the identification information of the target key, and the first information. For example, the key sending end can concatenate the three to generate M1, or can encode the three and then concatenate them to generate M3, which is not limited in this application.
[0192] For example, taking the example that the key sending end can concatenate the three to obtain M1, M1 can be obtained by the following formula:
[0193] M1=UID||ID||KeyType
[0194] Among them, KeyType can represent the first information.
[0195] S202. The key sending end fills the target key with a number of filling bits corresponding to the type of the target key to obtain a filled target key.
[0196] Optionally, the target key may be filled with a specific filling character, for example, a character with a value of 0 (referred to as 0 filling), which is not limited in this application.
[0197] Taking 0 padding as an example, if the target key type is a symmetric key and the length is 128 bits, 3968 bits of padding bits can be used to pad the target key to obtain the padded target key 0 bit1 ...0 bit3968 ||KEY, where KEY is the target key.
[0198] For example, if the target key type is an asymmetric SM2 key and the length is 256 bits, the target key can be padded with 3840 bits of padding bits to obtain the padded target key 0 bit1 ...0 bit3840 ||KEY, where KEY is the target key.
[0199] For example, if the target key type is an asymmetric RSA key and its parameters, and the length is 2048 bits, the target key can be padded with 2048 bits of padding bits to obtain the padded target key 0 bit1 ...0 bit2048 ||KEY, where KEY is the target key.
[0200] It should be understood that the above is only an exemplary method for generating M2 for some types of keys. For other keys, the above method can also be used to adaptively adjust the number of bits padded with 0 according to their own length to generate M2 of fixed length.
[0201] S203. The key sending end encrypts the padded target key based on the first subkey derived from the authorization key and the preset initial vector value to obtain M2.
[0202] Optionally, the first subkey derived from the authorization key may be the same as K1 in the prior art, which is not described in detail here. The preset initial vector value may be a preset initial vector value of the AES-128CBC encryption method, for example, IV=0.
[0203] If the target key type is a symmetric key, the calculation formula for M2 is as follows:
[0204] M2=ENC CBC (K1, IV=0, (0bit1...0bit3968||KEY))
[0205] If the target key type is an asymmetric SM2 key, the calculation formula for M2 is as follows:
[0206] M2=ENC CBC (K1, IV=0, (0bit1...0bit3840||KEY))
[0207] If the target key type is an asymmetric RSA key and its parameters, the calculation formula for M2 is as follows:
[0208] M2=ENC CBC (K1, IV=0, (0bit1...0bit2048||KEY))
[0209] In the embodiment of the present application, when the scope of modification of the SHE protocol is small, different types of target keys are encrypted only by changing the length of the 0 padding bit. Compared with the prior art, the flexibility of encrypting different types of keys is increased.
[0210] S204. The key sending end generates M3 based on M1 and M2.
[0211] As described above, M3 may be used to indicate the signature information of the encrypted target key, and the signature information may be used to verify the integrity of the target key.
[0212] Exemplarily, the key sending end can encrypt the concatenated data based on the second subkey derived from the authorization key to generate M3. The second subkey derived from the authorization key can be the same as K2 in the prior art and will not be described in detail here. The concatenated data can be obtained by concatenating M1 and M2, i.e., M1||M2. After concatenating M1 and M2, the key sending end uses K2 as the key and calculates the CMAC value as M3. The calculation formula for M3 is as follows:
[0213] M3=CMAC K2 (M1||M2)
[0214] The embodiment of the present application combines M1 and M2 to achieve data merging and integration. The combined data is encrypted using a second subkey derived from the authorization key to ultimately generate M3, ensuring the security and confidentiality of the combined data and effectively preventing tampering with the target key.
[0215] The above is the process of the key sending end performing encryption operation on the target key to generate M1, M2 and M3 of the target key. After the key sending end performs encryption operation on the target key, it will send a target key burning request to the key using end. The key burning request includes: M1, M2 and M3.
[0216] After receiving the key burning request for the target key, the key user will perform an integrity check on M2 based on M3. If the integrity check passes, M2 will be decrypted based on the type of the target key parsed from M1 to obtain the target key and burn the target key to the storage device.
[0217] S205 . The key sending end sends a key burning request of the target key to the key using end. The key burning request includes: M1 , M2 and M3 .
[0218] S206. The key user may encrypt the concatenated data based on the second subkey derived from the authorization key to generate M3*.
[0219] The second subkey derived from the authorization key can be the same as K2 in the prior art and will not be described here. The concatenated data can be obtained by concatenating M1 and M2, i.e., M1||M2. The key transmitter concatenates M1 and M2, uses K2 as the key, and calculates the CMAC value as M3*. The calculation formula for M3* is as follows:
[0220] M3*=CMAC K2 (M1||M2)
[0221] S207: The key user determines whether M3 and M3* are consistent. If they are consistent, it is determined that the integrity check of M2 has passed.
[0222] As mentioned above, integrity checking can be a verification method to ensure that the target key has not been tampered with during transmission.
[0223] Therefore, if M3 and M3* are consistent, it is determined that the integrity check of M2 has passed. If M3 and M3* are inconsistent, it is determined that the integrity check of M2 has failed.
[0224] The embodiment of the present application performs integrity verification on M2 by comparing M3 and M3*, thereby improving the reliability and security of the key transmission process.
[0225] If the integrity check passes, the key user can decrypt M2 based on the type of the target key parsed from M1, obtain the target key, and burn the target key to the storage device. This process is described in detail below.
[0226] S208: The key user may parse the first information from M1 based on the identification information of the key user and the identification information of the target key.
[0227] As mentioned above, M1 can be obtained by splicing the identification information of the key user, the identification information of the target key, and the first information. Therefore, the key user can determine the position of the first information in M1 based on a specific field, and thus obtain the first information by reading M1.
[0228] S209: The key user obtains the type of the target key based on the mapping relationship between the first information and the key type.
[0229] The mapping relationship may be pre-written on the key user side. When used, the mapping relationship between the first information and the key type may be set according to the encryption requirements of the key user side.
[0230] S210 . After obtaining the type of the target key, the key user may decrypt M2 based on the type of the target key to obtain the target key.
[0231] Exemplarily, the key user may decrypt M2 based on the first subkey derived from the authorization key and a preset initial vector value to obtain a padded target key. A number of padding bits corresponding to the type of the target key may be deleted from the padded target key to obtain the target key.
[0232] Optionally, the key user can decrypt M2 using the AES-128CBC decryption method, and remove the number of padding bits corresponding to the type of the target key from the padded target key to obtain the target key. The decryption formula of the target key is as follows:
[0233] KEY=DEC CBC，K1，IV＝0 (M2)
[0234] In the embodiment of the present application, the key user terminal analyzes the type of the target key when the integrity check passes, and obtains the target key based on the type of the target key. On the basis of ensuring that the target key has not been tampered with during transmission, by analyzing the type of the target key, different types of target keys can be decrypted, thereby improving the flexibility of key transmission.
[0235] After the key user burns the target key to the storage device, the present application also provides a process for the key user to load the target key. Figure 6 A flow chart of loading a target key provided in an embodiment of the present application is shown in FIG. Figure 6 As shown, the process includes:
[0236] S301: Read a target key from a storage device and verify the read target key.
[0237] Optionally, the key user may verify the read target key using any verification method, such as any one or more of a hash check, a cyclic redundancy check, an error checking and correcting (ECC) check, and an inverse code check.
[0238] For example, taking the example of a key user performing ECC and / or inverse code check on a target key, the key user can generate a check value for the target key and perform a comparison check during loading to complete the ECC check. The key user can check whether an error occurred during the loading process of the target key by comparing the inverse code check value of the target key with the actually calculated inverse code value to complete the inverse code check.
[0239] Optionally, the key user may only perform ECC check on the target key, or only perform inverse code check on the target key, or perform ECC check and inverse code check on the target key to perform multiple checks to ensure the accuracy and comprehensiveness of the check. This application does not limit this.
[0240] It should be understood that when multiple checks are used, if each check passes, the check is considered to have passed. If any check fails, the check is considered to have failed.
[0241] S302: If the verification passes, the target key is loaded into the key register.
[0242] Optionally, the key user may load all target keys into the key register at one time, or may load the target keys into the key register in segments, which is not limited in this application.
[0243] In some embodiments, the above process may also be referred to as the key register configuration process, which is equivalent and not limited to this. It should be understood that the embodiments of the present application focus on describing how to ensure the correctness of the key during the process of loading the key into the key register, and do not limit whether the key register configuration process includes other steps.
[0244] The embodiment of the present application can read the target key from the storage device and perform verification to ensure the correctness and integrity of the key. If the verification passes, the target key is securely loaded into the key register, effectively ensuring the accuracy and security of the key during the loading process and preventing security risks caused by key errors or tampering.
[0245] Based on the above embodiment, the embodiment of the present application can also determine whether the target key loading is successful based on the target key loading time. For example, if the target key loading is not completed when the preset time is reached, a first prompt message is output, and the first prompt message is used to indicate that the target key loading failed.
[0246] If the loading of the target key is completed within the preset time, a second prompt message is output, and the second prompt message is used to indicate that the loading of the target key is completed.
[0247] The embodiment of the present application can determine whether the target key loading is successful based on the target key loading duration, which is conducive to intuitive feedback on the progress of key loading and facilitates the key user to quickly respond to loading failures.
[0248] For example, Figure 7 A schematic diagram of a process for loading a key provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the process includes:
[0249] 41. The CSE configures a load key register, which may be a special function register (SFR).
[0250] 42. Determine whether the ECC check passes. If so, proceed to step 43. If not, proceed to step 46.
[0251] 43. Determine whether the inverse code check passes. If so, proceed to step 44. If not, proceed to step 46.
[0252] 44. Determine whether the OTP reading has timed out. If so, proceed to step 45. If not, proceed to step 46.
[0253] 45. Output verification prompt information, which is used to indicate that the CSE has successfully loaded the key.
[0254] 46. Output a verification prompt message, which indicates that the CSE failed to load the key.
[0255] The above is an embodiment of the method provided by this application. The device provided by this application is described below.
[0256] Figure 8 This is a structural diagram of a key processing device provided by this application, which is applied to the key sending end, such as Figure 8 As shown, the key processing device 400 provided in this embodiment includes:
[0257] The encryption module 401 is used to perform encryption operations on the target key to generate M1, M2, and M3 of the target key. Among them, M1 is used to indicate the type of the target key, M2 is used to indicate the encrypted target key, and M3 is used to indicate the signature information of the encrypted target key.
[0258] The sending module 402 is used to send a key burning request of the target key to the key user end. The key burning request includes: M1, M2 and M3, so that the key user end decrypts M2 based on the type of the target key parsed from M1 after passing the integrity check of M2 based on M3, obtains the target key, and burns the target key into the storage device.
[0259] Optionally, encryption module 401 is specifically configured to generate M1 based on identification information of the key user, identification information of the target key, and first information, where the first information indicates the type of the target key. Encrypt the target key to obtain M2. Generate M3 based on M1 and M2.
[0260] For example, encryption module 401 is specifically configured to concatenate the identification information of the key user, the identification information of the target key, and the first information to obtain M1. For example, encryption module 401 is specifically configured to pad the target key with a number of padding bits corresponding to the type of the target key to obtain a padded target key. The padded target key is encrypted based on a first subkey derived from the authorization key and a preset initialization vector value to obtain M2.
[0261] The key processing device 400 provided in this embodiment can execute the method provided by the key sending end in any of the above method embodiments. The implementation principles and technical effects thereof are similar and are not described in detail in this embodiment.
[0262] Figure 9 This is a structural diagram of a key processing device provided by this application, which is applied to the key sending end, such as Figure 9 As shown, the key processing device 500 provided in this embodiment includes: a receiving module 501 , a verification module 502 , a decryption module 503 , and a burning module 504 . Optionally, the device may further include a processing module 505 .
[0263] The receiving module 501 is configured to receive a key burning request for a target key. The key burning request includes: M1, M2, and M3. M1 indicates the type of the target key, M2 indicates the encrypted target key, and M3 indicates the signature information of the encrypted target key.
[0264] The verification module 502 is configured to perform integrity verification on M2 based on M3.
[0265] The decryption module 503 is configured to parse the type of the target key from M1 if the integrity check passes, and decrypt M2 based on the type of the target key to obtain the target key.
[0266] The burning module 504 is used to burn the target key into the storage device.
[0267] Optionally, the decryption module 503 is specifically configured to parse the first information from M1 based on the identification information of the key user and the identification information of the target key, and obtain the type of the target key based on a mapping relationship between the first information and the key type.
[0268] For example, the decryption module 503 is specifically configured to decrypt M2 based on the first subkey derived from the authorization key and the preset initial vector value to obtain a padded target key, and remove a number of padding bits corresponding to the type of the target key from the padded target key to obtain the target key.
[0269] Exemplarily, the burning module 504 is specifically configured to burn the target key into the one-time programmable memory. In one embodiment, the processing module 505 is configured to read the target key from the storage device and verify the read target key. If the verification passes, the target key is loaded into the key register.
[0270] For example, processing module 505 is specifically configured to perform ECC check and / or inverse code check on the target key. In one embodiment, processing module 505 is further configured to output a first prompt message if the target key loading is not completed before the preset time period has expired, the first prompt message being used to indicate that the target key loading has failed. If the target key loading is completed within the preset time period, a second prompt message is output, the second prompt message being used to indicate that the target key loading is complete.
[0271] The key processing device 500 provided in this embodiment can execute the method provided by the key user end in any of the above method embodiments. The implementation principles and technical effects are similar and will not be described in detail in this embodiment.
[0272] Figure 10 This is a structural diagram of an electronic device provided by this application. For example, the electronic device can be the key burning control terminal, or the key burning host computer. Figure 10 As shown, the electronic device 600 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 600 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.
[0273] During the specific implementation process, at least one processor 601 executes the computer-executable instructions stored in the memory 602, so that the at least one processor 601 performs the above method.
[0274] The specific implementation process of the processor 601 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.
[0275] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly implemented by a hardware processor or implemented by a combination of hardware and software modules in the processor.
[0276] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk memory.
[0277] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified into address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.
[0278] The present application also provides a hardware security module, including a memory, a processor, and an encryption accelerator; the encryption accelerator is used to perform verification and decryption operations during the key burning process; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the processor executes any one of the above-mentioned key usage methods.
[0279] The present application also provides a control unit, which includes the above-mentioned hardware security module.
[0280] The present application also provides a vehicle, which includes the above-mentioned control unit.
[0281] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.
[0282] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.
[0283] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.
[0284] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.
[0285] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.
[0286] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0287] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0288] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.
[0289] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0290] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.
Claims
1. A key processing method, characterized in that: The method comprises: Performing an encryption operation on the target key to generate M1, M2, and M3 of the target key; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key; A key burning request for a target key is sent to a key user, where the key burning request includes M1, M2, and M3, so that the key user, after passing an integrity check on M2 based on M3, decrypts M2 based on the type of the target key parsed from M1, obtains the target key, and burns the target key into a storage device.
2. The method according to claim 1, characterized in that The step of performing encryption operation on the target key to generate M1, M2 and M3 of the target key includes: Generate M1 based on identification information of the key user, identification information of the target key, and first information, wherein the first information is used to indicate a type of the target key; Encrypting the target key to obtain M2; Based on the M1 and the M2, the M3 is generated.
3. The method according to claim 2, characterized in that The generating of M1 based on the identification information of the key user, the identification information of the target key, and the first information includes: The identification information of the key user, the identification information of the target key, and the first information are concatenated to obtain M1.
4. The method according to claim 2, characterized in that The encrypting the target key to obtain M2 includes: Filling the target key with a number of padding bits corresponding to the type of the target key to obtain a padded target key; The padded target key is encrypted based on a first subkey derived from the authorization key and a preset initial vector value to obtain M2.
5. A key processing method, characterized in that: include: Receive a key burning request for a target key, the key burning request including: M1, M2, and M3; wherein, M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key; Based on M3, perform integrity check on M2; If the integrity check passes, the type of the target key is parsed from M1, and based on the type of the target key, M2 is decrypted to obtain the target key; Burn the target key into a storage device.
6. The method according to claim 5, characterized in that The parsing of the type of the target key from M1 includes: Parsing first information from M1 based on the identification information of the key user and the identification information of the target key; Based on the mapping relationship between the first information and the key type, the type of the target key is obtained.
7. The method according to claim 5, characterized in that The decrypting M2 based on the type of the target key to obtain the target key includes: Decrypting M2 based on a first subkey derived from the authorization key and a preset initial vector value to obtain a padded target key; A number of padding bits corresponding to the type of the target key is deleted from the padded target key to obtain the target key.
8. The method according to any one of claims 5 to 7, characterized in that: Burning the target key into a storage device includes: The target key is burned into a one-time programmable memory.
9. The method according to any one of claims 5 to 7, characterized in that: The method further comprises: Reading the target key from the storage device and verifying the read target key; If the verification is successful, the target key is loaded into the key register.
10. The method according to claim 9, characterized in that The verifying the target key includes: Perform ECC check and / or inverse code check on the target key.
11. The method according to claim 9, characterized in that The method further comprises: If the loading of the target key is not completed when the preset time is reached, output a first prompt message, where the first prompt message is used to indicate that the loading of the target key has failed; If the loading of the target key is completed within the preset time period, a second prompt information is output, where the second prompt information is used to indicate that the loading of the target key is completed.
12. A key processing device, characterized in that: The device is applied to a key sending end, and includes: An encryption module, configured to perform encryption operation on a target key to generate M1, M2, and M3 of the target key; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate signature information of the encrypted target key; The sending module is used to send a key burning request of a target key to a key user end, wherein the key burning request includes: M1, M2 and M3, so that the key user end decrypts M2 based on the type of the target key parsed from M1, obtains the target key, and burns the target key into a storage device when the integrity check of M2 passes based on M3.
13. A key processing device, characterized in that: The device is applied to a key user end, and includes: A receiving module, configured to receive a key burning request for a target key, wherein the key burning request includes: M1, M2, and M3; wherein M1 is used to indicate the type of the target key; M2 is used to indicate the encrypted target key; and M3 is used to indicate the signature information of the encrypted target key; A verification module, configured to perform integrity verification on M2 based on M3; a decryption module, configured to parse the type of the target key from M1 if the integrity check passes, and decrypt M2 based on the type of the target key to obtain the target key; The burning module burns the target key into a storage device.
14. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 4.
15. A hardware security module, characterized in that: include: Memory, processor, encryption accelerator; The encryption accelerator is used to perform verification and decryption operations during the key burning process; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 5 to 11.
16. A control unit, characterized in that: The control unit includes the hardware security module according to claim 15.
17. A vehicle, characterized in that: The vehicle comprises a control unit as claimed in claim 16.
18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 11 when executed by a processor.
19. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 11 when being executed by a processor.