WO2023000313A1 - 一种密钥验证方法及相关装置 - Google Patents

一种密钥验证方法及相关装置 Download PDF

Info

Publication number
WO2023000313A1
WO2023000313A1 PCT/CN2021/108185 CN2021108185W WO2023000313A1 WO 2023000313 A1 WO2023000313 A1 WO 2023000313A1 CN 2021108185 W CN2021108185 W CN 2021108185W WO 2023000313 A1 WO2023000313 A1 WO 2023000313A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
information
verification
integrity
ecu
Prior art date
Application number
PCT/CN2021/108185
Other languages
English (en)
French (fr)
Inventor
段立
耿峰
李�泳
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2021/108185 priority Critical patent/WO2023000313A1/zh
Priority to CN202180100210.6A priority patent/CN117597688A/zh
Publication of WO2023000313A1 publication Critical patent/WO2023000313A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the embodiments of the present application relate to the field of information security, and in particular, to a key verification method and a related device.
  • Information security is a prerequisite for autonomous driving.
  • various function keys can be used to protect the information security of the vehicle.
  • the security onboard communication (SecOC) key (SecOC key) can be used to protect the security of the vehicle communication network
  • the device key (device key) for device authentication can also be used to ensure the authenticity of the device Wait.
  • the embodiment of the present application discloses a key verification method and a related device, which can realize the integrity verification of the authentication key, thereby ensuring the normal use of the function key and the information security of the entire vehicle.
  • a key verification method which can be executed by an electronic control unit or a chip configured in the electronic control unit.
  • the method includes: receiving first information through the client, the first information is from a key management entity, the first information indicates the first key through the information of the second key, and the second key is configured with For authenticating at least one function key of the first electronic control unit, the at least one function key corresponds to at least one business function of the first electronic control unit; receiving a first verification parameter from the client; according to the first The second key and the first verification parameter are used to generate first verification information, and the first verification information is used to characterize the integrity of the first key; and the first verification information is sent to the client.
  • the method may also be executed by a functional component including an electronic control unit or a chip configured in the functional component.
  • the functional component is a domain controller including one or more electronic control units.
  • the integrity of the first key can be passed Indirectly verify the integrity of the second key to ensure the integrity and security of the second key, thereby ensuring the normal use of the function key and the information security of the entire vehicle.
  • the first information indicates the first key through the information of the second key and the first information is forwarded by the client to the first electronic control unit through the key management entity, it is avoided that the second key is transmitted in plain text. The form is exposed outside the key management entity and the electronic control unit, thereby ensuring the security of the core assets of the vehicle factory.
  • the method further includes: receiving fifth information from the client, the fifth information is from a key management entity, and the fifth information is passed through a fifth The information of the key indicates the second key, wherein the fifth key is used to authenticate the second key.
  • the second key can be written into the first electronic control unit through the fifth information first, which can satisfy the requirement that the maintenance party authorized by the vehicle production line and/or the vehicle factory write the second key into the first electronic control unit correctly.
  • the requirements of the electronic control unit and then provide authentication conditions for the writing of the subsequent function key, to ensure the normal use of the function key and the information security of the whole vehicle.
  • the method further includes: generating ninth information according to the first information and the challenge-response mechanism, the ninth information including Information about key integrity; sending the ninth information to the client.
  • the ninth information generated based on the challenge-response mechanism can realize the integrity verification of the first key, which simplifies the verification process and improves the verification efficiency.
  • the method further includes: generating tenth information according to the fifth information and the challenge-response mechanism, the tenth information includes Two key integrity information; sending the tenth information to the client.
  • the tenth information generated based on the challenge-response mechanism can realize the integrity verification of the second key, which simplifies the verification process and improves the verification efficiency.
  • the first verification information includes information obtained by using the first key to protect the integrity of the first verification parameter. Since the first information indicates the first key through the information of the second key, only when the second key locally stored by the first electronic control unit is consistent with the second key stored by the key management entity, the first The key can be correctly written into the first electronic control unit based on the first information. Based on this, the indirect verification of the integrity of the second key can be implemented by using the information obtained by performing integrity protection on the first verification parameter with the first key.
  • a key verification method which can be executed by a key management entity or a chip configured in the key management entity.
  • the method includes: generating first information and second authentication information, the first information indicating the first key through information of a second key configured to authenticate at least A function key, the at least one function key corresponds to at least one service function of the first electronic control unit, and the second verification information includes information for integrity verification of the first key;
  • the terminal sends the first information and the second verification information.
  • the key management entity includes a key management server (key management server, KMS).
  • KMS key management server
  • the writing of the first key can be realized by sending the first information indicating the first key and the second verification information that can be used for integrity verification of the first key to the client and verification of the integrity of the first key. Furthermore, since the first information indicates the first key through the information of the second key, the integrity of the second key can be indirectly verified by verifying the integrity of the first key, thereby ensuring the security of the second key. On the other hand, since the first information is sent to the client by the key management entity and the first information indicates the first key through the information of the second key, it is avoided that the second key is exposed in the encrypted form in plain text. In addition to the key management entity and electronic control unit, it ensures the security of the core assets of the vehicle factory.
  • indirectly verifying the integrity of the second key through the integrity of the first key does not need to rely on the identification information of the electronic control unit, so the entire vehicle production line does not need to collect all target electronic control units for which the second key is to be updated in advance identification information, reducing the burden on the vehicle production line and management costs.
  • the key management entity can also prepare the information (such as the first information and the second verification information) used for the integrity verification of the first key in advance, and send it to the client in advance.
  • the off-line verification of the authentication key (that is, the second key) of the electronic control unit can realize the real-time verification of the integrity of the second key even if it does not depend on the KMS, reducing time overhead.
  • the second verification information includes the first key, so that the client determines the local verification information according to the first key combined with locally generated first verification parameters , wherein, the local verification information can be used for the integrity verification of the first key and/or the second key; or, the second verification information includes a second verification parameter, and through the first The key performs integrity protection on the second verification parameter to obtain information.
  • the method further includes: sending fifth information to the client, where the fifth information indicates that the second key is , wherein the fifth key is used to authenticate the second key.
  • the writing of the second key can be realized, thereby satisfying the requirements of the vehicle production line and/or the maintenance party authorized by the vehicle factory to correctly write the second key into the first electronic control unit, and then provide the subsequent functions
  • the writing of the key provides authentication conditions to ensure the normal use of the function key and the information security of the vehicle.
  • this solution can be adapted to various scenarios where the second key is to be written. Through a unified solution adapted to various scenarios, the key management process of the key management entity or the vehicle factory can be simplified, and the encryption key can be simplified. Key writing process.
  • the method further includes: receiving second key update request information from the client, where the second key update request information is used to request to update the The second key, or used to request to verify the integrity of the second key stored locally by the first electronic control unit.
  • the method further includes: receiving an update result of the second key from the client.
  • the update status of the second key can be known, and then it can be judged whether the function key can be written, so as to ensure the normal use of the function key and the information security of the whole vehicle.
  • a key verification method which can be executed by a client or a chip configured in the client.
  • the method includes: receiving first information from a key management entity; sending the first information to the first electronic control unit, the first information indicating the first key through the information of the second key, the second The key is configured to authenticate at least one function key of the first electronic control unit, and the at least one function key corresponds to at least one business function of the first electronic control unit; Sending a first verification parameter, where the first verification parameter is used to verify the integrity of the first key; receiving first verification information from the first electronic control unit, where the first verification information is used to characterize the the integrity of the first key; determine the integrity of the second key according to the local verification information and the first verification information, wherein the local verification information includes pairing the second key with the first key A verification parameter for integrity protection of the resulting information.
  • the client includes an OEM key flashing device, or a dealer diagnostic instrument.
  • the client as an intermediary between the key management entity and the first electronic control unit, can forward the first information of the future key management entity to the first electronic control unit, and then realize that the first key is stored in the first electronic control unit.
  • the writing on the side of the electronic control unit indirectly realizes the verification of the integrity of the second key by verifying the integrity of the first key according to the local verification information. Since the first information indicates the first key through the information of the second key, it is ensured that the second key is not exposed outside the key management entity and the electronic control unit in plain text, thereby ensuring that the core assets of the vehicle factory safety.
  • the integrity verification of the second key is realized through the client as an intermediary, which is simple to implement and is suitable for vehicle production line assembly, after-sales maintenance scenarios, and component developer key flashing scenarios, thereby reducing key management Administrative costs for entities or OEMs.
  • the first verification parameter comes from the key management entity, for example, it corresponds to the second verification parameter from the key management entity, that is, the client will receive a verification parameter from the key management entity
  • the second verification parameter is forwarded to the first electronic control unit for verifying the integrity of the first key; or, the first verification parameter includes information generated by the client.
  • the local verification information comes from the key management entity, for example, corresponding to the integrity check of the second verification parameter through the first key from the key management entity Protect the obtained information; or the local authentication information is information determined by the client.
  • determining the integrity of the second key according to the local verification information and the first verification information includes: if the local verification information is consistent with the first If the verification information matches, it is determined that the second key is complete; or, if the local verification information does not match the first verification information, it is determined that the second key is incomplete.
  • the client can realize the judgment on the integrity of the second key, and then judge whether the function key can be written, so as to ensure the normal use of the function key.
  • the method further includes: sending fifth information to the first electronic control unit, where the fifth information indicates that the A second key, wherein the fifth key is used to authenticate the second key.
  • the method further includes: sending ninth information from the first electronic control unit to the key management entity, where the ninth information includes information for verifying the integrity of the first key; the client does not parse the ninth information.
  • the key management entity can obtain the integrity verification result of the first key, and the client can ensure the security of the first key without parsing the ninth information, thereby simplifying the operation of the client.
  • the method further includes: sending tenth information from the first electronic control unit to the key management entity, where the tenth information includes information used to verify the integrity of the second key; the client does not parse the tenth information.
  • the key management entity can obtain the integrity verification result of the second key, and the client can ensure the security of the first key without parsing the tenth information, thereby simplifying the operation of the client.
  • the method further includes: sending second key update request information to the key management entity, where the second key update request information is used to request updating the second key, or requesting to verify the integrity of the second key stored locally by the first electronic control unit.
  • the key management entity can be assisted to generate information suitable for the second key update or the integrity verification of the second key through the second key update request information, thereby realizing the integrity verification of the second key , to ensure the normal use of the function key and the information security of the entire vehicle.
  • the method further includes: sending an update result of the second key to the key management entity.
  • the key management entity can be assisted to know the update status of the second key, and then judge whether the function key can be written, so as to ensure the normal use of the function key and the information security of the whole vehicle.
  • the second key update request information includes one or more of the following information: identity authentication of the client Information, the number of electronic control units to be updated with the second key, the identification code of the vehicle to which the electronic control unit belongs, the version number of the authentication key locally stored by the electronic control unit, and the version number of the electronic control unit.
  • the identity authentication information of the client is used to indicate that the client has the authority to obtain key writing information from the key management entity, where the key writing information includes the following One or more items of information: the first information, the fifth information, and the second verification information.
  • the second key update request information includes one or more of the following information: the number of electronic control units to be updated with the second key, the identification code of the vehicle to which the electronic control unit belongs, the electronic control
  • the version number of the authentication key stored locally by the unit and the version number of the electronic control unit also facilitate the key management entity to determine the second key to be written, and realize the batch writing of the second key and/or the second key batch integrity verification, reducing the cost of key management.
  • the update result of the second key includes one or more of the following: the integrity of the second key information, the identity of the first electronic control unit, and the integrity information of the first key, wherein the identity of the first electronic control unit is used to uniquely identify the first electronic control unit.
  • the key management entity can determine whether the second key is written into the first electronic control unit and/or determine the authentication key stored locally by the first electronic control unit based on the update result of the second key Whether it is the second key, so as to ensure the normal use of the function key and the information security of the whole vehicle.
  • the key management entity can collect the identity of the first electronic control unit, it is also convenient for the key management entity to manage the electronic control unit that writes the second key.
  • the first information includes Encryption and/or integrity protection of the resulting information.
  • the first information includes: at least through the identity of the first electronic control unit information, the second information obtained by concatenating the index of the first key and the index of the second key, the third information obtained by encrypting the first key with the third key, and the fourth information obtained by encrypting the first key with the third key a key, fourth information obtained by performing integrity protection on information concatenated with at least the second information and the third information, wherein the third key and the fourth key are the first The derived key of the second key.
  • the fifth information includes Encryption and/or integrity protection of the resulting information.
  • the second key can be written into the first electronic control unit under the condition that the security of the second key is ensured.
  • the fifth information includes: at least through the identity of the first electronic control unit
  • the sixth information obtained by concatenating information, the index of the second key and the index of the fifth key, the seventh information obtained by encrypting the second key with the sixth key, and the seventh information obtained by encrypting the second key with the sixth key
  • the key is eighth information obtained by performing integrity protection on at least the concatenated information of the sixth information and the seventh information, wherein the sixth key and the seventh key are the fifth The key's derived key.
  • the second key can be written into the first electronic control unit, and the implementation is simple.
  • the identity information of the first electronic control unit includes the first electronic control unit ID of the first electronic control unit or the group ID of the first electronic control unit, wherein the ID of the first electronic control unit is used to uniquely identify the first electronic control unit; the group ID of the first electronic control unit is used for is used to identify the device group to which the first electronic control unit belongs.
  • the group identifier of the first electronic control unit contains at least one wildcard.
  • the key management entity based on the group identifier of the first electronic control unit, it is possible for the key management entity to write in batches the first key and/or the second key of multiple electronic control units, and complete the second key Unique batch verification, simplifying the process and saving costs; based on the identity of the first electronic control unit, point-to-point writing of the first key and/or second key and verification of the integrity of the second key can be realized .
  • a control device in a fourth aspect, includes a unit or module for performing the method in any possible implementation manner of the above-mentioned first aspect, or for performing any of the above-mentioned second aspects
  • a control device includes a processor and a memory.
  • the memory is used to store computer programs or instructions
  • the processor is used to call the computer programs or instructions in the memory, so that the control device executes the method in any possible implementation manner of the first aspect above , or for executing the method in any possible implementation manner of the above-mentioned second aspect, or for executing the method in any possible implementation manner of the above-mentioned third aspect.
  • control device further includes a communication interface, the communication interface is coupled with the processor, and the communication interface is used to input and/or output information, the information includes, for example, one or more of the following information Item: the first information, the fifth information, the first authentication parameter, the first authentication information, the second authentication information, the second key update request information, the second encryption key update result.
  • processors there are one or more processors, and one or more memories.
  • the memory may be integrated with the processor, or the memory may be separated from the processor.
  • control device for performing the method in any possible implementation manner of the first aspect above may be an electronic control unit or include one or more electronic The domain controller that controls the cell.
  • an electronic component in a sixth aspect, includes a control device for realizing the method in any possible implementation manner of the above first aspect.
  • the electronic component includes an ECU.
  • a vehicle in a seventh aspect, includes a control device for implementing the method in any possible implementation manner of the first aspect above, or the vehicle includes the electronic component provided in the sixth aspect above.
  • a key management entity which can implement the method in any possible implementation manner of the above-mentioned second aspect.
  • the key management entity may be a key management server.
  • a ninth aspect provides a key flashing tool, which can implement the method in any possible implementation manner of the third aspect above.
  • the key flashing tool may be an OEM key flashing tool or a dealer diagnostic instrument.
  • a tenth aspect provides a system, the system includes the electronic component provided in the sixth aspect above, the vehicle provided in the seventh aspect above, the key management entity provided in the eighth aspect above, or the key provided in the ninth aspect above One or more of the flash tools.
  • a system in an eleventh aspect, includes a control device configured to execute the method in any possible implementation manner of the above-mentioned first aspect, and configured to execute any possible implementation manner of the above-mentioned second aspect
  • a control device configured to execute the method in any possible implementation manner of the above-mentioned first aspect, and configured to execute any possible implementation manner of the above-mentioned second aspect
  • a chip in a twelfth aspect, includes one or more processors and an interface circuit, the interface circuit is used to provide information input and/or output for the one or more processors, the The chip is used to execute the method in any possible implementation manner of the above-mentioned first aspect, or to execute the method in any possible implementation manner of the above-mentioned second aspect, or to execute any one of the above-mentioned third aspect Methods in Possible Implementations.
  • a computer-readable storage medium is provided, and a computer program or instruction is stored in the computer-readable storage medium, and when the computer program or instruction is executed by a processor, the processor executes the above-mentioned
  • the method in any possible implementation of the first aspect, or the method in any possible implementation of the second aspect above, or the method in any possible implementation of the third aspect above method.
  • a computer program product is provided, and when the computer program product is run on one or more processors, the one or more processors are made to perform any possible implementation of the first aspect above
  • FIG. 1 is a network architecture of a possible key verification method provided by an embodiment of the present application
  • FIG. 2 is a schematic flow chart of a possible key verification method provided by an embodiment of the present application.
  • FIG. 3 is a schematic flow chart of a possible key writing method provided by an embodiment of the present application.
  • FIG. 4 is a schematic flowchart of a possible method for implementing a key update request and a key update result provided by an embodiment of the present application
  • FIG. 5 is a schematic flowchart of a possible method for implementing key verification information provided by an embodiment of the present application
  • FIG. 6 is a schematic flowchart of another possible method for realizing key verification information provided by the embodiment of the present application.
  • Fig. 7 is a schematic diagram of a possible control device provided by the embodiment of the present application.
  • Fig. 8 is a schematic diagram of another possible control device provided by the embodiment of the present application.
  • FIG. 9 is a schematic diagram of a possible chip structure provided by an embodiment of the present application.
  • At least one (unit) refers to one (unit) or multiple (units), and “multiple (units)” refers to two (units) or two (units) above.
  • At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items.
  • at least one item (piece) of a, b, or c may represent: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, c can be single or multiple.
  • the embodiments of the present application use ordinal numerals such as "first" and "second" to distinguish multiple objects, and are not used to limit the order, timing, priority or importance of multiple objects degree.
  • first information and the second information are only for distinguishing different information, and do not indicate the difference in content, priority, sending order, or degree of importance of the two kinds of information.
  • ECU Electronic Control Unit
  • the electronic control unit ECU can also be called the on-board controller, which can be used to control various functions in the use of the whole vehicle.
  • the ECU may include but not limited to: an ECU with an engine control function, an ECU with a handle control function, and an ECU with a brake control function.
  • the ECU can also be understood as an electronic unit having integrity protection function and encryption function and including secure memory.
  • the secure memory can be implemented based on non-volatile memory (non-volatile memory, NvM).
  • NvM non-volatile memory
  • the secure memory has a strict access control mechanism to control the reading and use of key key material.
  • the secure memory is, for example, a secure storage area in an automotive open system architecture (automotive open system architecture, AUTOSAR) secure hardware extension (secure hardware extension, SHE).
  • the name of the electronic unit with similar functions to control the use of the whole vehicle may not be called ECU, and the electronic unit with integrity protection function and encryption function and including secure memory
  • the name of the unit may not be called ECU, but for the convenience of description, in the embodiment of the present application, the electronic units that control various functions in the use of the vehicle are collectively referred to as ECU, which will have integrity protection functions and encryption functions and include security
  • the electronic unit of memory is also collectively referred to as ECU.
  • the authentication key is used for the authentication of the function key, and the writing and/or integrity verification of the function key can only be realized if the electronic control unit ECU has the correct authentication key. Based on this, the authentication key can also be understood as the authentication key of the function key or the authorization key of the function key. Exemplarily, the ECU has the correct authentication key. It can be understood that the authentication key stored locally by the ECU is the same as the authentication key stored locally by the KMS.
  • the authentication key can also be used to authenticate the hardware function key of the ECU in addition to the authentication of the function key, wherein the hardware function key can also be used for the authentication of the function key.
  • the authentication key may be used to authenticate a key corresponding to a subsequent version of the authentication key (as an example of a hardware function key).
  • the electronic control unit ECU can only realize the writing and/or integrity verification of the new version of the MEK only if it has the correct previous version of the MEK.
  • the authentication key can also be understood as the authentication key of the ECU hardware function key or the authorization key of the ECU hardware function.
  • the authentication key can correspond to all the complete vehicles included in a model, or it can correspond to a complete vehicle, or it can also correspond to a functional component in the complete vehicle, or it can correspond to an ECU in the complete vehicle.
  • a model All included vehicles have the same authentication key, and vehicles of different models have different authentication keys, or one vehicle has one authentication key, and different vehicles have different authentication keys, or, One functional component in the vehicle has one authentication key, and other functional components in the vehicle have other authentication keys, or, one ECU in the vehicle has one authentication key, and different ECUs have different authentication keys.
  • the functional components here may include functional components composed of multiple ECUs, for example, functional components for cockpit control composed of multiple ECUs.
  • the ECU master key MEK may also be referred to as an ECU hardware authority key.
  • the function key can also be called the service key, which can be used to encrypt the ECU key of various functions in the vehicle, so as to ensure the security of the computer system of the vehicle.
  • the function key may include but not limited to: a pre-shared key (pre-shared key, PSK), a master key (master key, MK) for business applications, and a session key (session key, SK).
  • the PSK may include a security onboard communication (SecOC) key (SecOC key) for protecting vehicle network communication security and a device key (device key) for device authentication.
  • the function key can be allocated based on one vehicle and one service.
  • one or more ECUs used for the same service may share the same function key.
  • the ECUs of the same service can be different.
  • the ECUs that communicate with each other can encrypt and decrypt messages based on the same function key, so as to achieve encryption and integrity protection for messages.
  • the multiple ECUs can also share the same function key. Any one of the plurality of ECUs authenticates other ECUs of the service based on the function key.
  • the functional key used for board-side encrypted communication and the functional key used for device authentication are keys for different services, and therefore are different keys.
  • board-side encrypted communication and device authentication can be understood as different services.
  • the function key can also be distributed on a finer granularity basis.
  • the function key can be allocated based on a complete vehicle, a service, and a pair of ECUs. For example, if multiple ECUs are used for the same service, every two ECUs among the multiple ECUs can form a pair of ECUs. Each pair of ECUs can share a function key.
  • the plurality of ECUs include ECU-1, ECU-2 and ECU-3.
  • the same function key can be shared between ECU-1 and ECU-2, such as function key 1; another function key can be shared between ECU-2 and ECU-3, such as function key 2;
  • the function key can be shared between ECU-1 and ECU-3, for example, it is marked as function key 3.
  • Message authentication code (message authentication code, MAC)
  • MAC Message Authentication Code
  • the sender first calculates the MAC by using the integrity protection algorithm (or also includes the key) negotiated by the communication parties. Afterwards, the MAC is sent along with the data. After receiving the message, the receiver uses the same integrity protection algorithm (or key) as the sender to calculate the MAC, and compares whether the MAC calculated by itself is consistent with the received MAC. If the two are consistent, the message passes the integrity verification.
  • the MAC may be generated by an integrity protection algorithm, and the integrity protection algorithm may also be called a MAC algorithm or a complete protection algorithm.
  • the integrity protection algorithm includes at least the following three algorithms: (1) key generation algorithm, used to generate a label calculation key and a verification key, and the label calculation key can be the same as the verification key (if used different from the key of the message authentication code), or different (such as the key used for digital signature); (2) the label calculation algorithm, which takes the label calculation key and the information to be protected as input, and generates the key corresponding to the The protection label of the information to be protected; (3) the verification algorithm, which takes the verification key, the label calculation key, and the information to be protected as input, and outputs a logical truth value if and only when the verification passes.
  • the integrity protection algorithm group needs to satisfy at least the following two properties.
  • Correctness that is, the protection label generated by using the label calculation key and the label calculation algorithm must be verified as true by the verification key and the verification algorithm.
  • Unforgeability that is, if the attacker does not have the label calculation key, he cannot forge the label for the information to be protected with a non-negligible probability.
  • the integrity protection algorithm implemented based on the hash algorithm is called a hash-based message authentication code (hash-based message authentication code, HMAC) algorithm, wherein the hash algorithm can be MD5, SHA-1, One of SHA-256, or other implementations, is not specifically limited.
  • HMAC hash-based message authentication code
  • HMAC hash-based message authentication code
  • the MAC algorithm implemented based on a cryptographic algorithm can be called a Cipher-based Message Authentication Code (CMAC) algorithm, in which the block encryption algorithm can be Advanced Encryption Standard (AES), Since the working mode of AES packet encryption includes but is not limited to ECB, CBC, CFB, OFB, the integrity protection algorithm based on the block encryption algorithm of different working modes can be called respectively: ECB-MAC algorithm, CBC-MAC algorithm, CFB -MAC algorithm, OFB-MAC algorithm.
  • the integrity protection algorithm may also include Galois message authentication code mode (GMAC), Zu Chongzhi cryptographic algorithm (such as ZUC128, ZUC256, etc.).
  • GMAC Galois message authentication code mode
  • Zu Chongzhi cryptographic algorithm such as ZUC128, ZUC256, etc.
  • the integrity protection algorithm may have other forms, which are not specifically limited.
  • Encryption algorithms include symmetric encryption algorithms and asymmetric encryption algorithms.
  • the encryption key of the symmetric encryption algorithm is the same as the decryption key, and the encryption key of the asymmetric encryption algorithm is different from the decryption key.
  • Common symmetric encryption algorithms include but are not limited to: data encryption standard (data encryption standard, DES), triple data encryption algorithm (triple data encryption algorithm, 3DES), AES; common asymmetric algorithms include but are not limited to: RSA encryption algorithm.
  • the authenticated encryption algorithm can either encrypt data or generate a message authentication code for a given original text, so the authenticated encryption algorithm can be used as both an encryption algorithm and a complete security algorithm.
  • the AES algorithm AES-Galois/Counter Mode, AES-GCM
  • the AES algorithm AES-CMAC/Counter Mode, AES-CCM
  • Authenticated encryption, and MAC can be generated in the process of authenticated encryption to protect the integrity of the message.
  • Hash algorithms include but are not limited to: secure hash algorithm (secure hash algorithm 1, SHA-1), message digest (message digest, MD) algorithm (such as MD2, MD4 or MD5).
  • Key derivation is the process of deriving one or more keys from a key, and the algorithm used to derive keys is called key derivation function (KDF), also known as key derivation algorithm.
  • KDF key derivation function
  • key derivation algorithms include but are not limited to: password-based key derivation function (password-based key derivation function, PBKDF), Script (scrypt) algorithm.
  • the PBKDF algorithm includes the first generation PBKDF1 and the second generation PBKDF2.
  • the description will be described using "the first KDF”, “the second KDF” and “the third KDF”.
  • the first KDF, the second KDF and the third KDF can be different KDFs or the same KDF.
  • the challenge-response mechanism is a mode in the authentication protocol.
  • An authentication protocol that implements a challenge-response mechanism usually includes two parties.
  • the challenger (challenger) is usually the party that needs to verify the identity of the other party, and the responder (responder) is the party that needs to self-certify the identity.
  • the principle of the challenge-response mechanism is as follows: the challenger sends a challenge to the responder, and the responder determines the corresponding response based on the locally stored authentication information (or secret authentication information) and the challenge and sends it to the challenger.
  • the challenger combines the challenge with its own verification information to verify whether the responder has passed the challenge, and/or judge whether the responder should be authenticated.
  • the challenger may take information containing fresh random character strings or information containing pseudo-random character strings as a challenge.
  • FIG. 1 is a network architecture of a possible key verification method provided by an embodiment of the present application.
  • the network architecture 100 may include a key management server, an OEM key flashing device (also referred to as an OEM tool (OEM tool)), a complete vehicle and an ECU.
  • OEM tool also referred to as an OEM tool (OEM tool)
  • ECU ECU
  • a local connection such as a local area network, directly connected to the hardware (such as the key flashing device and the ECU directly
  • a secure connection protocol such as a transport layer security specification (TLS) or a virtual private network (VPN)
  • the above-mentioned OEM may specifically refer to a complete vehicle manufacturer or an OEM.
  • Fig. 1 is only for ease of understanding, showing the key writing/verification process used in the vehicle production line, but this should not constitute any limitation to the present application.
  • the key writing/verification method provided in this application can also be applied to after-sales service, such as the key update process for after-sales service.
  • the OEM key flashing device in Figure 1 can be replaced by a dealer diagnostic instrument (also called a dealer diagnostic tool (tester tool)).
  • the aforementioned KMS dealer diagnostic instruments, and between the dealer diagnostic instruments and the ECU can also communicate through a local connection or a secure connection.
  • the hardware structures of the OEM server and the dealer server may be similar.
  • the functions of the OEM key flashing device and the dealer's diagnostic instrument are similar, but the application scenarios are different. Therefore, the hardware structure of the OEM key flashing device and the dealer's diagnostic instrument may also be similar.
  • the KMS further includes a KMS front server and a KMS background server.
  • the KMS front-end server is mainly responsible for communicating with the outside world, which can be understood as the interface between the KMS back-end server and the outside world.
  • the KMS background server is mainly responsible for key generation, key lookup, etc.
  • the KMS front-end server and the KMS back-end server can be two physically independent devices, or can be integrated into the same physical device. This embodiment of the present application does not limit it.
  • FIG. 1 two vehicles are shown in FIG. 1 with one or more ECUs deployed in each vehicle.
  • the present application does not limit the number of vehicles in the network architecture and the number of deployed ECUs.
  • MEK as an example of an authentication key. It should be understood that the MEK can also be replaced by other authentication keys.
  • MEK Due to the key properties of MEK (for example, MEK is used as the authentication key or authority key for the function key included in the whole vehicle), MEK can be considered as the core asset of the original equipment manufacturer (OEM), so MEK is prohibited It is leaked to third parties (such as component developers, OEM authorized dealers, and after-sales 4S stores) in the form of plain text, and is not allowed to be exposed outside KMS. Based on this, the existing OEMs write MEK into the electronic control unit under the environment of safety monitoring. In the absence of security monitoring (for example, when implementing remote key flashing), the security of MEK cannot be guaranteed, and there is a risk of tampering.
  • OEM original equipment manufacturer
  • an embodiment of the present application provides a method for key verification.
  • the client receives the first information from the key management entity, and sends the first information to the first electronic control unit.
  • the first The information indicates the first key by information of the second key configured to authenticate at least one functional key of the first electronic control unit, the at least one functional key corresponding to the first electronic control unit at least one service function; the client also sends a first verification parameter to the first electronic control unit, where the first verification parameter is used to verify the integrity of the first key.
  • the first electronic control unit receives the first information and the first verification parameter from the client, and generates first verification information according to the second key and the first verification parameter, and the first verification information is used to characterize the first Integrity of the key; the first electronic control unit sends the first verification information to the client.
  • the client receives the first verification information, and determines the integrity of the second key according to the first verification information and local verification information.
  • the second key can be indirectly verified through the integrity of the first key
  • the integrity of the second key is guaranteed to ensure the integrity and security of the second key, preventing the second key from being tampered with, thereby ensuring the normal use of the function key and the information security of the entire vehicle.
  • the first information indicates the first key through the information of the second key and the first information is forwarded by the client to the first electronic control unit through the key management entity, it is avoided that the second key is transmitted in plain text The form is exposed outside the key management entity and the electronic control unit, thereby ensuring the security of the core assets of the vehicle factory.
  • verifying the key may include verifying the integrity of the key, or may be understood as performing integrity verification on the key.
  • verifying the integrity of the key may include verifying whether the key is completely written into the ECU, or whether it is correctly written into the ECU. Specifically, for example, if the storage area of the ECU includes the key that has not been tampered with, it may indicate that the key has been correctly written or completely written into the ECU.
  • the keys here include function keys (such as SecOC key, device key) and/or authentication keys (such as MEK).
  • FIG. 2 is a schematic flowchart of a possible key verification method provided by an embodiment of the present application. Further, the method can be implemented based on the architecture in FIG. 1 . The method can include:
  • a key management entity generates first information and second verification information.
  • the key management entity is used to manage the key.
  • the key management entity may implement one or more of the following functions: key generation, authorized use of the key, and deregistration management of the key.
  • the keys here include various keys used in the vehicle, such as function keys and authentication keys, as well as other forms of keys such as temporary keys used in the key flashing process.
  • the key management entity may be KMS, and further, the KMS is managed by the OEM, thereby ensuring the security of various keys used in the vehicle; or, the key management entity may also be a
  • the OEM server, or the key management entity can also be an OEM, or the key management entity can also be an OEM server directly.
  • KMS KMS
  • various embodiments of the present application use KMS as an example of a key management entity for description, and it can be understood that the KMS may also be replaced by other forms of a key management entity.
  • the first information indicates the first key through the information of the second key, wherein the second key is configured to authenticate at least one functional key of the first ECU, and the at least one functional key Corresponding to at least one service function of the first ECU.
  • the first information is associated with the second key, or the first information is associated with information of the second key.
  • various embodiments of the present application are illustrated by using the first information to indicate the first key through the information of the second key. It should be understood that the first information is associated with the second key, or the first information is associated with the second key.
  • the information of the key may be associated with the information of the second key, and the implementation manner of the first key may be indicated by the information of the second key corresponding to the first information.
  • ECU-1 As an example of the first ECU for description. It should be understood that ECU-1 may also be replaced by other representation forms of the first ECU.
  • the second key is an authentication key, such as MEK.
  • the MEK can be used to authenticate at least one function key of the ECU-1, and can also be used to authenticate the hardware function key of the ECU-1.
  • the MEK can be obtained from the KMS.
  • At least one function key of ECU-1 may include one of the following implementation methods:
  • Mode 1 A function key of ECU-1.
  • the function key may correspond to one or more service functions of the ECU-1.
  • the function key can be used for on-board encrypted communication and/or device authentication.
  • Mode 2 Multiple function keys for ECU-2.
  • the ECU-1 can be used for multiple services, so the ECU may have multiple function keys, and these multiple function keys can correspond to multiple service functions of the ECU-1; Multiple function keys can also be used for the same service.
  • different function keys can be used (such as on-board encrypted communication key) to realize board-end encrypted communication, that is, the same function key can be shared between ECU-1 and ECU-2, for example, it is marked as function key 1; another function key can be shared between ECU-2 and ECU-3 key, such as function key 2.
  • the MEK can also be configured to authenticate at least one function key of a plurality of ECUs, and the at least one function key corresponds to at least one service function of the plurality of ECUs.
  • at least one service function of the plurality of ECUs may include the following implementation manner:
  • Mode A One function key for multiple ECUs.
  • the function key may correspond to one or more service functions of the plurality of ECUs.
  • the multiple ECUs can use the same function key (such as board-side encrypted communication key) to realize board-side encrypted communication, or the function key can Terminal encrypted communication can also be used for device authentication.
  • Method B Multiple function keys for multiple ECUs.
  • the multiple function keys may correspond to one service function or multiple service functions of the multiple ECUs.
  • the multiple ECUs can all be used for board-side encrypted communication, but different ECUs can implement board-side encrypted communication through different function keys;
  • the ECU corresponds to another service, and at this time, the multiple function keys may correspond to different services respectively.
  • the function key corresponds to a service function, and it can be understood that the function key will be used in the process of realizing the service function.
  • the first key may be a functional key, or a temporary key.
  • the temporary key may include MEK or a derived key of the functional key, which is used for encryption and/or integrity protection of the generated intermediate key.
  • the first key in order to implement the integrity verification of the MEK, the first key may be used as an intermediate key.
  • the first key may be obtained from the KMS.
  • the first key may be a key generated in advance by the KMS and stored in a locally maintained database, or may be a randomly generated key. This is not limited in this embodiment of the application. To simplify the description, the following content in the embodiments of the present application is described using VRF_K as a representation form of the first key, and it can be understood that the first key may also have other representation forms.
  • the first information includes information obtained through encryption and/or integrity protection using the MEK. Based on this, the KMS can realize that the first information indicates the first key through the information of the second key.
  • the first information may include information generated based on the authentication key MEK and the key VRK_K to be written through an encryption algorithm and/or an integrity protection algorithm, and the first information may be used to write the first key.
  • the first information includes information obtained through encryption and/or integrity protection using a key derived from the MEK. Based on this, the KMS can realize that the first information indicates the first key through the information of the second key.
  • the first information may be the information obtained through encryption and/or integrity protection calculation by one or more derived keys of MEK. Further, in an optional design, the first information may be used to write VRK_K. Since the first information includes the information obtained by encrypting and/or integrity-protecting the derived key of the MEK, it is ensured that the MEK is not exposed outside the KMS in plain text, and the security of the MEK is ensured.
  • the information obtained through the MEK derived key for integrity protection may include the information obtained through the MEK derived key combined with one or more algorithms in the integrity protection algorithm.
  • information which is not specifically limited in the embodiment of this application.
  • the information obtained through the MEK derived key combined with the label calculation algorithm in the integrity protection algorithm can be understood as the information obtained through the MEK derived key for integrity protection.
  • a derived key may be used for both encryption and integrity protection calculations, or it may be used only for encryption or integrity protection calculations. Based on this, when one derived key is only used for encryption or integrity protection calculation, the first information needs to implement encryption and integrity protection calculation through multiple derived keys of MEK.
  • the KMS can derive two derived keys K1' and K2' corresponding to the MEK based on the MEK, parameters Key_update_ENC_C and Key_update_MAC_C through the KDF, and these two derived keys are used for encryption and integrity protection respectively.
  • specific values of the parameters Key_update_ENC_C and Key_update_MAC_C may be predefined, such as predefined in relevant technical specifications.
  • the technical specification may be, for example, the security hardware extension SHE technical specification issued by the AUTOSAR organization.
  • K1', K2' for example, can be realized by following formula (1) and formula (2):
  • K1' first KDF (MEK, Key_update_ENC_C) formula (1)
  • K2' first KDF (MEK, Key_update_MAC_C) formula (2)
  • KMS can encrypt VRK_K based on the above-mentioned K1' through an encryption algorithm to obtain the third information included in the first information.
  • KMS uses the AES algorithm to implement K1' to encrypt VRK_K; KMS can also use the MAC algorithm to encrypt VRF_K based on K2'.
  • Integrity protection obtains the fourth information included in the first information.
  • the encryption algorithm and the integrity protection algorithm include but are not limited to the specific implementation manners described above, which are not specifically limited in this embodiment of the present application.
  • the KMS may concatenate the identity information of the ECU-1, the index of the VRF_K, and the index of the MEK to obtain the second information included in the first information.
  • the index of VRF_K may be used to uniquely identify VRF_K
  • the index of MEK may be used to uniquely identify MEK. It should be understood that different keys need to be stored separately in the ECU to ensure that different keys will not overwrite each other, thereby ensuring normal use of different keys. Based on this, in an optional design, the index of VRF_K can also be understood as indicating the address information stored in ECU-1 by VRF_K, similarly, the index of MEK can be used to indicate that MEK is in ECU-1 Saved address information.
  • the address information stored in the ECU for different keys can be predefined in relevant technical specifications, for example, in the SHE technical specification, it is stipulated that the address information corresponding to MEK is 0x1, and the address information corresponding to KEY1 ⁇ KEY10 is 0x4 ⁇ 0xd respectively , the address information corresponding to RAM_KEY is 0xe, where KEY1-KEY10 may correspond to function keys, and RAM_KEY may correspond to temporary keys.
  • the identity information of the ECU-1 is the identity identifier of the ECU-1 or the group identifier of the ECU-1.
  • the identity of the ECU-1 is used to uniquely identify the ECU-1.
  • the identity of the ECU-1 includes: the device identification code of the ECU-1 and the device type of the ECU-1.
  • the equipment identification code of ECU-1 can be part number (part number, PART#), for example, the equipment type of ECU-1 can include but not limited to: engine management system (engine management system, EMS), automatic transmission control unit (transmission control unit, TCU), body control module (body control module, BCM), electronic stability control system (electronic stability program, ESP), battery management system (battery management system, BMS), vehicle controller (vehicle control unit, VCU), etc.
  • the device identification code of the ECU-1 may include indication information of the device type of the ECU-1. In this case, the ECU-1 may be directly identified by the device identification code.
  • the group identifier of ECU-1 is used to identify the device group to which the ECU-1 belongs, and all ECUs included in the device group have common attributes.
  • the group identifier of ECU-1 can be used to identify the production line batch corresponding to the ECU-1, correspondingly, all the ECUs included in the equipment group to which the ECU-1 belongs belong to the same production line batch; and /or the group identifier of ECU-1 can be used to identify the equipment type corresponding to the ECU-1, correspondingly, all the ECUs included in the equipment group to which the ECU-1 belongs correspond to the same equipment type; and/or, the ECU-1
  • the group identifier of 1 may be used to identify the service function corresponding to the ECU-1.
  • the equipment identification code of an ECU is composed of W digits, where the W1 digit indicates one or more of the following corresponding to the ECU: production line batch, equipment type, business function, and the W2 digit indicates that the ECU is different from the ECU.
  • Information specific to other ECUs in the device group, W W1+W2.
  • the group identifier of ECU-1 may include at least one wildcard character, which is used to represent the unique information corresponding to all ECUs included in the equipment group, and the wildcard character may be realized by special characters such as #, %, #, etc.
  • the second information can be valid for multiple ECUs, and then the KMS can flash the first keys of multiple ECUs in batches, saving signaling overhead.
  • the first information indicates VRF_K through the information of the MEK
  • the first information includes second information M1', third information M2', and fourth information M3'.
  • the first information may be expressed as M1'
  • UID indicates the identity information of ECU-1
  • VRF_K_ID and MEK_ID respectively indicate the index of the first key and the index of MEK
  • indicates information cascade operation, for example
  • C ID ' is the count value output by KMS's local counter (count, CNT), which can be used for counting. It can be automatically incremented by 1 before each encryption. Subsequent verification of the size relationship between the received CNT and the locally generated CNT can achieve The purpose of anti-replay attack, the so-called replay attack is that the attacker sends a package that has been received by the destination host to achieve the purpose of deceiving the system, mainly used in the identity authentication process, destroying the correctness of the authentication.
  • F ID ' is used to configure the security flag of the storage area corresponding to VRF_K_ID.
  • the security flag can include, for example, the security flag defined in the AUTOSAR technical specification.
  • WRITE_PROTECTION write protection flag
  • BOOT_PROTECTION boot protection flag
  • DEBUGGER_PROTECTION debugging Protection flag
  • key usage flag KEY_USAGE
  • WILDCARD wildcard flag
  • the above-mentioned cascading information may include other information besides the above information, which is not specifically limited in the embodiment of the present application.
  • the encryption algorithm used to generate M2' and the MAC algorithm used to generate M3' listed here are only examples, and should not constitute any limitation to this embodiment of
  • the second verification information includes information used for VRF_K integrity verification.
  • the second verification information includes VRF_K, which can be used to verify the integrity of VRF_K.
  • the client can determine the local verification information by receiving the VRF_K and combining the locally generated first verification parameters.
  • the local verification information can be used Integrity verification based on VRF_K and/or MEK.
  • the second verification information includes a second verification parameter, and information obtained by performing integrity protection on the second verification parameter through VRF_K, wherein the second verification parameter is used to verify the integrity of VRF_K, and the second verification parameter may be KMS random
  • the generated information may also be information generated by the KMS according to certain rules, or generated by other means, which is not specifically limited here.
  • the KMS uses VRF_K as a key to generate the integrity verification information (VRF_MAC) of VRF_K through CMAC calculation, and VRF_MAC can be used to represent the integrity of VRF_K.
  • the key management entity sends the first information and the second verification information to the client.
  • the client receives the first information and the second verification information from the key management entity.
  • the client can be used for key flashing, that is, the client can implement keys (such as authentication keys, authentication keys, and other temporary keys) to be written into the ECU in the vehicle.
  • the client can be, for example, an OEM key flashing device or a dealer diagnostic instrument or an on-board diagnostics (On Board Diagnostics, OBD).
  • the OEM key flashing device may also be called an OEM diagnostic tool, or an OEM diagnostic instrument, and the dealer diagnostic instrument may also be called a dealer key flashing device, which is not specifically limited in this embodiment of the present application.
  • the client may also include an OEM server or include a dealer server.
  • the KMS sending the first information and the second verification information to the client may include: KMS directly sending the first information and the second verification information to the OEM key flashing device , or the KMS first sends the first information and the second verification information to the OEM server, and then the OEM server forwards the first information and the second verification information to the OEM key flashing device.
  • the KMS sending the first information and the second verification information to the client may include: the KMS directly sends the first information and the second verification information to the client. Further, the OEM server may receive the first information and the second verification information from the KMS, and then forward them to the OEM key flashing device. It should be understood that in this case, the above-mentioned key management entity may not include the OEM server.
  • the KMS sending the first information and the second verification information to the client may include: KMS directly sends the first information and the second verification information to the dealer's diagnostic instrument, or KMS first
  • KMS directly sends the first information and the second verification information to the dealer's diagnostic instrument
  • KMS first
  • the first information and the second verification information are sent to the OEM server or the dealer server, and then the OEM server or the dealer server forwards the first information and the second verification information to the dealer diagnostic instrument.
  • the KMS sending the first information and the second verification information to the client may include: the KMS directly sending the first information and the second verification information to the client.
  • the dealer server may receive the first information and the second verification information from the KMS or the OEM server, and then forward them to the dealer diagnostic instrument.
  • the OEM server may first receive the first information and the second verification information from the KMS.
  • the first information may be applied to one ECU, or to multiple ECUs
  • the second verification information may be applied to one ECU, or to multiple ECUs.
  • the ECUs to be verified for MEK integrity include ECU-1, ECU-2, and ECU-3.
  • these three ECUs may correspond to the same VRF_K, and accordingly, the KMS may pass the same VRF_K
  • One information indicates the first key
  • the second verification information corresponding to the three ECUs is also the same; in another case, the three ECUs can correspond to different VRF_K, correspondingly, the first The information is different from each other, and the corresponding second verification information is also different from each other.
  • the KMS may send the first information and the second verification information in the same signaling, or may send the first information and the second verification information respectively through different signaling. If the first information includes multiple pieces of information, for example, the first information includes the second information, the third information, and the fourth information, the KMS may use different signaling to send the different information included in the first information, or may use the same One signaling sends all the information included in the first information. In addition, if different ECUs correspond to different first keys, correspondingly, the first information and the second verification information generated based on the first key are also different, for example recorded as first information-1, first information- 2 and the first information-3, and the second verification information-1, the second verification information-2, and the second verification information-3.
  • KMS can send different first information and different second verification information in the same signaling, or send the first information-1, first information-2 and The first information-3, and the second verification information-1, the second verification information-2, and the second verification information-3, or the first information and the second verification information corresponding to the respective ECUs can also be transmitted through different signaling Send to the OEM key flashing device respectively, such as first information-1 and first verification information-1 through signaling 1, first information-2 and first verification information-2 through signaling 2, first information-2 and first verification information-2 through signaling 3 Send the first information-3 and the first verification information-3 to the OEM key flashing device, and further, the OEM key flashing device can send these information to the corresponding ECUs respectively.
  • the KMS may also send the first information and the second verification information in other ways, which are not specifically limited in this embodiment of the present application.
  • the device for flashing the OEM key sends the first information and the first verification parameter to the ECU-1.
  • ECU-1 receives the first information and the first verification parameter.
  • the OEM key flashing device forwards the first information from the KMS to ECU-1, so that ECU-1 can determine VRF_K based on the first information.
  • forwarding can be understood as transparent transmission, that is, in this scenario, the OEM key flashing device can directly transmit the first information of future KMS to ECU-1. , the OEM key device does not perform any processing on the first information.
  • the first verification parameter is used to verify the integrity of VRF_K.
  • the first verification parameter is the second verification parameter, that is, the OEM key flashing device may directly forward the second verification parameter from the KMS to the first ECU.
  • the first verification parameter is information generated by the OEM key flashing device, such as information randomly generated by the OEM key flashing device, or information generated by the OEM key flashing device according to certain rules.
  • the OEM key flashing device may also generate the first verification parameter in other ways, which are not specifically limited here. It should be understood that the first verification parameter may also be applied to multiple ECUs, that is, for multiple ECUs including ECU-1, the first verification parameter may be the same.
  • the OEM key flashing device sends the first information and the first verification parameter in the same signaling to save signaling overhead, or the first information and the first verification parameter can be sent separately through different signaling , realizing the flexibility indicated by the first information and the first verification parameter.
  • the OEM key flashing device may directly send the first information and the first verification parameter to the ECU-1, for example, the OEM key flashing device is directly connected to the ECU-1, and send the first information and the first verification parameter to the ECU-1; or, if the functional parts including the ECU-1 support the forwarding mechanism, the OEM key flashing device can first send the first information and the first verification parameter to the ECU-1. Send to include this functional part, then send the first information and the first verification parameter to ECU-1 by the functional part through the internal forwarding mechanism, in this case, it can be understood that the OEM key flashing device can communicate with the The functional parts are directly connected.
  • the functional component is a domain controller (domain controller, DC) including one or more ECUs or a key management system in the vehicle.
  • the domain controller can also be regarded as an electronic functional unit ECU, that is, the domain controller can directly receive the first information from the client.
  • the ECU-1 generates first verification information according to the MEK and the first verification parameters.
  • the first verification information is used to characterize the integrity of the first key.
  • the ECU-1 generates the first verification information according to the MEK and the first verification parameter, which may include: the ECU-1 decrypts and/or integrity checks the received first information through the MEK to determine the VRF_K, Then, according to the VRF_K and the received first verification parameter, first verification information for representing the integrity of the first key is generated.
  • the ECU-1 decrypts and/or integrity checks the received first information through the MEK to determine the VRF_K, which may include: ECU-1 first based on the received first information It is determined that the MEK is used to implement decryption and/or integrity verification of the first information, and then the locally stored MEK is used to perform specific decryption and/or integrity verification on the first information, thereby determining VRF_K.
  • the ECU-1 after the ECU-1 determines VRF_K, it can store VRF_K locally.
  • the following illustrates a specific implementation of the ECU-1 generating the first verification information according to the MEK and the first verification parameters.
  • the first information It includes the second information M1', the third information M2' and the fourth information M3'.
  • the specific implementation of M1', M2' and M3' can refer to the corresponding description in step 201, which will not be repeated here.
  • ECU-1 determines the index of MEK (i.e. MEK_ID) according to the received M1', based on this, ECU-1 uses the key stored locally and corresponding to MEK_ID as MEK for the integrity verification and decryption of VRF_K.
  • ECU-1 can first complete the integrity check to VRF_K or the first information based on the locally stored MEK and the received M3', so as to ensure that the VRF_K or the first information has not been tampered with. If the integrity verification of VRF_K or the first information is successful, ECU-1 decrypts M2' according to the locally stored MEK to determine VRF_K. In an optional design, after ECU-1 determines VRF_K, based on the address information indicated by the index of VRF_K included in M1', the VRF_K determined by decrypting M2' can be stored in the local memory corresponding to the address information . Further, after determining the VRF_K, the ECU-1 may generate the first verification information according to the determined VRF_K and the first verification parameters, and the specific generation process may refer to the above description, which will not be repeated here.
  • ECU-1 performs integrity verification based on MEK and M3', including integrity verification based on the derived key of MEK, and ECU-1 decrypts M2' based on MEK, including decrypting M2 based on the derived key of MEK. '.
  • the derivation algorithm used by the ECU-1 in the process of determining VRF_K is the same as the derivation algorithm used by the KMS in the process of determining the first information, and the derivation algorithm may be an algorithm pre-configured in the ECU-1.
  • ECU-1 sends first verification information to the OEM key flashing device.
  • the OEM key flashing device receives the first verification information.
  • the OEM key flashing device determines the integrity of the MEK according to the local verification information and the first verification information, wherein the local verification information is information obtained by integrity protection through VRF_K and the first verification parameter.
  • the local verification information comes directly from the KMS.
  • the local verification information is the information obtained by performing integrity protection on the second verification parameter through VRF_K included in the second verification information in step 201 (for example, it is recorded as VRF_MAC ).
  • the first verification parameter may be a second verification parameter included in the second verification information.
  • the OEM key flashing device compares the VRF_MAC from the KMS with the first verification information (marked as MAC_T, for example) from the ECU-1, and determines the integrity of the MEK according to the comparison result.
  • VRF_MAC is obtained by KMS based on VRF_K and the second verification parameter
  • MAC_T is obtained by ECU-1 based on locally determined VRF_K and the first verification parameter, so by comparing VRF_MAC and MAC_T, it can be It is determined whether the VRF_K determined locally by the ECU-1 is the same as the VRF_K from the KMS.
  • VRF_K from KMS is indicated by the information of MEK, and the VRF_K determined locally by ECU-1 is determined based on the MEK stored locally, so equivalently, by comparing VRF_MAC and MAC_T, it can be determined that ECU-1 local Whether the saved MEK is the same as the MEK saved by the KMS, and then realizes the integrity verification of the MEK saved locally by the ECU-1.
  • the MEK stored locally by ECU-1 is complete, which may include: the MEK stored locally by ECU-1 is the same as the MEK stored by KMS, or locally stored by ECU-1 The MEK is a valid key.
  • the MEK stored locally by ECU-1 is incomplete, which may include: the MEK stored locally by ECU-1 is different from the MEK stored by KMS, or the MEK stored locally by ECU-1 is not a valid encryption key. It should be understood that only when the MEK stored locally by the ECU-1 is complete, can the OEM key flashing device write the function key to the ECU-1 based on the MEK, thereby ensuring the normal use of the ECU-1 in the entire vehicle.
  • the local verification information is information locally determined by the OEM key flashing device.
  • the device for flashing an OEM key determines the local verification information according to the second verification information from the KMS and the locally generated first verification parameters, wherein the second verification information includes VRF_K.
  • the local authentication information for example, VRF_MAC
  • the first authentication parameter for example, VRF_M
  • VRF_MAC is obtained by the OEM key flashing device according to the VRF_K from the KMS and the locally generated first verification parameter
  • MAC_T is obtained by ECU-1 based on the locally determined VRF_K and the first verification parameter from the OEM key flashing device
  • the first verification parameter is obtained, so in this way, by comparing VRF_MAC and MAC_T, it can also be determined whether the VRF_K determined locally by the ECU-1 is the same as the VRF_K from the KMS.
  • VRF_MAC and MAC_T it can be determined whether the MEK stored locally by the ECU-1 is the same as the MEK stored by the KMS, thereby realizing the integrity verification of the MEK locally stored by the ECU-1.
  • the specific implementation of determining the integrity of the MEK can refer to the above description, and details will not be repeated.
  • the embodiment of the present application indirectly verifies the integrity of the second key through the integrity of the first key, which not only realizes the integrity verification of the second key, but also ensures the integrity of the functional key.
  • the second key is exposed outside the KMS and ECU in plain text, thereby ensuring the security of the core assets of the OEM.
  • the information used to verify the integrity of the first key does not include the identification information of the ECU.
  • the entire vehicle production line does not need to collect the identification information of all target ECUs for which the second key is to be updated in advance, thereby reducing the cost of the entire vehicle.
  • Production line burden and management costs.
  • the KMS can also pre-prepare the filling key material (for example, the first information and the second verification information in the above embodiment) for the first key integrity verification, and send it to the OEM key in advance
  • the flashing device based on this, can also realize offline verification of the second key of the ECU, that is, it does not depend on KMS, and can also realize real-time verification of the integrity of the second key, reducing time overhead. It should be understood that through this solution, it is also avoided to deploy the KMS near the existing vehicle production line, which simplifies the design of the vehicle production line and reduces the management cost of the vehicle factory.
  • the integrity verification of the second key can be realized.
  • the KMS may first write the second key into the ECU through the client.
  • the KMS needs to first write the second key stored locally by the KMS into the In the ECU.
  • the OEM can first pass some preset root keys to the component developers (such as Tier1 component developers), and the component developers will first write these preset root keys into the ECU As the initial hardware permission key of ECU.
  • the second key stored locally by the new ECU may be different from the second key stored by the KMS.
  • the successful writing of the function key needs to be authenticated by the authentication key first, so the 4S shop needs to first Write the second key stored in the KMS into the ECU through the key flashing device. After the KMS writes the second key into the ECU, the integrity verification of the second key is implemented based on the method in the embodiment shown in FIG. 2 .
  • the key verification method described in the embodiment of the present application may also include steps S301-S304 shown in Figure 3, these steps can be used to write the second key to the ECU, for Certain specific scenarios may be necessary.
  • ECU-1 is still taken as an example of the first ECU below
  • KMS is an example of a key management entity
  • an OEM key flashing device is an example of a client
  • MEK is an example of a second key
  • VRF_K is an example of a first key.
  • the KMS generates fifth information.
  • the fifth information indicates the MEK through the information of the fifth key, and the fifth key is used to authenticate the MEK.
  • the fifth key may be a pre-master ECU master key (pre-master ECU key, PMEK) preset in the ECU-1, or may also be a previous version of the MEK stored locally by the ECU-1.
  • the MEK locally stored in KMS is MEK2.0
  • the previous version of MEK locally stored in ECU-1 is MEK1.0.
  • the MEK1.0 in -1 is replaced by MEK2.0 to ensure the normal use of the ECU-1 function key.
  • PMEK is used as an example of the fifth key for description in each embodiment of the present application. It can be understood that PMEK may also be replaced by other authentication keys used to authenticate the MEK.
  • the fifth information indicates the MEK through PMEK information, and may include: the fifth information includes information obtained through encryption and/or integrity protection calculation through the PMEK. Based on this, the KMS can realize that the fifth information indicates the second key through the information of the PMEK.
  • the fifth information may include information generated based on the authentication key PMEK and the key MEK to be written by using an encryption algorithm and/or an integrity protection algorithm, and the fifth information may be used for writing the MEK.
  • the fifth information indicates the MEK by using PMEK information, and may include: the fifth information includes information obtained by encrypting and/or integrity protecting by using a derived key of the PMEK. Based on this, the KMS can realize that the fifth information indicates the MEK through the information of the PMEK.
  • the fifth information may be information obtained through encryption and/or integrity protection calculation by one or more derived keys of the PMEK, and the fifth information may be used to write into the MEK.
  • a derived key can be used for both encryption and integrity protection calculations, or it can be used only for encryption or integrity protection calculations. It should be understood that when one derived key is only used for encryption or integrity protection calculation, the fifth information needs to be encrypted and integrity protection calculation through multiple derived keys of PMEK.
  • the KMS can derive two derived keys K1 and K2 corresponding to the PMEK based on the PMEK, parameters Key_update_ENC_C and Key_update_MAC_C through the KDF, and these two derived keys are used for encryption and integrity protection respectively.
  • specific values of the parameters Key_update_ENC_C and Key_update_MAC_C may be predefined, such as predefined in relevant technical specifications.
  • the technical specification may be, for example, the SHE technical specification issued by the AUTOSAR organization.
  • K1 and K2 can be realized by the following formula (3) and formula (4):
  • K1 second KDF (PMEK, Key_update_ENC_C) formula (3)
  • K2 second KDF (PMEK, Key_update_MAC_C) formula (4)
  • KMS can encrypt MEK based on the above-mentioned K1 through an encryption algorithm to obtain the seventh information included in the fifth information.
  • KMS uses the AES algorithm to encrypt MEK by K1; KMS can also use the MAC algorithm to protect the integrity of MEK based on K2
  • the eighth information included in the fifth information is obtained.
  • the encryption algorithm and the integrity protection algorithm include but are not limited to the specific implementation manners described above, which are not specifically limited in this embodiment of the present application.
  • the KMS may concatenate the identity information of the ECU-1, the index of the MEK, and the index of the PMEK to obtain sixth information included in the fifth information.
  • identity information of the ECU-1 and the index of the MEK reference may be made to the specific description in S201 above, which will not be repeated here.
  • the PMEK index is used to uniquely identify the PMEK, and can be used to indicate the address information of the PMEK stored in the ECU-1. It should be noted that when the identity information of ECU-1 is a group identifier containing wildcards, the fifth information can be valid for multiple ECUs, and then KMS can flash the second keys of multiple ECUs in batches, saving Signaling overhead.
  • the fifth information indicates the MEK through the information of the PMEK
  • UID indicates the identity information of ECU-1
  • indicates information cascade operation, for example, A
  • C ID is the count value output by the KMS local counter CNT, which can be used for counting. It can be automatically incremented by 1 before each encryption.
  • the F ID is used to configure the security flag of the storage area corresponding to the MEK_ID.
  • the encryption algorithm used to generate M2 and the MAC algorithm used to generate M3 listed here are only examples, and should not constitute any limitation to this embodiment of the application.
  • the encryption algorithm and the integrity protection algorithm may also include, but are not limited to, the specific implementation manners described above, which are not specifically limited in this embodiment of the present application.
  • the KMS sends fifth information to the OEM key flashing device.
  • the OEM key flashing device receives the fifth information.
  • the fifth information includes multiple pieces of information, for example, the fifth information includes sixth information, seventh information, and eighth information
  • the KMS may use different signaling to send different information included in the fifth information, or All information included in the fifth information may also be sent through the same signaling.
  • the KMS may also carry the fifth information (or part of the information included in the fifth information) with other information (such as the first information or part of the information included in the first information) sent to the OEM key flashing device. can be sent in one signaling, or can also be sent through different signalings.
  • the embodiment of the present application does not limit the specific manner of implementing the sending of the fifth information.
  • the device for flashing the OEM key sends the fifth information to the ECU-1.
  • ECU-1 receives the fifth information.
  • the OEM key flashing device forwards the fifth information from the KMS to ECU-1, so that ECU-1 can determine the MEK based on the fifth information.
  • For the specific implementation manner of sending the fifth information to the ECU-1 by the OEM key flashing device reference may be made to the corresponding description in S203, which will not be repeated here.
  • ECU-1 determines MEK according to the fifth information.
  • the ECU-1 determining the MEK according to the fifth information may include: the ECU-1 decrypts and/or integrity checks the received fifth information according to the PMEK to determine the MEK. Specifically, for example, based on the received fifth information, ECU-1 first determines to realize the decryption and/or integrity check of the fifth information through PMEK, and then performs specific decryption of the fifth information through the locally stored PMEK and/or integrity checks to determine the MEK.
  • the fifth information in step S301 corresponds a specific implementation of the ECU-1 determining MEK according to the fifth information.
  • the fifth information includes sixth information M1,
  • the specific implementation manners of M1, M2 and M3 can refer to the corresponding description in step S301, which will not be repeated here.
  • ECU-1 determines the index of PMEK (namely PMEK_ID) according to the received M1, based on this, ECU-1 uses the key stored locally and corresponding to PMEK_ID as PMEK for integrity verification and decryption of MEK.
  • the ECU-1 may first complete the integrity verification of the MEK or the fifth information based on the locally stored PMEK and the received M3, so as to ensure that the MEK or the fifth information has not been tampered with. If the integrity verification of the MEK or the fifth information is successful, the ECU-1 decrypts M2 according to the locally stored PMEK to determine the MEK.
  • ECU-1 determines the MEK, it stores the MEK locally.
  • ECU-1 may store the MEK determined by decrypting M2 in the local memory corresponding to the address information based on the address information indicated by the MEK index (MEK_ID) included in M1, or store the locally stored PMEK Replace with that MEK.
  • MEK_ID the MEK index
  • the MEK can be written into the ECU first, so that the maintenance party authorized by the vehicle production line and/or the vehicle factory can correctly write the MEK first.
  • the method of writing MEK to ECU described above can be adapted to various scenarios where MEK is to be written. Through a unified solution adapted to various scenarios, the key management process of key management entities or vehicle manufacturers can be simplified. Simplify the key writing process.
  • the second information includes the information obtained by encrypting and/or integrity protecting the MEK, it can also prevent the MEK from being exposed outside the KMS and the ECU in plain text during the MEK writing process, thus ensuring the Security of core assets.
  • the key verification method described in each embodiment of the present application may also include one or more steps in steps S401-S404 shown in FIG. This step may be necessary for some specific scenarios. Steps S401-S404 are specifically as follows:
  • step S401 the OEM key flashing device sends MEK update request information to the KMS.
  • the KMS receives the MEK update request information.
  • This MEK update request message is used to request to update the MEK of ECU-1.
  • the MEK update information can be used to request the KMS to verify the integrity of the MEK stored locally by the ECU-1, or the MEK update request information can be used to request the KMS to write the MEK to the ECU-1 (including the integrity of the MEK). verify).
  • the MEK update request information may also include one or more of the following information: the identity authentication information of the OEM key flashing device, the number of ECUs to be updated (or the number of ECUs to be verified) The number of ECUs with MEK integrity), the identification code VIN of the vehicle to which the ECU belongs, the version number of the authentication key stored locally by the ECU, and the different version numbers of the ECU.
  • the identity authentication information can be used to represent whether the OEM key flashing device has the right to obtain one or more items of information obtained by the client from the key management entity included in each embodiment of the application, such as the first information , the fifth information, and the second verification information.
  • VIN can be used to identify a complete vehicle.
  • Different version numbers of the ECU can be used to identify the version number of the authentication key locally stored by the ECU, for example, the locally stored authentication key is PMEK, or MEK1.0, or MEK2.0, etc. It should be understood that the aforementioned ECUs to be updated with MEKs or ECUs with which to verify the integrity of MEKs include ECU-1.
  • step S402 the KMS verifies the MEK update request information.
  • the KMS may verify the MEK update request information. And according to the verification result, determine whether the first information used to indicate the first key and the second verification used to verify the integrity of the first key are passed or determined to pass the method described in the above-mentioned embodiment of the present application.
  • the information is sent to the OEM key flashing device, or the first information used to indicate the first key, the second verification information used to verify the integrity of the first key, and the fifth information used to indicate the second key
  • the information is sent to the OEM key flashing device.
  • the KMS verifies the MEK update request information, which may include one or more of the following: KMS verifies the legitimacy of the MEK update request information, and KMS determines that it is used to write the MEK (including the MEK Integrity Verification of MEK), the KMS determines the specific information used to verify the integrity of the MEK.
  • the verification of the legitimacy of the MEK update request information by the KMS can be understood as: KMS determines whether the OEM key flashing device that initiated the MEK update request information has the right to obtain information related to MEK writing and/or integrity verification.
  • Information such as the first information, the fifth information, and the second verification information in each embodiment of the present application; or, KMS verifying the legitimacy of the MEK update request information can also be understood as: KMS flashes the device through the OEM key.
  • the identity authentication information determines whether the OEM key flashing device is an OEM authorized key flashing device. If the OEM key flashing device is an OEM-authorized key flashing device, it can be assumed that the OEM key flashing device has the authority to obtain information related to MEK writing and/or integrity verification.
  • the identity authentication information may indicate whether the 4S store or the maintenance party that initiates the MEK update request is an OEM-authorized dealer. It should be understood that in this scenario, the OEM key flashing device can be replaced by a dealer diagnostic instrument. If the identity authentication information can indicate that the 4S shop or maintenance party is a dealer authorized by the OEM, then the KMS can send information related to MEK writing and/or integrity verification to the dealer's diagnostic instrument. Based on this, it can be guaranteed that information related to MEK writing and/or integrity verification is only provided to clients authorized by KMS or OEMs, thus ensuring the security of MEK.
  • the KMS can determine the specific information used to write the MEK (including the integrity verification of the MEK) or the information used to verify the integrity of the MEK through one or more of the following information included in the MEK update request information.
  • specific information is: the number of ECUs whose MEK is to be updated (or the number of ECUs whose MEK integrity is to be verified), the vehicle identification number (VIN) of the vehicle to which the ECU belongs, and the ID of the authentication key stored locally by the ECU. Version number, different version numbers of ECU.
  • KMS can determine one or more of the following information through the number of ECUs whose MEK is to be updated or the number of ECUs whose MEK integrity is to be verified: the number of the first information, the number of the second verification information, the fifth information
  • the number of MEKs can be written in batches to ECUs in batches and/or the integrity verification of MEKs in batches can be realized, and the cost of key management can be reduced.
  • KMS can determine the version number of the MEK to be written through the different version numbers of the ECU or the version number of the authentication key stored locally by the ECU, thereby ensuring effective MEK writing, and further writing functions based on the MEK key to ensure the normal use of the ECU.
  • step S403 is specifically:
  • the ECU-1 sends the version number of the locally stored MEK to the OEM key flashing device.
  • the OEM key flashing device receives the version number of the locally stored MEK.
  • ECU-1 can also send one or more of the following information to the OEM key flashing device: the identification code of the vehicle to which ECU-1 belongs, that is, VIN, the VIN of ECU-1 Different version numbers, ECU-1 device identification code, ECU-1 device type.
  • the OEM key flashing device can determine the number of ECUs whose MEK is to be updated or the number of ECUs whose integrity of the MEK is to be verified by collecting the above information of multiple ECUs.
  • the device for flashing the OEM key sends an update result of the MEK to the KMS.
  • the KMS receives the OEM key flashing device.
  • the update result of the MEK includes one or more of the following: the integrity of the MEK, the integrity of the VRF_K, and the identity of the ECU-1.
  • the integrity of the MEK is used to indicate whether the MEK is written into ECU-1 and has passed the integrity verification, or the integrity of the MEK is used to indicate whether the MEK locally stored in the KMS is the same as the MEK locally stored in the ECU-1; the integrity of the VRF_K It is used to indicate whether VRF_K is written into ECU-1 and has passed the integrity verification.
  • the KMS can determine whether the MEK is completely written into the ECU-1, and if it is determined that the MEK has not been completely written into the ECU-1, it can retry to write the MEK into the ECU through the OEM key flashing device -1; if it is determined that the MEK has been completely written into ECU-1, the update result can be filed for possible subsequent applications.
  • steps S401-step S403 shown in FIG. 4 may be included before the methods in the above embodiments, and after the methods in the above embodiments, you may Step S404 shown in FIG. 4 is included.
  • KMS can generate information suitable for MEK update or MEK integrity verification, and then realize the integrity verification of MEK, and ensure the normal use of function keys and the information security of the whole vehicle.
  • KMS can determine whether the MEK is written into the first electronic control unit and/or determine whether the authentication key stored locally by the first electronic control unit is MEK, so as to ensure the normal use of the function key and the information of the whole vehicle Safety.
  • the key management entity to manage the electronic control unit written into the MEK and/or the electronic control unit that has verified the integrity of the authentication key.
  • the key verification method described in the embodiment of this application may also include step S501-step S502 shown in FIG. 5, or may also include step S501-step S503.
  • Steps S501-S503 are specifically as follows:
  • ECU-1 generates ninth information according to the first information and the challenge-response mechanism.
  • the ninth information includes information for verifying the integrity of VRF_K.
  • the ninth information generated here may include eleventh information and twelfth information, wherein the eleventh information is at least passed through the ECU-1
  • the twelfth information is the information obtained by protecting the integrity of the eleventh information through the derived key of VRF_K
  • the thirteenth information is information obtained by encrypting the counter value (for example, C ID ') contained in the first information by using the derived key of VRF_K.
  • VRF_K integrity verification of VRF_K
  • the effect of anti-replay estimation can be achieved through the eleventh information including the thirteenth information.
  • the derivation algorithm, encryption algorithm, and integrity protection algorithm used to generate the derivation key may include, but are not limited to, the specific implementation manners described above, which are not specifically limited in this embodiment of the present application.
  • ECU-1 sends the ninth information to the OEM key flashing device.
  • the OEM key flashing device receives the ninth information.
  • ECU-1 can carry the ninth information and other information sent to the OEM key flashing device (such as the first verification information) in the same signaling and send it, or it can also send it through different The signaling respectively sends the ninth information and other information sent to the OEM key flashing device.
  • the OEM key flashing device such as the first verification information
  • the device for flashing the OEM key sends the ninth information to the KMS.
  • the KMS receives the ninth information.
  • the OEM key flashing device does not further process the received ninth information, for example, does not parse the ninth information.
  • the KMS can determine the identity of the ECU-1 according to the ninth information, which is used by the vehicle manufacturer to record the ECU whose integrity of the MEK has been confirmed.
  • ECU-1 may correspond to the responder in the challenge-response mechanism
  • the OEM key flashing device may correspond to the challenger in the challenge-response mechanism
  • the first information includes
  • the ninth information may correspond to a corresponding response made by the responding party.
  • the OEM key flashing device does not analyze the ninth information, but sends it to the KMS for further processing, and the KMS determines whether the responding party has passed the challenge and/or judges the responding party should be authenticated. In this way, the integrity verification of VRF_K can be realized, and the realization is simple.
  • the ninth information may be used to indicate the integrity of the VRF_K, and based on this, the ninth information may be understood as an example of the integrity information of the VRF_K. It should be understood that the ninth information may be included in the update result of VRF_K sent by the OEM key flashing device to the KMS.
  • the key verification method described in each embodiment of the present application includes the method in the embodiment shown in Figure 3
  • the key verification method described in the embodiment of the present application may also include the method shown in Figure 6 Step S601-step S602, or may also include step S601-step S603 shown in FIG. 6 .
  • Steps S601-S603 are specifically as follows:
  • the ECU-1 generates tenth information according to the fifth information and the challenge-response mechanism.
  • the tenth information includes information for verifying the integrity of the MEK.
  • the tenth information generated here may include the fourteenth information and the fifteenth information, wherein the fourteenth information is at least passed through the ECU-1
  • the information is the information obtained by encrypting the count value (for example, C ID ) contained in the second information with the key derived from the MEK.
  • the derivation algorithm, encryption algorithm, and integrity protection algorithm used to generate the derivation key may include, but are not limited to, the specific implementation manners described above, which are not specifically limited in this embodiment of the present application.
  • ECU-1 sends the tenth information to the OEM key flashing device.
  • the OEM key flashing device receives the tenth information.
  • ECU-1 may send the tenth information and other information sent to the OEM key flashing device (such as the first verification information and the ninth information) in the same signaling, or The tenth information and other information sent to the OEM key flashing device may also be sent separately through different signaling.
  • the device for flashing the OEM key sends the tenth information to the KMS.
  • the KMS receives the tenth information.
  • the OEM key flashing device does not further process the received tenth information, for example, does not parse the tenth information.
  • the KMS can determine the identity of the ECU-1 according to the tenth information, which is used by the vehicle manufacturer to record the ECU whose integrity of the MEK has been confirmed.
  • ECU-1 may correspond to the responder in the challenge-response mechanism
  • the OEM key flashing device may correspond to the challenger in the challenge-response mechanism
  • the fifth information includes challenge
  • the tenth information may correspond to a response made by the responding party.
  • the OEM key flashing device does not analyze the tenth information, but sends it to the KMS for further processing, and the KMS determines whether the responding party has passed the challenge and/or judges the responding party should be authenticated.
  • the tenth information can be used to indicate the integrity of the MEK. Based on this, the tenth information can be understood as an example of the integrity information of the MEK, that is, the MEK sent by the OEM key flashing device to the KMS The tenth information may be included in the update result.
  • Fig. 7 is a schematic block diagram of a control device provided by an embodiment of the present application.
  • the control device may include at least one processor and a memory, so as to execute the method in any possible implementation manner above.
  • the memory is used to store computer programs or instructions
  • the at least one processor is used to call the computer programs or instructions in the memory.
  • the at least one processor may be used to perform internal processing in the control device, for example, generate first verification information according to the second key and the first verification parameter, and the first verification information is used for Characterize the integrity of the first key; for another example, generate first information and second verification information; for another example, determine the integrity of the second key according to the local verification information and the first verification information, Wherein the local verification information includes information obtained by performing integrity protection on the first verification parameter by the first key.
  • the control device may further include a transceiver, as shown in FIG. 8 .
  • Fig. 8 is a schematic block diagram of a control device provided by an embodiment of the present application.
  • the transceiver is coupled with at least one processor and memory included in the control device, and it can be understood that the transceiver, the at least one processor, and the memory communicate with each other through an internal connection path.
  • the transceiver may provide information input and/or output for the at least one processor and the memory, so that the control device executes the method in any possible implementation manner in the embodiments of the present application.
  • the transceiver may be used for receiving first information; for another example, the transceiver may be used for receiving first verification parameters; for another example, the transceiver may be used for sending first verification information and so on.
  • control device includes a unit for executing the method in any possible implementation manner in the embodiments of the present application.
  • the above-mentioned control device may be a control device of an electronic component, configured to execute any method performed by ECU-1 above; or the above-mentioned control device is a control device of a key management entity, configured to Execute any of the above methods performed by the KMS; or the above-mentioned control device is a control device of a key flashing tool, and is used to execute any of the methods above performed by the OEM key flashing device.
  • An embodiment of the present application also provides a vehicle, the vehicle includes a control device that implements the method in any of the possible implementations performed by the ECU-1 above, or the vehicle includes a control device that implements the method performed by the ECU-1 above An electronic component of the method in any one of the possible implementations.
  • An embodiment of the present application also provides a system, the system includes electronic components for executing the method in any possible implementation manner executed by the ECU-1 above, including electronic components for executing the method executed by the ECU-1 above.
  • the vehicle of the control device of the method in any one of the possible implementations, the vehicle including the electronic components used to execute the method in any of the possible implementations performed by the ECU-1 above, and the vehicle used to execute the above KMS.
  • a key management entity executing the method in any of the possible implementations, or one of the key flashing tools used to execute the method in any of the possible implementations performed by the OEM key flashing device above or more.
  • An embodiment of the present application also provides a system, the system includes a control device for executing the method in any possible implementation manner executed by the ECU-1 above, and is used for executing any of the methods executed by the KMS above.
  • FIG. 9 shows a schematic structural diagram of a chip.
  • the chip includes one or more processors and an interface circuit, where the interface circuit is used to provide the one or more processors with information input and/or output for executing the method in any possible implementation manner above.
  • the chip may also include a bus.
  • the processor is an integrated circuit chip, which has a signal processing capability.
  • the processor may be a field programmable gate array (field programmable gate array, FPGA), a general processor, a digital signal processor (digital signal processor, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, system on chip (SoC), central processor unit (CPU), or network processing A network processor (network processor, NP), a microcontroller (micro controller unit, MCU), a programmable logic device (programmable logic device, PLD) or other integrated chips.
  • FPGA field programmable gate array
  • FPGA field programmable gate array
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register.
  • the storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.
  • the interface circuit can be used for sending or receiving data, instructions or information, and the processor can process the data, instructions or other information received by the interface circuit, and can send the processing completion information through the interface circuit.
  • the chip also includes a memory, which may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories.
  • the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • Volatile memory can be random access memory (RAM), which acts as external cache memory.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • DRAM synchronous dynamic random access memory
  • SDRAM double data rate synchronous dynamic random access memory
  • double data rate SDRAM double data rate SDRAM
  • DDR SDRAM enhanced synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • serial link DRAM SLDRAM
  • direct memory bus random access memory direct rambus RAM, DR RAM
  • processors and the interface circuit can be realized through hardware design, software design, or a combination of software and hardware, which is not limited here.
  • memory of the systems and methods described herein is intended to include, but not be limited to, these and any other suitable types of memory.
  • the embodiment of the present application also provides a computer program product, the computer program product includes: computer program code, when the computer program code runs on the computer, the computer executes any possible implementation performed by the first node above The method in the manner, or execute the method in any possible implementation manner performed by the second node above.
  • the present application also provides a computer-readable medium, the computer-readable medium stores program codes, and when the program codes are run on a computer, the computer is made to execute the method in any one of the above possible implementation manners.
  • all or part of them may be implemented by software, hardware, firmware or any combination thereof.
  • software When implemented using software, it may be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application will be generated in whole or in part.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media.
  • the available medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (for example, a solid state disk (solid state disc, SSD)) etc.
  • a magnetic medium for example, a floppy disk, a hard disk, a magnetic tape
  • an optical medium for example, a high-density digital video disc (digital video disc, DVD)
  • a semiconductor medium for example, a solid state disk (solid state disc, SSD)
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Lock And Its Accessories (AREA)

Abstract

本申请实施例提供一种密钥验证方法及相关装置，应用于信息安全领域。具体应用中，客户端将来自密钥管理实体的第一信息转发给第一电子控制单元，其中，该第一信息通过第二密钥的信息指示第一密钥，并且客户端向该第一电子控制单元发送第一验证参数，该第一验证参数用于验证该第一密钥的完整性，并接收响应于第一验证参数的第一验证信息，该第一验证信息用于表征该第一密钥的完整性。该客户端根据本地验证信息与该第一验证信息，确定第二密钥的完整性。采用该方式，通过第一密钥的完整性间接验证了第二密钥的完整性，且避免了第二密钥以明文形式暴露在密钥管理实体和第一电子控制单元之外，进而保证了整车厂核心资产的安全。

Description

一种密钥验证方法及相关装置 技术领域
本申请实施例涉及信息安全领域，尤其涉及一种密钥验证方法及相关装置。
背景技术
信息安全是自动驾驶的前提。目前整车系统中可以通过多种功能密钥来保护整车的信息安全。例如，可通过板端加密通讯(security onboard communication，SecOC)密钥(SecOC key)来保护车载通信网络的安全，也可通过用于设备认证的设备密钥(device key)来保证设备的真实性等。
一般来说，功能密钥的正常使用需要通过认证密钥的认证，因此如何保证认证密钥的完整性，进而保证功能密钥的正常使用是本领域技术人员亟待解决的技术问题。
发明内容
本申请实施例公开了一种密钥验证方法及相关装置，可以实现认证密钥的完整性验证，进而保证功能密钥的正常使用以及整车的信息安全。
第一方面，提供了一种密钥验证方法，该方法可以由电子控制单元或配置于电子控制单元中的芯片执行。该方法包括：通过客户端接收第一信息，所述第一信息来自密钥管理实体，所述第一信息通过第二密钥的信息指示第一密钥，所述第二密钥被配置用于认证第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能；接收来自所述客户端的第一验证参数；根据所述第二密钥和所述第一验证参数，生成第一验证信息，所述第一验证信息用于表征所述第一密钥的完整性；向所述客户端发送所述第一验证信息。
在一种可选的设计中，该方法也可以由包含电子控制单元的功能部件或配置于该功能部件中的芯片执行。示例性地，该功能部件为包含一个或多个电子控制单元的域控制器。
根据本申请提供的密钥验证方法，由于用于表征第一密钥完整性的第一验证信息是基于第二密钥和第一验证参数得到的，因此，可以通过第一密钥的完整性间接验证第二密钥的完整性，保证第二密钥的完整性以及安全性，进而保证功能密钥的正常使用以及整车的信息安全。此外，又由于第一信息是通过第二密钥的信息指示第一密钥且第一信息是由客户端通过密钥管理实体转发给第一电子控制单元，因此避免了第二密钥以明文形式暴露在密钥管理实体和电子控制单元之外，进而保证了整车厂核心资产的安全。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：接收来自所述客户端的第五信息，所述第五信息来自密钥管理实体，所述第五信息通过第五密钥的信息指示所述第二密钥，其中，所述第五密钥用于认证所述第二密钥。
采用该方案，可以先通过第五信息，将第二密钥写入第一电子控制单元，可以满足整车产线和/或整车厂授权的维修方将第二密钥正确写入第一电子控制单元的需求，进而为后续功能密钥的写入提供认证条件，保证功能密钥的正常使用以及整车的信息安全。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：根据所述第一信息和挑战-应答机制，生成第九信息，所述第九信息包括用于验证所述第一密钥完整性的信息； 向所述客户端发送所述第九信息。
该方案中，基于挑战-应答机制生成的第九信息可以实现对第一密钥的完整性验证，简化了验证流程，提高了验证效率。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：根据所述第五信息和挑战-应答机制，生成第十信息，所述第十信息包括用于验证所述第二密钥完整性的信息；向所述客户端发送所述第十信息。
该方案中，基于挑战-应答机制生成的第十信息可以实现对第二密钥的完整性验证，简化了验证流程，提高了验证效率。
在一种可选的设计中，所述第一验证信息包括通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息。由于第一信息是通过第二密钥的信息来指示第一密钥，因此只有当第一电子控制单元本地保存的第二密钥与密钥管理实体保存的第二密钥一致时，第一密钥才能基于第一信息被正确写入到该第一电子控制单元中。基于此，通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息，可以实现对第二密钥完整性的间接验证。
第二方面，提供了一种密钥验证方法，该方法可以由密钥管理实体或配置于密钥管理实体中的芯片执行。该方法包括：生成第一信息和第二验证信息，所述第一信息通过第二密钥的信息指示第一密钥，所述第二密钥被配置用于认证第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能，所述第二验证信息包括用于所述第一密钥的完整性验证的信息；向客户端发送所述第一信息和所述第二验证信息。
在一种可选的设计中，所述密钥管理实体包括密钥管理服务器(key management server，KMS)。
根据本申请提供的密钥验证方法，通过向客户端发送指示第一密钥的第一信息和可以用于第一密钥完整性验证的第二验证信息，可以实现第一密钥的写入以及对第一密钥完整性的验证。又由于第一信息通过第二密钥的信息指示第一密钥，因此，通过对第一密钥完整性的验证可以间接验证第二密钥的完整性，保证第二密钥的安全。另一方面，又由于第一信息是由密钥管理实体发送给客户端且第一信息是通过第二密钥的信息指示第一密钥，因此避免了第二密钥以明文形式暴露在密钥管理实体和电子控制单元之外，进而保证了整车厂核心资产的安全。此外，通过第一密钥的完整性间接验证第二密钥的完整性不需要依赖电子控制单元的标识信息，因此不需要整车产线提前收集待更新第二密钥的所有目标电子控制单元的标识信息，降低了整车产线的负担和管理成本。
通过该方案，密钥管理实体还可以预先准备好用于第一密钥完整性验证的信息(例如第一信息，第二验证信息)，并提前将其发送给客户端，基于此可以实现对电子控制单元的认证密钥(即第二密钥)的离线验证，即使不依赖于KMS，也可以实现对第二密钥完整性的实时验证，减少了时间开销。
在一种可选的设计中，所述第二验证信息包括所述第一密钥，以使得所述客户端根据所述第一密钥再结合本地生成的第一验证参数，确定本地验证信息，其中，该本地验证信息可以用于所述第一密钥和/或所述第二密钥的完整性验证；或者，所述第二验证信息包括 第二验证参数，以及通过所述第一密钥对所述第二验证参数进行完整性保护得到的信息。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：向所述客户端发送第五信息，所述第五信息通过第五密钥的信息指示所述第二密钥，其中，所述第五密钥用于认证所述第二密钥。
通过该方案，可以实现第二密钥的写入，从而满足整车产线和/或整车厂授权的维修方将第二密钥正确写入第一电子控制单元的需求，进而为后续功能密钥的写入提供认证条件，保证功能密钥的正常使用以及整车的信息安全。此外，该方案可以适配于第二密钥待写入的各种场景，通过适配于各种场景的统一解决方案，可以简化密钥管理实体或整车厂的密钥管理流程，简化密钥写入流程。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：接收来自所述客户端的第二密钥更新请求信息，所述第二密钥更新请求信息用于请求更新所述第二密钥，或者用于请求验证所述第一电子控制单元本地保存的第二密钥的完整性。
通过该方案，通过该第二密钥更新请求信息，生成适配于第二密钥更新或第二密钥完整性验证的信息，进而实现第二密钥的完整性验证，保证功能密钥的正常使用以及整车的信息安全。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：接收来自所述客户端的所述第二密钥的更新结果。
通过该方案，可以获知该第二密钥的更新情况，进而判断功能密钥是否能被写入，以此保证功能密钥的正常使用以及整车的信息安全。
第三方面，提供了一种密钥验证方法，该方法可以由客户端或配置于客户端中的芯片执行。该方法包括：接收来自密钥管理实体的第一信息；向第一电子控制单元发送所述第一信息，所述第一信息通过第二密钥的信息指示第一密钥，所述第二密钥被配置用于认证所述第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能；向所述第一电子控制单元发送第一验证参数，所述第一验证参数用于验证所述第一密钥的完整性；接收来自所述第一电子控制单元的第一验证信息，所述第一验证信息用于表征所述第一密钥的完整性；根据本地验证信息与所述第一验证信息，确定所述第二密钥的完整性，其中所述本地验证信息包括通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息。
在一种可选的设计中，所述客户端包括OEM密钥刷写装置，或者包括经销商诊断仪。
通过该方案，客户端作为密钥管理实体与第一电子控制单元之间的中间介质，可以将来密钥管理实体的第一信息转发给第一电子控制单元，进而实现第一密钥在第一电子控制单元侧的写入，再根据本地验证信息通过验证第一密钥的完整性间接实现对第二密钥完整性的验证。由于第一信息是通过第二密钥的信息指示第一密钥，因此保证了第二密钥不以明文形式暴露在密钥管理实体和电子控制单元之外，进而保证了整车厂核心资产的安全。此外，通过客户端作为中间介质实现对第二密钥的完整性验证，实现简单，适配整车产线组装、售后维修场景以及零部件开发商密钥刷写场景，进而可以降低密钥管理实体或整车厂的管理成本。
在一种可选的设计中，所述第一验证参数来自所述密钥管理实体，例如对应于来自所 述密钥管理实体的第二验证参数，即客户端将来自所述密钥管理实体的第二验证参数转发给第一电子控制单元，用于验证所述第一密钥的完整性；或者，所述第一验证参数包括所述客户端生成的信息。
在一种可选的设计中，所述本地验证信息来自所述密钥管理实体，例如对应于来自所述密钥管理实体的通过所述第一密钥对所述第二验证参数进行完整性保护得到的信息；或者所述本地验证信息是由所述客户端确定的信息。
结合第三方面，在第三方面的某些实现方式中，根据本地验证信息与所述第一验证信息，确定所述第二密钥的完整性，包括：若本地验证信息与所述第一验证信息匹配，则确定所述第二密钥是完整的；或者，若本地验证信息与所述第一验证信息不匹配，则确定所述第二密钥是不完整的。
通过该方案，客户端可以实现对第二密钥完整性的判断，进而判断功能密钥是否能被写入，以此保证功能密钥的正常使用。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：向所述第一电子控制单元发送第五信息，所述第五信息通过第五密钥的信息指示所述第二密钥，其中，所述第五密钥用于认证所述第二密钥。
通过该方案，可以满足整车产线和/或整车厂授权的维修方将第二密钥正确写入第一电子控制单元的需求，进而为后续功能密钥的写入提供认证条件，保证功能密钥的正常使用以及整车的信息安全。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：向所述密钥管理实体发送来自所述第一电子控制单元的第九信息，所述第九信息包括用于验证所述第一密钥完整性的信息；所述客户端不解析所述第九信息。
通过该方案，可以使密钥管理实体获取第一密钥的完整性验证结果，且客户端不解析所述第九信息还可以保证第一密钥的安全性，简化客户端操作。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：向所述密钥管理实体发送来自所述第一电子控制单元的第十信息，所述第十信息包括用于验证所述第二密钥完整性的信息；所述客户端不解析所述第十信息。
通过该方案，可以使密钥管理实体获取第二密钥的完整性验证结果，且客户端不解析所述第十信息还可以保证第一密钥的安全性，简化客户端操作。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：向所述密钥管理实体发送第二密钥更新请求信息，所述第二密钥更新请求信息用于请求更新所述第二密钥，或者用于请求验证所述第一电子控制单元本地保存的第二密钥的完整性。
通过该方案，可以辅助密钥管理实体通过该第二密钥更新请求信息，生成适配于第二密钥更新或第二密钥完整性验证的信息，进而实现第二密钥的完整性验证，保证功能密钥的正常使用以及整车的信息安全。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：向所述密钥管理实体发送所述第二密钥的更新结果。
通过该方案，可以辅助密钥管理实体获知第二密钥的更新情况，进而判断功能密钥是否能被写入，以此保证功能密钥的正常使用以及整车的信息安全。
结合第二方面和第三方面，在第二方面和第三方面的某些实现方式中，所述第二密钥更新请求信息包括如下信息中的一项或多项：所述客户端的身份认证信息，待更新第二密钥的电子控制单元的数量，电子控制单元所属的整车的识别码，电子控制单元本地保存的认证密钥的版本号，电子控制单元的版本号。
在一种可选的设计中，所述客户端的身份认证信息用于表征所述客户端具有从所述密钥管理实体获取密钥写入信息的权限，其中所述密钥写入信息包括如下信息中的一项或多项：所述第一信息，所述第五信息，所述第二验证信息。通过所述第二密钥更新请求信息中包含所述客户端的身份认证信息，可以保证密钥写入信息只提供给密钥管理实体授权的客户端，进而保证了密钥的安全性。
此外，通过所述第二密钥更新请求信息中包含如下信息中的一项或多项：待更新第二密钥的电子控制单元的数量，电子控制单元所属的整车的识别码，电子控制单元本地保存的认证密钥的版本号，电子控制单元的版本号，还便于密钥管理实体确定待写入的第二密钥，实现第二密钥的批量写入和/或第二密钥的批量完整性验证，降低密钥管理的成本。
结合第二方面和第三方面，在第二方面和第三方面的某些实现方式中，所述第二密钥的更新结果包括以下一项或多项：所述第二密钥的完整性信息，所述第一电子控制单元的身份标识，所述第一密钥的完整性信息，其中，所述第一电子控制单元的身份标识用于唯一标识所述第一电子控制单元。
通过该方案，密钥管理实体可以基于所述第二密钥的更新结果，确定所述第二密钥是否写入第一电子控制单元和/或确定第一电子控制单元本地保存的认证密钥是否为所述第二密钥，以此保证功能密钥的正常使用以及整车的信息安全。此外，通过收集所述第一电子控制单元的身份标识，还便于密钥管理实体实现对写入所述第二密钥的电子控制单元的管理。
结合第一方面、第二方面和第三方面，在第一方面、第二方面和第三方面的某些实现方式中，所述第一信息包括通过所述第二密钥的派生密钥进行加密和/或完整性保护得到的信息。
通过该方案，可以实现在第一密钥安全的情况下，将第一密钥写入到第一电子控制单元，以及保证第二密钥不以明文的形式暴露在密钥管理实体和电子控制单元之外。
结合第一方面、第二方面和第三方面，在第一方面、第二方面和第三方面的某些实现方式中，所述第一信息包括：至少通过所述第一电子控制单元的身份信息、所述第一密钥的索引和所述第二密钥的索引级联得到的第二信息，通过第三密钥对所述第一密钥加密得到的第三信息，以及通过第四密钥，对至少由所述第二信息和所述第三信息级联的信息进行完整性保护得到的第四信息，其中，所述第三密钥和所述第四密钥是所述第二密钥的派生密钥。
通过该方案，可以实现在第一密钥安全的情况下，将第一密钥写入到第一电子控制单元，以及保证第二密钥不以明文的形式暴露在密钥管理实体和电子控制单元之外，且实现简单。
结合第一方面、第二方面和第三方面，在第一方面、第二方面和第三方面的某些实现 方式中，所述第五信息包括通过所述第五密钥的派生密钥进行加密和/或完整性保护得到的信息。
通过该方案，可以实现在保证第二密钥安全的情况下，将第二密钥写入到第一电子控制单元。
结合第一方面、第二方面和第三方面，在第一方面、第二方面和第三方面的某些实现方式中，所述第五信息包括：至少通过所述第一电子控制单元的身份信息、所述第二密钥的索引和所述第五密钥的索引级联得到的第六信息，通过第六密钥对所述第二密钥加密得到的第七信息，以及通过第七密钥对至少由所述第六信息和所述第七信息级联的信息进行完整性保护得到的第八信息，其中，所述第六密钥和所述第七密钥是所述第五密钥的派生密钥。
通过该方案，通过该方案，可以实现在保证第二密钥安全的情况下，将第二密钥写入到第一电子控制单元，且实现简单。
结合第一方面、第二方面和第三方面，在第一方面、第二方面和第三方面的某些实现方式中，所述第一电子控制单元的身份信息包括所述第一电子控制单元的身份标识或者所述第一电子控制单元的组标识，其中，所述第一电子控制单元的身份标识用于唯一标识所述第一电子控制单元；所述第一电子控制单元的组标识用于标识所述第一电子控制单元所属的设备组。
在一种可选的设计中，所述第一电子控制单元的组标识中包含至少一个通配符。
通过该方案，基于第一电子控制单元的组标识，可以实现密钥管理实体对多个电子控制单元的第一密钥和/或第二密钥的批量写入，以及对第二密钥完整性的批量验证，简化流程，节省开销；基于第一电子控制单元的身份标识，可以实现点对点的第一密钥和/或第二密钥的写入，以及对第二密钥完整性的验证。
第四方面，提供了一种控制装置，所述控制装置包括用于执行上述第一方面的任一种可能实现方式中的方法的单元或模块，或者用于执行上述第二方面的任一种可能实现方式中的方法的单元或模块，或者用于执行上述第三方面的任一种可能实现方式中的方法的单元或模块。
第五方面，提供了一种控制装置，所述控制装置包括处理器和存储器。所述存储器用于存储计算机程序或指令，所述处理器用于调用所述存储器中的所述计算机程序或指令，以使得所述控制装置执行上述第一方面的任一种可能实现方式中的方法，或者用于执行上述第二方面的任一种可能实现方式中的方法，或者用于执行上述第三方面的任一种可能实现方式中的方法。在一种可选的设计中，该控制装置还包括通信接口，该通信接口与处理器耦合，该通信接口用于输入和/或输出信息，所述信息例如包含如下信息中的一项或多项：所述第一信息、所述第五信息、所述第一验证参数，所述第一验证信息，所述第二验证信息，所述第二密钥更新请求信息，所述第二密钥的更新结果。
在一种可选的设计中，所述处理器为一个或多个，所述存储器为一个或多个。
在一种可选的设计中，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。
结合第四方面和第五方面，在一种可选的设计中，用于执行上述第一方面的任一种可 能实现方式中的方法的控制装置可以为电子控制单元或者包含一个或多个电子控制单元的域控制器。
第六方面，提供了一种电子部件，所述电子部件包括实现上述第一方面的任一种可能实现方式中的方法的控制装置。示例性地，所述电子部件包括ECU。
第七方面，提供了一种车辆，所述车辆包括实现上述第一方面的任一种可能实现方式中的方法的控制装置，或者所述车辆包括上述第六方面提供的电子部件。
第八方面，提供了一种密钥管理实体，可以实现上述第二方面的任一种可能实现方式中的方法。在一种可选的设计中，所述密钥管理实体可以是密钥管理服务器。
第九方面，提供了一种密钥刷写工具，可以实现上述第三方面的任一种可能实现方式中的方法。在一种可选的设计中，所述密钥刷写工具可以是OEM密钥刷写工具或者经销商诊断仪。
第十方面，提供了一种系统，所述系统包括上述第六方面提供的电子部件，上述第七方面提供的车辆，上述第八方面提供的密钥管理实体或者上述第九方面提供的密钥刷写工具中的一个或多个。
第十一方面，提供了一种系统，所述系统包括用于执行上述第一方面的任一种可能实现方式中的方法的控制装置，用于执行上述第二方面的任一种可能实现方式中的方法的控制装置或者用于执行上述第三方面的任一种可能实现方式中的方法的控制装置中的一个或多个。
第十二方面，提供了一种芯片，所述芯片包括一个或多个处理器和接口电路，所述接口电路用于为所述一个或多个处理器提供信息输入和/或输出，所述芯片用于执行上述第一方面的任一种可能实现方式中的方法，或者用于执行上述第二方面的任一种可能实现方式中的方法，或者用于执行上述第三方面的任一种可能实现方式中的方法。
第十三方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被处理器执行时，使得所述处理器执行上述第一方面的任一种可能实现方式中的方法，或者用于执行上述第二方面的任一种可能实现方式中的方法，或者用于执行上述第三方面的任一种可能实现方式中的方法。
第十四方面，提供了一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，使得所述一个或多个处理器执行上述第一方面的任一种可能实现方式中的方法，或者用于执行上述第二方面的任一种可能实现方式中的方法，或者用于执行上述第三方面的任一种可能实现方式中的方法。
附图说明
以下对本申请实施例用到的附图进行介绍。
图1是本申请实施例提供的一种可能的密钥验证方法的网络架构；
图2为本申请实施例提供的一种可能的密钥验证方法的示意性流程图；
图3为本申请实施例提供的一种可能的密钥写入方法的示意性流程图；
图4为本申请实施例提供的一种可能的实现密钥更新请求和密钥更新结果的方法的示意性流程图；
图5为本申请实施例提供的一种可能的实现密钥验证信息的方法的示意性流程图；
图6为本申请实施例提供的又一种可能的实现密钥验证信息的方法的示意性流程图；
图7是本申请实施例提供的一种可能的控制装置的示意图；
图8是本申请实施例提供的另一种可能的控制装置的示意图；
图9是本申请实施例提供的一种可能的芯片结构的示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。需要说明的是，本申请中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
本申请中实施例提到的“至少一项(个)”是指一项(个)或者多项(个)，“多项(个)”是指两项(个)或两项(个)以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b、或c中的至少一项(个)，可以表示：a、b、c、(a和b)、(a和c)、(b和c)、或(a和b和c)，其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一信息和第二信息，只是为了区分不同的信息，而并不是表示这两种信息的内容、优先级、发送顺序或者重要程度等的不同。
首先，对本申请实施例中涉及的技术术语进行简单说明。
1.电子控制单元(Electronic Control Unit，ECU)
电子控制单元ECU也可以称为车载控制器，可用于控制整车使用中的各种功能。ECU例如可以包括但不限于：具有发动机控制功能的ECU、具有手柄控制功能的ECU、具有制动器控制功能的ECU。
示例性地，ECU还可以理解为具有完整性保护功能和加密功能且包括安全内存的电子单元。其中，安全内存可以基于非易失性存储(non-volatile memory，NvM)实现。安全内存具有严格的访问控制机制可以控制关键密钥材料的读取和使用。示例性地，安全内存例如为汽车开放系统架构(automotive open system architecture，AUTOSAR)安全硬件扩展(secure hardware extension，SHE)中的安全存储区。
需要说明的是，在某些技术场景中，具备相类似控制整车使用中的各种功能的电子单元的名称也可能不称为ECU，具有完整性保护功能和加密功能且包括安全内存的电子单元的名称也可能不称为ECU，但是为了方便描述，本申请实施例中将具有控制整车使用中的各种功能的电子单元统称为ECU，将具有完整性保护功能和加密功能且包括安全内存的电子单元也统称为ECU。
2.认证密钥
认证密钥用于功能密钥的认证，电子控制单元ECU只有拥有正确的认证密钥，才能实现功能密钥的写入和/或完整性验证。基于此，认证密钥还可以理解为功能密钥的认证密钥或功能密钥的权限密钥。示例性地，ECU具有正确的认证密钥，可以理解为，ECU本地保存的认证密钥与KMS本地保存的认证密钥相同。
此外，认证密钥除了可以用于功能密钥的认证，还可以用于认证ECU的硬件功能密钥，其中该硬件功能密钥也可以用于功能密钥的认证。示例性地，该认证密钥可以用于认证该认证密钥的后续版本所对应的密钥(作为硬件功能密钥的一例)。以认证密钥为ECU主密钥(master ECU key，MEK)为例，电子控制单元ECU只有拥有正确的MEK的在先版本，才能实现新版本的MEK的写入和/或完整性验证。具体地，如果当前密钥管理服务器保存的MEK最新版本为2.0(为便于描述，记为MEK2.0)，若使得该MEK2.0能够被成功写入目标ECU，需要该目标ECU拥有正确的MEK在先版本例如MEK1.0。基于此，认证密钥还可以理解为ECU硬件功能密钥的认证密钥或ECU硬件功能的权限密钥。
认证密钥可以对应一款车型包括的所有整车，或者也可以对应一台整车，或者也可以对应整车内的一个功能部件，或者对应整车内的一个ECU，相应地，一款车型包括的所有整车具有相同的认证密钥，不同车型的整车具有不同的认证密钥，或者一台整车具有一个认证密钥，不同整车具有不同的认证密钥，或者，整车内的一个功能部件具有一个认证密钥，该整车内的其他功能部件具有其他认证密钥，亦或者，整车内的一个ECU具有一个认证密钥，不同的ECU具有不同的认证密钥。这里的功能部件可以包括由多个ECU组成的功能部件，例如由多个ECU组成的用于座舱控制的功能部件。
在本申请实施例中，ECU主密钥MEK也可以称为ECU硬件权限密钥。
3.功能密钥
功能密钥也可以称为业务密钥，可用于加密整车中各类功能的ECU密钥，从而保障整车计算机系统的安全。功能密钥例如可以包括但不限于：预共享密钥(pre-shared key，PSK)，用于业务应用的主密钥(master key，MK)，会话密钥(session key，SK)。其中，PSK可以包含用于保护车载网络通信安全的板端加密通讯(security onboard communication，SecOC)的密钥(SecOC key)和用于设备认证的设备密钥(device key)。
在本申请实施例中，功能密钥可以是基于一台整车、一个业务来分配的。示例性地，对于一台整车而言，用于同一业务的一个或多个ECU可以共用同一个功能密钥。而对于不同的整车而言，同一业务的ECU可以是不同的。比如，若同一整车中的多个ECU用于板端加密通讯，该多个ECU可共用同一个功能密钥，该多个ECU相互之间均可基于该功能密钥来进行加密通信。具体的，相互通信的ECU之间，可以基于相同的功能密钥来对消息进行加密和解密，以达到对消息的加密和完整性保护。又比如，若同一整车中的多个ECU用于设备认证，该多个ECU也可共用同一个功能密钥。该多个ECU中的任意一个ECU基于该功能密钥来对该业务的其他ECU进行认证。
可以理解，用于板端加密通讯的功能密钥和用于设备认证的功能密钥是不同业务的密钥，因此是不同的密钥。在本申请实施例中，板端加密通讯和设备认证可以理解为不同业务。
此外，该功能密钥也可以基于更小的粒度来分配。示例性地，功能密钥可以是基于一台整车、一个业务、一对ECU来分配的。例如，若多个ECU用于同一业务，该多个ECU中的每两个ECU可以组成一对ECU。每对ECU可以共用一个功能密钥。具体地，比如该多个ECU包括ECU-1、ECU-2和ECU-3。ECU-1和ECU-2之间可共用同一个功能密钥，比如记为功能密钥1；ECU-2和ECU-3之间可共用另一个功能密钥，比如记为功能密钥2；ECU-1和ECU-3之间可共用功能密钥，比如记为功能密钥3。
4.消息认证码(message authentication code，MAC)
消息认证码(MAC)是密码学中通信实体双方使用的一种验证机制，是用于保证消息完整性的一种工具。示例性地，在发送消息之前，发送方首先使用通信双方协商好的完整性保护算法(或者还包括密钥)计算出MAC。之后，MAC和数据一起被发送。接收方收到该消息后，用和发送方同样的完整性保护算法(或者还包括密钥)计算出MAC，并比较自己计算的MAC和收到的MAC是否一致。若两者一致，则消息通过完整性验证。
5.完整性保护算法
MAC可以通过完整性保护算法来生成，该完整性保护算法也可以称为MAC算法或者完保算法。一般来说，完整性保护算法至少包含以下三个算法：(1)密钥生成算法，用于生成标签计算密钥和验证密钥,该标签计算密钥可以与该验证密钥相同(如用于消息认证码的密钥)，也可以不同(如用于数字签名(digital signature)的密钥)；(2)标签计算算法，以标签计算密钥、待保护信息为输入，产生对应于该待保护信息的保护标签；(3)验证算法，以验证密钥、标签计算密钥、待保护信息为输入，当且仅当验证通过时，输出逻辑真值。此外，完整性保护算法组还至少需满足以下两个性质。(1)正确性(correctness)，即使用标签计算密钥和标签计算算法所生成的保护标签必然可被验证密钥和验证算法所验证为真。(2)抗伪造性(unforgeability),即若攻击者不掌握标签计算密钥时，无法以非可忽略(non-negligible)的概率为待保护信息伪造标签。
示例性地，例如，基于哈希算法实现的完整性保护算法称为基于哈希的消息认证码(hash-based message authentication code，HMAC)算法，其中的哈希算法可以为MD5、SHA-1、SHA-256中的一个，或者为其他实现方式，不做具体限定。这些不同的HMAC实现通常可以标记为：HMAC-MD5,HMAC-SHA1,HMAC-SHA256。再如，基于密码算法来实现的MAC算法可以称为基于密码的消息认证码(Cipher-based Message Authentication Code，CMAC)算法，其中的分组加密算法可以为高级加密标准(Advanced Encryption Standard，AES)，由于AES分组加密的工作模式包括但不限于ECB,CBC,CFB,OFB，基于不同的工作模式的分组加密算法实现的完整性保护算法可以分别称为：ECB-MAC算法、CBC-MAC算法，CFB-MAC算法，OFB-MAC算法。此外，完整性保护算法还可以包括伽罗瓦消息验证码(Galois message authentication code mode，GMAC)、祖冲之密码算法(如ZUC128、ZUC256等)。
需要说明的是，在本申请实施例中，完整性保护算法可以有其他形式，不做具体限定。
6.加密算法
加密算法包括对称加密算法和非对称加密算法。通常来说，对称加密算法的加密密钥与解密密钥相同，非对称加密算法的加密密钥与解密密钥不同。常见的对称加密算法包括 但不限于：数据加密标准(data encryption standard，DES)、三重数据加密算法(triple data encryption algorithm，3DES)、AES；常见的非对称算法包括但不限于：RSA加密算法。
需要说明的是，在一些具体场景中，通过认证加密算法，对于给定的原文既可以加密数据也可以生成消息认证码，因此认证加密算法既可以作为加密算法也可以作为完保算法。例如，基于GMAC和计数加密模式的AES算法(AES-Galois/Counter Mode，AES-GCM)、基于CMAC和计数加密模式的AES算法(AES-CMAC/Counter Mode，AES-CCM)均可以对消息进行认证加密，而进行认证加密的过程中能够生成MAC来保护消息的完整性。
此外，还有一类不需要密钥的散列算法，比如用于基于加密算法或基于完保算法所生产的信息中的部分信息的生成。散列算法包括但不限于：安全散列算法(secure hash algorithm 1，SHA-1)、信息摘要(message digest，MD)算法(如MD2、MD4或MD5)。
7.密钥派生算法
密钥派生是从一个密钥中派生出一个或多个密钥的过程，而用于派生密钥的算法称为密钥派生算法(key derivation function，KDF)，又称为密钥导出算法。例如，通过密钥Key派生出的新的密钥可以表示为：DK＝KDF(Key)。常用的密钥派生算法包括但不限于：基于密码的密钥派生函数(password-based key derivation function，PBKDF)、斯克里普特(scrypt)算法。其中，PBKDF算法又包括第一代PBKDF1和第二代PBKDF2。
需要说明的是，在本申请各实施例中，为了方便描述各个密钥派生过程使用的KDF，会使用“第一KDF”、“第二KDF”和“第三KDF”进行描述，该“第一KDF”“第二KDF”和“第三KDF”可以是不同的KDF，也可以是相同的KDF。
8.挑战-应答机制
挑战-应答机制为认证协议中的一种模式。一个实现了挑战-应答机制的认证协议中通常包含2个参与方。挑战方(challenger)通常是需要验证对方身份的一方，应答方(responder)为需要自证身份的一方。
挑战-应答机制准则如下：挑战方将挑战(challenge)发送给应答方，应答方基于本地保存的认证信息(或秘密认证信息)和该挑战，确定相应的应答(response)发送给挑战方。挑战方结合挑战和自己持有的验证信息，来验证应答方是否通过了挑战，和/或判断应答方是否应该被认证。示例性地，挑战方可以将包含新鲜的随机字符串的信息或包含伪随机字符串的信息作为挑战。
其次，对本申请实施例的系统架构和业务场景进行描述。需要说明的是，本申请描述的系统架构及业务场景是为了更加清楚的说明本申请的技术方案，并不构成对于本申请提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请提供的技术方案对于类似的技术问题，同样适用。
请参见图1，图1是本申请实施例提供的一种可能的密钥验证方法的网络架构。如图1所示，该网络架构100可以包括密钥管理服务器，OEM密钥刷写装置(也可以称为OEM工具(OEM tool))、整车和ECU。KMS和OEM密钥刷写装置之间，OEM密钥刷写装置和ECU之间，均可以通过本地连接(例如本地局域网，硬件直接相连(比如密钥刷写装置与ECU直接))来通信，也可通过安全连接协议(比如，传输层安全协议(transport layer security specification，TLS)或虚拟专用网络(virtual private network，VPN))来通信，以 保证通信安全。
可以理解，对于整车生产而言，上述OEM具体可以是指整车制造商或代工厂。
应理解，图1仅为便于理解，示出了用于整车生产线中密钥写入/验证流程，但这不应对本申请构成任何限定。本申请提供的密钥写入/验证方法也可应用于售后服务中，比如用于售后服务的密钥更新流程。在应用于售后服务时，图1中的OEM密钥刷写装置可以替换为经销商诊断仪(也可以称为经销商诊断工具(tester tool))。上述KMS经销商诊断仪之间，经销商诊断仪与ECU之间也可通过本地连接或安全连接来通信。
可以理解，由于OEM服务器与经销商服务器的功能相似，应用场景不同，因此OEM服务器与经销商服务器的硬件结构可以是相似的。OEM密钥刷写装置与经销商诊断仪的功能相似，应用场景不同，因此OEM密钥刷写装置与经销商诊断仪的硬件结构也可以是相似的。
在一种可选的设计中，KMS还进一步包括KMS前置服务器和KMS后台服务器。KMS前置服务器主要负责与外部的通信，可理解为是KMS后台服务器与外部通信的接口。KMS后台服务器主要负责密钥生成、密钥查找等。KMS前置服务器与KMS后台服务器可以是物理上独立的两个设备，也可以集成在同一个物理设备中。本申请实施例对此不作限定。
还应理解，图1中示出了两辆车以及部署在每辆车上的一个或多个ECU。本申请对于该网络架构中的整车数量以及所部署的ECU的数量均不作限定。
需要说明的是，为了描述清楚，本申请各实施例中的下述内容以MEK作为认证密钥的一个示例进行描述，可以理解的是，MEK也可以替换为其他认证密钥。
由于MEK的密钥属性(例如MEK用作整车包括的功能密钥的认证密钥或权限密钥)，MEK可以认为是原始设备制造商(original equipment manufacturer，OEM)的核心资产，因此MEK禁止以明文的形式被外传泄露给第三方(例如部件开发商，OEM授权的经销商，售后4S店)，并且也不允许暴露在KMS之外。基于此，现有的整车厂通过在安全监控的环境下将MEK写入到电子控制单元中。在缺乏安全监控的情况下(例如当实现远程密钥刷写时)，MEK的安全性无法保证，有被篡改的风险。
鉴于此，本申请实施例提供一种密钥验证的方法，在该方法中，客户端接收来自密钥管理实体的第一信息，并向第一电子控制单元发送该第一信息，该第一信息通过第二密钥的信息指示第一密钥，该第二密钥被配置用于认证该第一电子控制单元的至少一个功能密钥，该至少一个功能密钥对应该第一电子控制单元的至少一个业务功能；该客户端还向该第一电子控制单元发送第一验证参数，该第一验证参数用于验证上述第一密钥的完整性。该第一电子控制单元接收来自该客户端的第一信息和第一验证参数，并根据第二密钥和该第一验证参数，生成第一验证信息，该第一验证信息用于表征该第一密钥的完整性；该第一电子控制单元向该客户端发送该第一验证信息。该客户端接收该第一验证信息，并根据该第一验证信息和本地验证信息，确定该第二密钥的完整性。该方案中，由于用于表征第一密钥完整性的第一验证信息是基于第二密钥和第一验证参数得到的，因此，可以通过第一密钥的完整性间接验证第二密钥的完整性，保证第二密钥的完整性以及安全性，防止第二密钥被篡改，进而保证功能密钥的正常使用以及整车的信息安全。此外，又由于第一信 息是通过第二密钥的信息指示第一密钥且第一信息是由客户端通过密钥管理实体转发给第一电子控制单元，因此避免了第二密钥以明文形式暴露在密钥管理实体和电子控制单元之外，进而保证了整车厂核心资产的安全。
下面结合具体实施例对本申请实施例提供的密钥验证方法进行介绍。需要说明的是，在本申请实施例中，对密钥进行验证可以包括验证该密钥的完整性，或可以理解为对该密钥进行完整性验证。示例性地，对该密钥进行完整性验证可以包括验证该密钥是否被完整写入ECU，或者是否被正确写入ECU。具体地，例如如果ECU的存储区域包括未经篡改的该密钥，则可以表示该密钥被正确写入或完整写入ECU。示例性地，这里的密钥包括功能密钥(例如SecOC key，device key)和/或认证密钥(例如MEK)。
请参见图2，图2是本申请实施例提供的一种可能的密钥验证方法的流程示意图。进一步的，该方法可以基于图1的架构来实现。该方法可以包括：
S201，密钥管理实体生成第一信息和第二验证信息。
在本申请实施例中，密钥管理实体用于管理密钥，例如密钥管理实体可以实现如下一项或多项功能：生成密钥、对密钥的授权使用、对密钥的注销管理。需要说明的是，这里的密钥包括车内使用的各种密钥，例如功能密钥和认证密钥，以及其他形式的密钥比如在密钥刷写过程中使用的临时密钥。
示例性地，该密钥管理实体可以为KMS，进一步地，该KMS受OEM管理，进而保证了车内使用的各种密钥的安全性；或者，该密钥管理实体也可以为包括KMS的OEM服务器，或者该密钥管理实体也可以为整车厂，或者该密钥管理实体也可以直接为OEM服务器。KMS的描述可以参考前述描述，此处不再赘述。此外，为了描述清楚，本申请各实施例以KMS作为密钥管理实体的一个示例进行描述，可以理解的是，KMS也可以替换为密钥管理实体的其他形式。
在本申请实施例中，第一信息通过第二密钥的信息指示第一密钥，其中，第二密钥被配置用于认证第一ECU的至少一个功能密钥，该至少一个功能密钥对应该第一ECU的至少一个业务功能。可替换地，第一信息与第二密钥相关联，或者第一信息与第二密钥的信息相关联。为了描述清楚，本申请各实施例以第一信息通过第二密钥的信息指示第一密钥来说明，应理解，第一信息与第二密钥相关联，或者第一信息与第二密钥的信息相关联，可以对应第一信息通过第二密钥的信息指示第一密钥的实现方式。
为了描述清楚，本申请各实施例以ECU-1作为第一ECU的一个示例进行描述，应理解，ECU-1也可以替换为第一ECU的其他表示形式。
示例性地，第二密钥为认证密钥，例如MEK。如前所述，MEK除了可以用于认证ECU-1的至少一个功能密钥，还可以用于认证ECU-1的硬件功能密钥。这里的硬件功能密钥可以是多个，也可以是一个，不做具体限定。作为一种可能的实现方式，该MEK可以从KMS处获取。
需要说明的是，ECU-1的至少一个功能密钥，可以包括如下一种实现方式：
方式1：ECU-1的一个功能密钥。进一步地，该功能密钥可以对应该ECU-1的一个或多个业务功能。例如，该功能密钥可以用于板端加密通讯和/或设备认证。
方式2：ECU-2的多个功能密钥。进一步地，例如该ECU-1可以用于多个业务，因此 该ECU可能具有多个功能密钥，这多个功能密钥可以对应该ECU-1的多个业务功能；又例如ECU-1的多个功能密钥也可以用于同一种业务，比如ECU-1和不同的ECU(例如ECU-2和ECU-3)进行车内通信时，可以使用不同的功能密钥(比如板端加密通讯密钥)实现板端加密通讯，即ECU-1和ECU-2之间可共用同一个功能密钥，比如记为功能密钥1；ECU-2和ECU-3之间可共用另一个功能密钥，比如记为功能密钥2。
此外，如前所述，MEK还可以被配置用于认证多个ECU的至少一个功能密钥，该至少一个功能密钥对应该多个ECU的至少一个业务功能。示例性地，该多个ECU的至少一个业务功能，可以包括如下一种实现方式：
方式A：多个ECU的一个功能密钥。进一步地，该功能密钥可以对应该多个ECU的一个或多个业务功能。例如，若多个ECU均用于板端加密通讯，则该多个ECU可以使用相同的功能密钥(比如板端加密通讯密钥)实现板端加密通讯，或者该功能密钥除了可以对应板端加密通讯，还可以用于设备认证。
方式B：多个ECU的多个功能密钥。进一步地，该多个功能密钥可以对应该多个ECU的一个业务功能或多个业务功能。例如，该多个ECU均可以用于板端加密通讯，但不同的ECU可以通过不同的功能密钥实现板端加密通讯；又例如，该多个ECU中有的ECU对应一种业务，有的ECU对应另外一种业务，此时这多个功能密钥可以分别对应不同的业务。
需要说明的是，在本申请实施例中，功能密钥对应业务功能，可以理解为，在实现该业务功能的过程中，会使用该功能密钥。
示例性地，第一密钥可以为功能密钥，或者为临时密钥。其中，临时密钥可以包括MEK或者功能密钥的派生密钥，用于加密和/或完整性保护产生的中间密钥。在本申请实施例中，为了实现对MEK的完整性验证，可以使用第一密钥作为中间密钥。在一种可能的实现方式中，该第一密钥可以从KMS处获取。示例性地，第一密钥可以是KMS预先生成并保存在本地维护的数据库中的密钥，也可以是随机生成的密钥。本申请实施例中对此不做限定。为了简化描述，本申请实施例中的下述内容以VRF_K作为第一密钥的一种表示形式进行描述，可以理解的是，第一密钥也可以具有其他的表示形式。
在一种可能的实现方式中，第一信息包括通过MEK进行加密和/或完整性保护得到的信息。基于此，KMS可实现第一信息通过第二密钥的信息指示第一密钥。示例性地，例如第一信息可以包括通过加密算法和/或完整性保护算法，基于认证密钥MEK以及待写入的密钥VRK_K生成的信息，且该第一信息可以用于写入第一密钥。
在又一种可能的实现方式中，第一信息包括通过MEK的派生密钥进行加密和/或完整性保护得到的信息。基于此，KMS可以实现第一信息通过第二密钥的信息指示第一密钥。第一信息可以是通过MEK的一个或多个派生密钥进行加密和/或完整性保护计算所得到的信息，进一步地，在一种可选的设计中，该第一信息可以用于写入VRK_K。由于第一信息包括通过MEK的派生密钥进行加密和/或完整性保护得到的信息，因此保证了MEK没有以明文形式暴露在KMS之外，保证了MEK的安全性。需要说明的是，在本申请各实施例中，通过MEK的派生密钥进行完整性保护得到的信息，可以包括通过MEK的派生密钥结合完整性保护算法中的一个算法或多个算法得到的信息，本申请实施例不做具体限定。例如通过MEK的派生密钥结合完整性保护算法中的标签计算算法得到的信息，可以理解为 通过MEK的派生密钥进行完整性保护得到的信息。应理解，一个派生密钥可以用于加密和完整性保护计算，或者也可以只用于加密或者完整性保护计算。基于此，当一个派生密钥仅用于加密或者完整性保护计算时，第一信息需要通过MEK的多个派生密钥实现加密和完整性保护计算。
示例性地，KMS可以通过KDF，基于MEK、参数Key_update_ENC_C以及Key_update_MAC_C，派生出与MEK对应的K1’、K2’两个派生密钥，这两个派生密钥分别用于加密和完整性保护。其中，参数Key_update_ENC_C和Key_update_MAC_C的具体取值可以是预定义的，比如在相关的技术规范中预定义。所述技术规范例如可以AUTOSAR组织发布的安全硬件扩展SHE技术规范。K1’、K2’例如可通过如下公式(1)和公式(2)实现：
K1’＝第一KDF(MEK，Key_update_ENC_C)           公式(1)
K2’＝第一KDF(MEK，Key_update_MAC_C)          公式(2)
此后，KMS可以通过加密算法基于上述K1’对VRK_K加密得到第一信息中包括的第三信息，例如KMS使用AES算法实现K1’对VRK_K的加密；KMS还可以使用MAC算法基于K2’对VRF_K进行完整性保护得到第一信息中包括的第四信息。应理解，加密算法和完整性保护算法包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
进一步地，KMS还可以将ECU-1的身份信息、VRF_K的索引以及MEK的索引级联，以得到第一信息中包括的第二信息。
其中，VRF_K的索引可以用于唯一标识VRF_K，MEK的索引可以用于唯一标识MEK。应理解，不同的密钥在ECU内需要分别保存，以保证不同的密钥不会相互覆盖，进而保证不同密钥的正常使用。基于此，在一种可选的设计中，VRF_K的索引也可以理解为用于指示该VRF_K在ECU-1内保存的地址信息，类似地，MEK的索引可以用于指示MEK在ECU-1内保存的地址信息。不同密钥在ECU内保存的地址信息例如可在相关的技术规范中预定义，比如在SHE技术规范中，规定了MEK对应的地址信息为0x1，KEY1～KEY10对应的地址信息分别为0x4～0xd，RAM_KEY对应的地址信息为0xe，这里KEY1～KEY10可以对应功能密钥，RAM_KEY可以对应临时密钥。
ECU-1的身份信息为该ECU-1的身份标识或者为ECU-1的组标识。
在本申请实施例中，ECU-1的身份标识用于唯一标识该ECU-1。示例性地，ECU-1的身份标识包括：ECU-1的设备识别码和该ECU-1的设备类型。其中，ECU-1的设备识别码例如可以是零件编号(part number，PART#)，ECU-1的设备类型例如可以包括但不限于：发动机管理系统(engine management system，EMS)、自动变速箱控制单元(transmission control unit，TCU)、车身控制模块(body control module，BCM)、电子稳定控制系统(electronic stability program，ESP)、电池管理系统(battery management system，BMS)、整车控制器(vehicle control unit，VCU)等。在有些情况下，ECU-1的设备识别码中可以包括该ECU-1的设备类型的指示信息，在这种情况下，ECU-1可以直接由设备识别码来标识。
在本申请实施例中，ECU-1的组标识用于标识该ECU-1所属的设备组，该设备组中包括的所有ECU具有公共的属性。示例性地，ECU-1的组标识可以用于标识该ECU-1对应 的产线批次，对应地，该ECU-1所属的设备组中包括的所有ECU属于相同的产线批次；和/或ECU-1的组标识可以用于标识该ECU-1对应的设备类型，对应地，该ECU-1所属的设备组中包括的所有ECU对应相同的设备类型；和/或，该ECU-1的组标识可以用于标识该ECU-1对应的业务功能，对应地，该ECU-1所属的设备组中包括的所有ECU对应相同的业务功能。例如，ECU的设备识别码由W位数字组成，其中的W1位数字表示该ECU对应的以下一项或多项：产线批次，设备类型，业务功能，W2位数字表示该ECU不同于该设备组中的其他ECU所特有的信息，W＝W1+W2。在这种情况下，ECU-1的组标识中可以包括至少一个通配符，用于表示该设备组中包括的所有ECU各自对应的特有信息，该通配符可以通过特殊字符例如#、％、#等实现，也可以通过特殊的数字组合例如全0数字组合实现。应理解，基于ECU-1的组标识中包括通配符，可以实现第二信息对多个ECU有效，进而实现KMS对多个ECU的第一密钥的批量刷写，节省了信令开销。
为了进一步地理解第一信息是如何通过MEK的信息指示VRF_K，下述示例了一种第一信息的实现方式。具体的，第一信息包括第二信息M1’、第三信息M2’以及第四信息M3’，示例性地，例如第一信息可以表示为M1’||M2’||M3’。其中M1’可以为M1’＝UID||VRF_K_ID||MEK_ID，UID表示ECU-1的身份信息，VRF_K_ID和MEK_ID分别表示第一密钥的索引和MEK的索引，||表示信息级联运算，例如A||B表示将信息A和B级联。M2’可以为M2’＝ENC CBC,K1’,IV’＝0(C ID’||F ID’||VRF_K)，即KMS将C ID’、F ID'和VRF_K级联后，再以K1’为密钥通过CBC模式加密形成第三信息。M3’可以为M3’＝CMAC K2’(M1’||M2’)，即KMS通过将M1’和M2’级联后，再以K2’为密钥经过CMAC计算而成的MAC值即为M3’。在上述过程中，K1’和K2’均为MEK的派生密钥。C ID’是由KMS本地的计数器(count，CNT)输出的计数值，可用于计数，每次加密前可以自动加1，后续通过验证接收到的CNT与本地生成的CNT的大小关系，可以达到防重放攻击的目的，所谓的重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。F ID’用于配置VRF_K_ID所对应的存储区域的安全标志，安全标志例如可以包括AUTOSAR技术规范中定义的安全标志，该安全标志可以包括写保护标志(WRITE_PROTECTION)，启动保护标志(BOOT_PROTECTION)，调试保护标志(DEBUGGER_PROTECTION)，密钥用途标志(KEY_USAGE)，通配符标志(WILDCARD)，IV’＝0表示基于CBC模式加密所使用的初始化向量为全0向量。需要说明的是，在本申请实施例中，上述级联信息除了包括如上信息之外，还可以包括其他信息，本申请实施例不做具体限定。应理解，在此列举的用于生成M2’的加密算法和用于生成M3’的MAC算法仅为示例，不应对本申请实施例构成任何限定，加密算法和完整性保护算法还可以包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
在本申请实施例中，第二验证信息包括用于VRF_K完整性验证的信息。例如，第二验证信息包括VRF_K，该VRF_K可用于VRF_K的完整性验证，具体地，客户端可以通过接收该VRF_K再结合本地生成的第一验证参数，确定本地验证信息，该本地验证信息可以用于VRF_K和/或MEK的完整性验证。又例如，第二验证信息包括第二验证参数，以及通过VRF_K对第二验证参数进行完整性保护得到的信息，其中第二验证参数用于验证VRF_K的完整性，第二验证参数可以是KMS随机生成的信息，也可以是KMS按照一定的规则生 成的信息，或者通过其他方式生成的信息，这里不做具体限定。在一种可选的设计中，第二验证参数(比如记为VRF_M)与通过VRF_K对第二验证参数进行完整性保护得到的信息(比如记为VRF_MAC)满足如下关系：VRF_MAC＝CMAC VRF_K(VRF_M)。KMS以VRF_K为密钥经过CMAC计算生成VRF_K的完整性验证信息(即VRF_MAC)，VRF_MAC可以用于表征VRF_K的完整性。
S202，密钥管理实体向客户端发送第一信息和第二验证信息。
相应地，该客户端接收来自密钥管理实体的第一信息和第二验证信息。
在本申请实施例中，客户端可以用于密钥刷写，即通过客户端可以实现密钥(比如认证密钥、认证密钥以及其他临时密钥)写入到整车内的ECU中。客户端例如可以为OEM密钥刷写装置或者为经销商诊断仪或者为车载诊断(On Board Diagnostics，OBD)。OEM密钥刷写装置也可以被称为OEM诊断工具，或者被称为OEM诊断仪，经销商诊断仪也可以被称为经销商密钥刷写装置，本申请实施例不做具体限定。此外，客户端还可以包括OEM服务器或者包括经销商服务器。
示例性地，如果客户端为OEM密钥刷写装置，KMS向客户端发送第一信息和第二验证信息，可以包括：KMS直接向OEM密钥刷写装置发送第一信息和第二验证信息，或者KMS先将第一信息和第二验证信息发送给OEM服务器，再由OEM服务器将该第一信息和第二验证信息转发给该OEM密钥刷写装置。
示例性地，如果客户端包括OEM服务器和OEM密钥刷写装置，KMS向客户端发送第一信息和第二验证信息，可以包括：KMS直接向客户端发送第一信息和第二验证信息。进一步地，OEM服务器可以接收来自KMS的第一信息和第二验证信息，然后再将其转发给OEM密钥刷写装置。应理解，在这种情况下，上述的密钥管理实体可以不包括OEM服务器。
示例性地，如果客户端为经销商诊断仪，KMS向客户端发送第一信息和第二验证信息，可以包括：KMS直接向经销商诊断仪发送第一信息和第二验证信息，或者KMS先将第一信息和第二验证信息发送给OEM服务器或者经销商服务器，再由该OEM服务器或者该经销商服务器将该第一信息和第二验证信息转发给该经销商诊断仪。
示例性地，如果客户端包括经销商服务器和经销商诊断仪，KMS向客户端发送第一信息和第二验证信息，可以包括：KMS直接向该客户端发送第一信息和第二验证信息。进一步地，经销商服务器可以接收来自KMS或者来自OEM服务器的第一信息和第二验证信息，然后再将其转发给经销商诊断仪。其中，在后一种情况下，OEM服务器可以先从KMS处接收第一信息和第二验证信息。
为了描述清楚，本申请各实施例以OEM密钥刷写装置作为客户端的一个示例进行描述，可以理解的是，OEM密钥刷写装置也可以替换为客户端的其他形式。
在本申请实施例中，第一信息可以应用于一个ECU，或者应用于多个ECU，第二验证信息可以应用于一个ECU，或者应用于多个ECU。示例性地，例如待进行MEK完整性验证的ECU包括ECU-1、ECU-2和ECU-3，一种情况下，这三个ECU可以对应相同的VRF_K，相应地，KMS可以通过相同的第一信息指示第一密钥，并且这三个ECU对应的第二验证信息也是相同的；另外一种情况下，这三个ECU可以对应不同的VRF_K，相应地，这三 个ECU对应的第一信息彼此不同，对应的第二验证信息也彼此不同。
应理解，KMS可以将第一信息和第二验证信息携带在同一条信令中发送，或者也可以通过不同的信令分别发送第一信息和第二验证信息。如果第一信息中包括多个信息，例如第一信息包括第二信息、第三信息以及第四信息，KMS可以用不同的信令分别发送第一信息中包括的不同信息，或者也可以通过同一条信令发送该第一信息包括的所有信息。此外，如果不同的ECU对应不同的第一密钥，相应地，基于该第一密钥生成的第一信息和第二验证信息也是不同的，例如记为第一信息-1，第一信息-2和第一信息-3，以及第二验证信息-1、第二验证信息-2，第二验证信息-3。在这种情况下KMS可以将不同的第一信息和不同的第二验证信息携带在同一条信令中发送，也可以通过不同的信令分别发送第一信息-1，第一信息-2以及第一信息-3、和第二验证信息-1、第二验证信息-2以及第二验证信息-3，或者也可以通过不同的信令将各自ECU所对应的第一信息和第二验证信息分别发送给OEM密钥刷写装置，比如通过信令1将第一信息-1和第一验证信息-1、通过信令2将第一信息-2和第一验证信息-2、通过信令3将第一信息-3和第一验证信息-3发送给OEM密钥刷写装置，进一步地，OEM密钥刷写装置可以将这些信息分别发送给各自对应的ECU。KMS还可以通过其他方式发送第一信息和第二验证信息，本申请实施例在此不做具体限定。
S203，OEM密钥刷写装置向ECU-1发送第一信息和第一验证参数。
相应地，ECU-1接收第一信息和第一验证参数。
OEM密钥刷写装置将来自KMS的第一信息转发给ECU-1，以使得ECU-1可以基于第一信息确定VRF_K。
需要说明的是，在本申请各实施例中，转发可以理解为透传，即在此场景下，OEM密钥刷写装置可以将来KMS的第一信息直接透传给ECU-1，在此过程中，OEM密钥装置对第一信息不做任何处理。
在本申请实施例中，第一验证参数用于验证VRF_K的完整性。例如，第一验证参数为第二验证参数，即OEM密钥刷写装置可以将来自KMS的第二验证参数直接转发给第一ECU。又例如，第一验证参数为OEM密钥刷写装置生成的信息，比如OEM密钥刷写装置随机生成的信息，又比如OEM密钥刷写装置按照一定的规则生成的信息。此外，OEM密钥刷写装置也可以通过其他方式生成第一验证参数，这里不做具体限定。应理解，第一验证参数也可以应用于多个ECU，即对于包括ECU-1的多个ECU而言，第一验证参数可以是相同的。
应理解，OEM密钥刷写装置将第一信息和第一验证参数携带在同一条信令中发送，节省信令开销，或者也可以通过不同的信令分别发送第一信息和第一验证参数，实现第一信息和第一验证参数指示的灵活性。
需要说明的是，在本申请实施例中，OEM密钥刷写装置可以将第一信息和第一验证参数直接发送给该ECU-1，例如OEM密钥刷写装置直接与ECU-1相连，并将第一信息和第一验证参数发送给ECU-1；又或者，如果包括该ECU-1的功能部件支持转发机制，那么OEM密钥刷写装置可以将第一信息和第一验证参数先发送给包括该功能部件，再由功能部件通过内部的转发机制将第一信息和第一验证参数发送给ECU-1，这种情况下，可以理解的是，OEM密钥刷写装置可以与该功能部件直接相连。示例性地，该功能部件为包含一个 或多个ECU的域控制器(domain controller，DC)或者为车内的密钥管理系统。此外，在本申请各实施例中，域控制器也可以看为一个电子功能部件ECU，即该域控制器可以直接接收来自客户端的第一信息。
S204，ECU-1根据MEK和第一验证参数，生成第一验证信息。
其中，该第一验证信息用于表征第一密钥的完整性。
示例性地，ECU-1根据MEK和第一验证参数，生成第一验证信息，可以包括：ECU-1通过MEK对接收到的第一信息进行解密和/或完整性校验，以确定VRF_K，再根据该VRF_K与接收到的第一验证参数，生成用于表征第一密钥完整性的第一验证信息。进一步地，在一种可选的设计中，ECU-1通过MEK对接收到的第一信息进行解密和/或完整性校验，以确定VRF_K，可以包括：ECU-1先基于接收到的第一信息，确定通过MEK实现对该第一信息的解密和/或完整性校验，之后再通过本地保存的MEK对该第一信息执行具体的解密和/或完整性校验，进而确定VRF_K。此外ECU-1可以基于MAC算法，通过确定的VRF_K和第一验证参数，得到第一验证信息，例如第一验证信息(比如记为MAC_T)与第一验证参数(比如记为VRF_M)满足如下关系：MAC_T＝CMAC VRF_K(VRF_M)。
在一种可选的设计中，该ECU-1确定VRF_K之后，可以将VRF_K存储在本地。
对应于步骤S201中一种具体的第一信息实现方式，下述示例了一种ECU-1根据MEK和第一验证参数，生成第一验证信息的具体实现方式，在该例中，第一信息包括第二信息M1’、第三信息M2’以及第四信息M3’，其中M1’、M2’以及M3’具体实施方式可以参考步骤201中的相应描述，这里不做赘述。ECU-1根据接收到的M1’，确定MEK的索引(即MEK_ID)，基于此，ECU-1将本地保存的且与MEK_ID所对应的密钥作为MEK，用于VRF_K的完整性验证和解密。例如，ECU-1可以先基于在本地保存的MEK和接收到的M3’，完成对VRF_K或第一信息的完整性校验，以保证VRF_K或第一信息未经篡改。在对VRF_K或第一信息的完整性验证成功的情况下，ECU-1再根据在本地保存的MEK解密M2’，以确定VRF_K。在一种可选的设计中，ECU-1确定VRF_K之后，可以基于M1’中包括的VRF_K的索引所指示的地址信息，将解密M2’确定得到的VRF_K保存在对应该地址信息的本地内存中。进一步地，ECU-1在确定VRF_K之后，可以根据确定得到的VRF_K和第一验证参数，生成第一验证信息，具体生成过程可以参考上述描述，这里不做赘述。
需要说明的是，ECU-1根据MEK和M3’进行完整性校验，包括根据MEK的派生密钥进行完整性校验，ECU-1根据MEK解密M2’，包括根据MEK的派生密钥解密M2’。应理解，ECU-1在确定VRF_K的过程中使用的派生算法与KMS在确定第一信息的过程中使用到的派生算法相同，该派生算法可以为预先配置于ECU-1中的算法。
S205，ECU-1向OEM密钥刷写装置发送第一验证信息。
相应地，OEM密钥刷写装置接收该第一验证信息。
S206，OEM密钥刷写装置根据本地验证信息和该第一验证信息，确定MEK的完整性，其中本地验证信息为通过VRF_K和第一验证参数进行完整性保护得到的信息。
在一种可能的实现方式中，本地验证信息直接来自KMS，例如本地验证信息即为步骤201中第二验证信息包括的通过VRF_K对第二验证参数进行完整性保护得到的信息(比如记为VRF_MAC)。在这种情况下，第一验证参数可以为第二验证信息中包括的第二验证参 数。OEM密钥刷写装置将来自KMS的VRF_MAC与来自ECU-1的第一验证信息(比如记为MAC_T)相比较，根据比较结果确定MEK的完整性。基于上述描述，应理解，由于VRF_MAC是KMS基于VRF_K和第二验证参数得到的，而MAC_T是ECU-1基于在本地确定得到的VRF_K与第一验证参数得到的，因此通过比较VRF_MAC和MAC_T，可以确定ECU-1在本地确定得到的VRF_K与来自KMS的VRF_K是否相同。又因为来自KMS的VRF_K是通过MEK的信息指示的，而ECU-1在本地确定得到的VRF_K是基于本地保存的MEK确定的，因此等效地，通过比较VRF_MAC和MAC_T，可以确定ECU-1本地保存的MEK与KMS保存的MEK是否相同，进而实现了对ECU-1本地保存的MEK的完整性验证。具体的，若VRF_MAC与MAC_T相匹配(比如MAC_T＝＝VRF_MAC)，则可以确定ECU-1本地保存的MEK是完整的，否则，则可以确定ECU-1本地保存的MEK是不完整的。示例性地，MAC_T＝＝VRF_MAC可以表示MAC_T包括的每个比特位置的比特值与VRF_MAC包括的对应比特位置的比特值都相同。
需要说明的是，在一种可选的设计中，ECU-1本地保存的MEK是完整的，可以包括：ECU-1本地保存的MEK与KMS保存的MEK是相同的，或者ECU-1本地保存的MEK是有效的密钥。在一种可选的设计中，ECU-1本地保存的MEK是不完整的，可以包括：ECU-1本地保存的MEK与KMS保存的MEK不同，或者ECU-1本地保存的MEK不是有效的密钥。应理解，只有ECU-1本地保存的MEK是完整的，才能实现OEM密钥刷写装置基于MEK向该ECU-1写入功能密钥，进而保证该ECU-1在整车中的正常使用。
在又一种可能的实现方式中，本地验证信息是OEM密钥刷写装置在本地确定的信息。示例性地，OEM密钥刷写装置根据来自KMS的第二验证信息和在本地生成的第一验证参数确定本地验证信息，其中该第二验证信息中包括VRF_K。具体地，在这种方式下，本地验证信息(比如记为VRF_MAC)与第一验证参数(比如即为VRF_M)满足：VRF_MAC＝CMAC VRF_K(VRF_M)。类似地，由于VRF_MAC是OEM密钥刷写装置根据来自KMS的VRF_K与本地生成的第一验证参数得到的，而MAC_T是ECU-1基于在本地确定得到的VRF_K与来自OEM密钥刷写装置的第一验证参数得到的，因此在这种方式下，通过比较VRF_MAC和MAC_T，也可以确定ECU-1在本地确定得到的VRF_K与来自KMS的VRF_K是否相同。进而等效地，通过比较VRF_MAC和MAC_T，可以确定ECU-1本地保存的MEK与KMS保存的MEK是否相同，从而实现了对ECU-1本地保存的MEK的完整性验证。通过VRF_MAC和MAC_T的比较结果，确定MEK完整性的具体实现可以参考上述描述，不做具体赘述。
基于上述描述，可以理解的是，本申请实施例通过第一密钥的完整性间接验证了第二密钥的完整性，不仅实现了对第二密钥的完整性验证，保证了功能密钥的正常使用以及整车的信息安全，而且由于介于KMS与ECU-1之间的OEM密钥刷写装置是通过直接转发来自KMS的第一信息来指示第一密钥，因此，避免了第二密钥以明文形式暴露在KMS和ECU之外，进而保证了整车厂核心资产的安全。此外，用于第一密钥完整性验证的信息中不包括ECU的标识信息，因此，整车产线不需要提前收集待更新第二密钥的所有目标ECU的标识信息，从而降低了整车产线的负担和管理成本。进一步地，KMS还可以预先准备好用于第一密钥完整性验证的灌装密钥材料(例如上述实施例中的第一信息和第二验证信息)， 并将其提前发送给OEM密钥刷写装置，基于此还可以实现对ECU的第二密钥的离线验证，即不依赖于KMS，也可以实现第二密钥完整性的实时验证，减少了时间开销。应理解，通过该方案，也避免了在现有的整车产线就近部署KMS，简化了整车产线的设计，降低了整车厂的管理成本。
通过图2所示的密钥验证方法，可以实现对第二密钥的完整性验证。在一种可选的设计中，KMS在发送第一信息之前，还可以通过客户端先将第二密钥写入到ECU中。示例性地，当ECU本地保存的第二密钥与KMS保存的第二密钥不同时，为了保证ECU的功能密钥的正常使用，KMS需要先将KMS本地保存的第二密钥写入到ECU中。例如，在整车生产过程中，OEM可以先将一些预置根密钥传递给部件开发商(例如Tier1零部件开发商)，由部件开发商先将这些预置根密钥写入到ECU中作为ECU的初始硬件权限密钥。然后这些已写入预置根密钥的ECU被运输到整车产线，OEM在整车产线再将ECU的预置根密钥替换为MEK，从而保证功能密钥可以写入到ECU中，保证ECU的正常使用。应理解，由于MEK的密钥属性，在此场景下，ECU本地保存的第二密钥(可以理解为预置根密钥，或初始硬件权限密钥)与KMS保存的第二密钥(待写入的MEK)不同；又例如，在整车的使用过程中，不可避免存在硬件损坏或者硬件升级的状况，此时要求由OEM或者部件开发商授权的维修方(例如4S店)将已损坏或者需要升级的ECU替换为新的ECU，应理解，在此场景下，新的ECU本地保存的第二密钥与KMS保存的第二密钥可以不同。此时为了保证替换后的ECU可以正常工作，需要给新的ECU写入功能密钥，而如前所述，功能密钥的成功写入需要认证密钥对其先进行认证，因此需要4S店先通过密钥刷写装置将KMS保存的第二密钥写入到ECU中。KMS将第二密钥写入到ECU之后，再基于图2所示的实施例中的方法，实现对第二密钥的完整性验证。
基于此，作为一种可能的实现方式，本申请实施例所述的密钥验证方法，还可以包括图3所示的步骤S301-S304，这些步骤可用于向ECU写入第二密钥，对于某些具体的场景可以是必须的。
需要说明的是，为了更好地理解下述各实施例所述的方法与上述图2所示的实施例中的方法之间的关系，下文仍以ECU-1为第一ECU的一个示例，KMS为密钥管理实体的一个示例，OEM密钥刷写装置为客户端的一个示例，MEK作为第二密钥的一个示例，VRF_K作为第一密钥的一个示例进行说明。步骤S301-S304具体如下：
S301，KMS生成第五信息。
其中，第五信息通过第五密钥的信息指示MEK，第五密钥用于认证MEK。示例性地，第五密钥可以为预置于ECU-1中的预备ECU主密钥(pre-master ECU key，PMEK)，或者也可以为ECU-1本地保存的MEK的在先版本。例如，KMS本地保存的MEK为MEK2.0，而ECU-1中本地保存的MEK的在先版本为MEK1.0，此时需要通过ECU-1本地保存的MEK1.0的认证，才可以将ECU-1中的MEK1.0替换为MEK2.0，进而保证该ECU-1功能密钥的正常使用。为了描述清楚，本申请各实施例中以PMEK作为第五密钥的一个示例进行描述，可以理解的是，PMEK也可以替换为其他用于认证MEK的认证密钥。
在一种可能的实现方式，第五信息通过PMEK的信息指示MEK，可以包括：第五信息包括通过PMEK进行加密和/或完整性保护计算得到的信息。基于此，KMS可实现第五 信息通过PMEK的信息指示第二密钥。示例性地，例如第五信息可以包括通过加密算法和/或完整性保护算法，基于认证密钥PMEK以及待写入的密钥MEK生成的信息，且该第五信息可以用于写入MEK。
在又一种可能的实现方式中，第五信息通过PMEK的信息指示MEK，可以包括：第五信息包括通过PMEK的派生密钥进行加密和/或完整性保护得到的信息。基于此，KMS可以实现第五信息通过PMEK的信息指示MEK。第五信息可以是通过PMEK的一个或多个派生密钥进行加密和/或完整性保护计算所得到的信息且该第五信息可以用于写入MEK。这里，一个派生密钥可以同时用于加密和完整性保护计算，或者也可以只用于加密或者完整性保护计算。应理解，当一个派生密钥仅用于加密或者完整性保护计算时，第五信息需要通过PMEK的多个派生密钥实现加密和完整性保护计算。
示例性地，KMS可以通过KDF，基于PMEK、参数Key_update_ENC_C以及Key_update_MAC_C，派生出与PMEK对应的K1、K2两个派生密钥，这两个派生密钥分别用于加密和完整性保护。其中，参数Key_update_ENC_C和Key_update_MAC_C的具体取值可以是预定义的，比如在相关的技术规范中预定义。所述技术规范例如可以是AUTOSAR组织发布的SHE技术规范。K1、K2例如可通过如下公式(3)和公式(4)实现：
K1＝第二KDF(PMEK，Key_update_ENC_C)           公式(3)
K2＝第二KDF(PMEK，Key_update_MAC_C)          公式(4)
此后，KMS可以通过加密算法基于上述K1对MEK加密得到第五信息中包括的第七信息，例如KMS使用AES算法实现K1对MEK的加密；KMS还可以使用MAC算法基于K2对MEK进行完整性保护得到第五信息中包括的第八信息。应理解，加密算法和完整性保护算法包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
进一步地，KMS还可以将ECU-1的身份信息、MEK的索引以及PMEK的索引级联，以得到第五信息中包括的第六信息。其中，ECU-1的身份信息以及MEK的索引可参考上述S201中的具体描述，此处不再赘述。PMEK的索引用于唯一标识PMEK，可以用于指示PMEK在ECU-1内保存的地址信息。需要说明的是，当ECU-1的身份信息为包含通配符的组标识时，可以实现第五信息对多个ECU有效，进而实现KMS对多个ECU的第二密钥的批量刷下，节省了信令开销。
为了进一步地理解第五信息是如何通过PMEK的信息指示MEK，下述示例了一种第五信息的实现方式。具体的，第五信息包括第六信息M1、第七信息M2以及第八信息M3。其中M1可以为M1＝UID||MEK_ID||PMEK_ID，UID表示ECU-1的身份信息，MEK_ID和PMEK_ID分别表示MEK的索引和PMEK的索引，||表示信息级联运算，例如A||B表示将信息A和B级联。M2可以为M2＝ENC CBC,K1,IV＝0(C ID||F ID||MEK)，即KMS将C ID、F ID和MEK级联后，再以K1为密钥通过CBC模式加密形成第七信息。M3可以为M3＝CMAC K2(M1||M2)，即KMS通过将M1和M2级联后，再以K2为密钥经过CMAC计算而成的MAC值即为M3。在上述过程中，K1和K2均为PMEK的派生密钥。C ID是由KMS本地的计数器CNT输出的计数值，可用于计数，每次加密前可以自动加1，后续通过验证接收到的CNT与本地生成的CNT的大小关系，可以达到防重放攻击的目的。F ID用于配置 MEK_ID所对应的存储区域的安全标志，安全标志的具体说明可以参考S201中的相关说明，这里不做赘述。IV＝0表示基于CBC模式加密所使用的初始化向量为全0向量。需要说明的是，在本申请实施例中，上述级联信息除了包括如上信息之外，还可以包括其他信息，本申请实施例不做具体限定。应理解，在此列举的用于生成M2的加密算法和用于生成M3的MAC算法仅为示例，不应对本申请实施例构成任何限定。本领域的技术人员可知，加密算法和完整性保护算法还可以包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
S302，KMS向OEM密钥刷写装置发送第五信息。
相应地，OEM密钥刷写装置接收该第五信息。类似地，如果第五信息中包括多个信息，例如第五信息中包括第六信息、第七信息以及第八信息，KMS可以用不同的信令分别发送第五信息中包括的不同信息，或者也可以通过同一条信令发送第五信息中包括的所有信息。此外，KMS还可以将第五信息(或第五信息中包括的部分信息)与其他发送给OEM密钥刷写装置的信息(比如第一信息或者第一信息中包括的部分信息)携带在同一条信令中发送，或者也可以通过不同的信令发送。本申请实施例对实现第五信息发送的具体方式不做限定。
S303，OEM密钥刷写装置向ECU-1发送该第五信息。
相应地，ECU-1接收该第五信息。OEM密钥刷写装置将来自KMS的第五信息转发给ECU-1，以使得ECU-1可以基于第五信息确定MEK。OEM密钥刷写装置向ECU-1发送第五信息的具体实现方式可以参考S203中的相应描述，这里不做赘述。
S304，ECU-1根据该第五信息，确定MEK。
示例性地，ECU-1根据该第五信息，确定MEK，可以包括：ECU-1根据PMEK，对接收到的第五信息进行解密和/或完整性校验，以确定MEK。具体地，例如ECU-1先基于接收到的第五信息，确定通过PMEK实现对第五信息的解密和/或完整性校验，之后再通过本地保存的PMEK对该第五信息执行具体的解密和/或完整性校验，进而确定MEK。
对应于步骤S301中一种具体的第五信息实现方式，下述示例了一种ECU-1根据第五信息，确定MEK的具体实现方式，在该例中，第五信息包括第六信息M1、第七信息M2以及第八信息M3，其中M1、M2以及M3的具体实施方式可以参考步骤S301中的相应描述，这里不做赘述。ECU-1根据接收到的M1，确定PMEK的索引(即PMEK_ID)，基于此，ECU-1将本地保存的且与PMEK_ID所对应的密钥作为PMEK，用于MEK的完整性验证和解密。例如，ECU-1可以先基于在本地保存的PMEK和接收到的M3，完整对MEK或第五信息的完整性校验，以保证MEK或者第五信息未经篡改。在对MEK或第五信息的完整性验证成功的情况下，ECU-1再根据在本地保存的PMEK解密M2，以确定MEK。
进一步地，该ECU-1确定MEK之后，将MEK存储在本地。示例性地，ECU-1可以基于M1中包括的MEK的索引(即MEK_ID)所指示的地址信息，将解密M2确定得到的MEK保存在对应该地址信息的本地内存中，或者将本地保存的PMEK替换为该MEK。
基于图3所示的实施例中的方法，在验证MEK之前，可以先将MEK写入到ECU中，从而满足整车产线和/或整车厂授权的维修方将MEK正确写入第一电子控制单元的需求，进而为后续功能密钥的写入提供认证条件，保证功能密钥的正常使用以及整车的信息安全。 上述描述的MEK写入ECU的方法可以适配于MEK待写入的各种场景，通过适配于各种场景的统一解决方案，可以简化密钥管理实体或整车厂的密钥管理流程，简化密钥写入流程。此外，由于第二信息包括通过对MEK进行加密和/或完整性保护得到的信息，也可以避免在MEK写入过程中，MEK以明文形式暴露在KMS和ECU之外，进而保证了整车厂核心资产的安全。
进一步地，在一种可选的设计中，本申请各实施例中所述的密钥验证方法，还可以包括图4所示的步骤S401-S404中的一个或多个步骤，该一个或多个步骤对于某些具体场景可以是必须的。步骤S401-S404具体如下：
步骤S401，OEM密钥刷写装置向KMS发送MEK更新请求信息。
相应地，KMS接收该MEK更新请求信息。
该MEK更新请求信息用于请求更新ECU-1的MEK。可替换地，该MEK更新信息可以用于请求KMS验证ECU-1本地保存的MEK完整性，或者该MEK更新请求信息可以用于请求KMS将MEK写入至ECU-1(包括对MEK的完整性验证)。
在一种可选的设计中，该MEK更新请求信息中还可以包括如下信息中的一项或多项：OEM密钥刷写装置的身份认证信息，待更新MEK的ECU的数量(或者待验证MEK完整性的ECU的数量)，ECU所属的整车的识别码VIN，ECU本地保存的认证密钥的版本号，ECU的不同版本号。其中，该身份认证信息可以用于表征该OEM密钥刷写装置是否有权限获取本申请各实施例中所包括的客户端从密钥管理实体获取的一项或多项信息，例如第一信息、第五信息、第二验证信息。VIN可以用于标识一台整车。ECU的不同版本号可用于标识该ECU本地保存的认证密钥的版本号，例如本地保存的认证密钥为PMEK，或者为MEK1.0，或者为MEK2.0等。应理解，上述待更新MEK的ECU或者带验证MEK完整性的ECU中包括ECU-1。
步骤S402，KMS校验该MEK更新请求信息。
相应地，KMS在接收到该MEK更新请求信息后，可以校验该MEK更新请求信息。并根据校验结果，确定是否通过或确定通过上述本申请实施例中所述的方法，将用于指示第一密钥的第一信息和用于该第一密钥完整性验证的第二验证信息发送给OEM密钥刷写装置，或者将用于指示第一密钥的第一信息、用于该第一密钥完整性验证的第二验证信息以及用于指示第二密钥的第五信息发送给OEM密钥刷写装置。
在一种可选的设计中，KMS校验该MEK更新请求信息，可以包括如下一项或多项：KMS校验该MEK更新请求信息的合法性，KMS确定用于写入MEK(包括对MEK的完整性验证)的具体信息，KMS确定用于验证MEK完整性的具体信息。
示例性地，KMS校验该MEK更新请求信息的合法性可以理解为：KMS确定发起该MEK更新请求信息的OEM密钥刷写装置是否有权限获取与MEK写入和/或完整性验证相关的信息，例如本申请各实施例中的第一信息、第五信息、第二验证信息；或者，KMS校验该MEK更新请求信息的合法性也可以理解为：KMS通过OEM密钥刷写装置的身份认证信息确定该OEM密钥刷写装置是否为OEM授权的密钥刷写装置。如果该OEM密钥刷写装置是OEM授权的密钥刷写装置，则可以默认该OEM密钥刷写装置有权限获取与MEK写入和/或完整性验证相关的信息，例如本申请各实施例中的第一信息、第五信息、第二验 证信息。具体的例如针对售后维修场景，该身份认证信息可以表征发起该MEK更新请求的4S店或维修方是否为经OEM授权的经销商。应理解，在此场景下，OEM密钥刷写装置可替换为经销商诊断仪。如果该身份认证信息可以表征该4S店或维修方为经OEM授权的经销商，则KMS可以将MEK写入和/或完整性验证相关的信息发送给经销商诊断仪。基于此，可以保证MEK写入和/或完整性验证相关的信息只提供给KMS或整车厂授权的客户端，进而保证了MEK的安全性。
示例性地，KMS通过MEK更新请求信息中包括的如下信息中的一项或多项，可以确定用于写入MEK(包括对MEK的完整性验证)的具体信息或用于验证MEK完整性的具体信息。其中，如下信息为：待更新MEK的ECU的数量(或者待验证MEK完整性的ECU的数量)，ECU所属的整车的识别码(vehicle identification number，VIN)，ECU本地保存的认证密钥的版本号，ECU的不同版本号。例如，KMS通过待更新MEK的ECU的数量或待验证MEK完整性的ECU的数量，可以确定如下信息中的一项或多项：第一信息的数量，第二验证信息的数量，第五信息的数量，进而可以实现对批量ECU的MEK批量写入和/或MEK批量完整性验证，降低密钥管理的成本。又例如，KMS通过ECU的不同版本号或ECU本地保存的认证密钥的版本号，可以确定待写入的MEK的版本号，进而保证有效的MEK写入，进而可以基于该MEK进一步写入功能密钥，以保证该ECU的正常使用。
在一种可选的设计中，在步骤S401之前，还可以包括步骤S403。步骤S403具体为：
S403，ECU-1将本地保存的MEK的版本号发送给OEM密钥刷写装置。
相应地，OEM密钥刷写装置接收该本地保存的MEK的版本号。
在一种可选的设计中，ECU-1还可以将如下信息中的一项或多项发送给OEM密钥刷写装置：ECU-1所属的整车的识别码即VIN，ECU-1的不同版本号，ECU-1的设备识别码、ECU-1的设备类型。
应理解，OEM密钥刷写装置可以通过收集多个ECU的上述信息，确定待更新MEK的ECU的数量或待验证MEK完整性的ECU的数量。
S404，OEM密钥刷写装置向KMS发送MEK的更新结果。
相应地，KMS接收该OEM密钥刷写装置。
该MEK的更新结果包括如下一项或多项：MEK的完整性，VRF_K的完整性，ECU-1的身份标识。其中MEK的完整性用于表征MEK是否写入ECU-1并且通过了完整性验证，或者MEK的完整性用于表征KMS本地保存的MEK与ECU-1本地保存的MEK是否相同；VRF_K的完整性用于表征VRF_K是否写入ECU-1并且通过了完整性验证。
示例性地，KMS基于该更新结果，可以确定MEK是否完整写入ECU-1，如果确定MEK没有被完整写入ECU-1，则可以重新尝试通过OEM密钥刷写装置将MEK写入到ECU-1中；如果确定MEK被完整写入ECU-1，则可以将该更新结果做备案处理，用于可能的后续应用。
在一种可选的设计中，作为一种可能的实现方式，在上述各实施例的方法之前，可以包括图4所示的步骤S401-步骤S403，在上述各实施例中的方法之后，可以包括图4所示的步骤S404。
通过上述MEK更新请求信息，KMS可以生成适配于MEK更新或MEK完整性验证的 信息，进而实现MEK的完整性验证，保证功能密钥的正常使用以及整车的信息安全。通过上述更新结果，KMS可以确定MEK是否写入第一电子控制单元和/或确定第一电子控制单元本地保存的认证密钥是否为MEK，以此保证功能密钥的正常使用以及整车的信息安全。此外，通过收集所述ECU-1的身份标识，还便于密钥管理实体实现对写入所述MEK的电子控制单元和/或已验证认证密钥完整性的电子控制单元的管理。
此外，作为一种可能的实现方式，本申请实施例中所述的密钥验证方法，还可以包括图5所示的步骤S501-步骤S502，或者还可以包括图5所示的步骤S501-步骤S503。步骤S501-S503具体如下：
S501，ECU-1根据第一信息和挑战-应答机制，生成第九信息。
其中，第九信息包括用于验证VRF_K完整性的信息。示例性地，对应于步骤S201中一种具体的第一信息生成方式，这里生成的第九信息可以包括第十一信息和第十二信息，其中第十一信息为至少通过所述ECU-1的身份标识、VRF_K的索引、MEK的索引以及第十三信息级联得到的信息，第十二信息为通过VRF_K的派生密钥对该第十一信息进行完整性保护得到的信息，第十三信息为通过VRF_K的派生密钥对第一信息中包含的计数值(例如C ID’)加密得到的信息。应理解，基于此，不仅可以实现对VRF_K的完整性验证，还可以通过包括第十三信息的第十一信息，达到防重放估计的效果。需要说明的是，用于派生密钥生成的派生算法、加密算法以及完整性保护算法可以包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
S502，ECU-1向OEM密钥刷写装置发送该第九信息。
相应地，该OEM密钥刷写装置接收该第九信息。
在一种可选的设计中，ECU-1可以将第九信息与其他发送给OEM密钥刷写装置的信息(比如第一验证信息)携带在同一条信令中发送，或者也可以通过不同的信令分别发送第九信息与其他发送给OEM密钥刷写装置的信息。
S503，OEM密钥刷写装置向KMS发送该第九信息。
相应地，KMS接收该第九信息。
在一种可选的设计中，OEM密钥刷写装置对于接收到的第九信息不做进一步处理，例如不解析第九信息。
在一种可选的设计中，KMS根据该第九信息，可以确定ECU-1的身份标识，用于整车厂对已确认MEK完整性的ECU进行备案处理。
示例性地，此场景下，ECU-1可以对应于挑战-应答机制中的应答方，OEM密钥刷写装置可以对应于挑战-应答机制中的挑战方，第一信息中包括由挑战方发出的挑战，第九信息可以对应于应答方做出的相应应答。所不同的是，在该场景下，OEM密钥刷写装置不对该第九信息进行解析，而是将其发送给KMS进行进一步处理，由KMS确定应答方是否通过了挑战和/或判断应答方是否应该被认证。采用该方式，可以实现对VRF_K的完整性验证，且实现简单。
需要说明的是，第九信息可以用于指示VRF_K的完整性，基于此，第九信息可以理解为VRF_K的完整性信息的一个示例。应理解，在OEM密钥刷写装置发送给KMS的VRF_K的更新结果中，可以包含该第九信息。
此外，当本申请各实施例中所述的密钥验证方法包括图3所示的实施例中的方法时，本申请实施例中所述的密钥验证方法，还可以包括图6所示的步骤S601-步骤S602，或者还可以包括图6所示的步骤S601-步骤S603。步骤S601-S603具体如下：
S601，ECU-1根据第五信息和挑战-应答机制，生成第十信息。
其中，第十信息包括用于验证MEK完整性的信息。示例性地，对应于步骤S301中一种具体的第五信息生成方式，这里生成的第十信息可以包括第十四信息和第十五信息，其中第十四信息为至少通过所述ECU-1的身份标识、MEK的索引、PMEK的索引以及第十六信息级联得到的信息，第十五信息为通过MEK的派生密钥对该第十四信息进行完整性保护得到的信息，第十六信息为通过MEK的派生密钥对第二信息中包含的计数值(例如C ID)加密得到的信息。应理解，基于此，不仅可以实现对MEK的完整性验证，还可以通过包括第十六信息的第十四信息，达到防重放估计的效果。需要说明的是，用于派生密钥生成的派生算法、加密算法以及完整性保护算法可以包括但不限于上述描述的具体实现方式，本申请实施例在此不做具体限定。
S602，ECU-1向OEM密钥刷写装置发送该第十信息。
相应地，该OEM密钥刷写装置接收该第十信息。
在一种可选的设计中，ECU-1可以将第十信息与其他发送给OEM密钥刷写装置的信息(比如第一验证信息、第九信息)携带在同一条信令中发送，或者也可以通过不同的信令分别发送第十信息与其他发送给OEM密钥刷写装置的信息。
S603，OEM密钥刷写装置向KMS发送该第十信息。
相应地，KMS接收该第十信息。
在一种可选的设计中，OEM密钥刷写装置对于接收到的第十信息不做进一步处理，例如不解析第十信息。
在一种可选的设计中，KMS根据该第十信息，可以确定ECU-1的身份标识，用于整车厂对已确认MEK完整性的ECU进行备案处理。
示例性地，此场景下，ECU-1可以对应于挑战-应答机制中的应答方，OEM密钥刷写装置可以对应于挑战-应答机制中的挑战方，第五信息中包括由挑战方发出的挑战，第十信息可以对应于应答方做出的应答。所不同的是，在该场景下，OEM密钥刷写装置不对该第十信息进行解析，而是将其发送给KMS进行进一步处理，由KMS确定应答方是否通过了挑战和/或判断应答方是否应该被认证。采用该方式，可以实现对MEK的完整性验证，且实现简单。
需要说明的是，第十信息可以用于指示MEK的完整性，基于此，第十信息可以理解为MEK的完整性信息的一个示例，即，在OEM密钥刷写装置发送给KMS的MEK的更新结果中，可以包含该第十信息。
需要说明的是，本申请各实施例中的方法包括的步骤可以根据实际需要进行顺序调整、合并和删减。
上面结合图2至图6介绍了本申请实施例提供的密钥验证方法，下面结合图7至图9详细说明本申请实施例提供的装置。
图7为本申请实施例提供的控制装置的示意性框图。如图7所示，该控制装置可以包 括至少一个处理器和存储器，以执行上文中任一种可能实现方式中的方法。其中，存储器用于存储计算机程序或指令，该至少一个处理器用于调用所述存储器中的所述计算机程序或指令。示例性地，该至少一个处理器可以用于进行控制装置内的内部处理，例如根据所述第二密钥和所述第一验证参数，生成第一验证信息，所述第一验证信息用于表征所述第一密钥的完整性；又例如，生成第一信息和第二验证信息；再例如，根据本地验证信息与所述第一验证信息，确定所述第二密钥的完整性，其中所述本地验证信息包括通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息。
进一步地，在一种可选的设计中，该控制装置还可以包括收发器，如图8中所示。图8是本申请实施例提供的控制装置的示意性框图。其中，该收发器与该控制装置包括的至少一个处理器、存储器耦合，可以理解的是，该收发器、该至少一个处理器和该存储器通过内部连接通路互相通信。具体地，该收发器可以为该至少一个处理器和该存储器提供信息输入和/或输出，以使得该控制装置执行本申请实施例中任一种可能实现方式中的方法。例如，该收发器可以用于接收第一信息；又例如，该收发器可用于接收第一验证参数；再例如，该收发器可以用于发送第一验证信息等。
在又一种实现方式中，该控制装置包括用于执行本申请实施例中任一种可能实现方式中的方法的单元。
在一种可选的设计中，上述控制装置可以是电子部件的控制装置，用于执行上文中ECU-1所执行的任一方法；或者上述控制装置是密钥管理实体的控制装置，用于执行上文中KMS所执行的任一方法；或者上述控制装置是密钥刷写工具的控制装置，用于执行上文中OEM密钥刷写装置所执行的任一方法。
本申请实施例中还提供了一种车辆，该车辆包括实现上文中ECU-1所执行的任一种可能实现方式中的方法的控制装置，或者所述车辆包括实现上文中ECU-1所执行的任一种可能实现方式中的方法的电子部件。
本申请实施例中还提供了一种系统，该系统包括用于执行上文中ECU-1所执行的任一种可能实现方式中的方法的电子部件、包括用于执行上文中ECU-1所执行的任一种可能实现方式中的方法的控制装置的车辆、包括用于执行上文中ECU-1所执行的任一种可能实现方式中的方法的电子部件的车辆、用于执行上文中KMS所执行的任一种可能实现方式中的方法的密钥管理实体、或者用于执行上文中OEM密钥刷写装置所执行的任一种可能实现方式中的方法的密钥刷写工具中的一个或多个。
本申请实施例中还提供了一种系统，该系统包括用于执行上文中ECU-1所执行的任一种可能实现方式中的方法的控制装置，用于执行上文中KMS所执行的任一种可能实现方式中的方法的控制装置，或者用于执行上文中OEM密钥刷写装置所执行的任一种可能实现方式中的方法的控制装置中的一个或多个。
另外，本申请实施例中还提供了一种芯片，如图9所示。图9示出了一种芯片的结构示意图。芯片包括一个或多个处理器以及接口电路，该接口电路用于为该一个或多个处理器提供信息输入和/或输出用于执行上文中任一种可能实现方式中的方法。在一种可选的设计中，该芯片还可以包括总线。其中，示例性地，处理器是一种集成电路芯片，具有信号的处理能力。例如，该处理器可以是现场可编程门阵列(field programmable gate array，FPGA)， 可以是通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
接口电路可以用于数据、指令或者信息的发送或者接收，处理器可以利用接口电路接收的数据、指令或者其它信息，进行加工，可以将加工完成信息通过接口电路发送出去。
在一种可选的设计中，芯片还包括存储器，可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
需要说明的是，处理器、接口电路各自对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，这里不作限制。
需要说明的是，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上文中第一节点所执行的任意可能的实现方式中的方法，或者执行上文中第二节点所执行的任意可能的实现方式中的方法。
本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述任一种可能实现方式中的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地 产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disc，SSD))等。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (30)

  1. 一种验证方法，其特征在于，包括：
    通过客户端接收第一信息，所述第一信息来自密钥管理实体，所述第一信息通过第二密钥的信息指示第一密钥，所述第二密钥被配置用于认证第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能；
    接收来自所述客户端的第一验证参数；
    根据所述第二密钥和所述第一验证参数，生成第一验证信息，所述第一验证信息用于表征所述第一密钥的完整性；
    向所述客户端发送所述第一验证信息。
  2. 如权利要求1所述的方法，其特征在于，所述第一信息包括通过所述第二密钥的派生密钥进行加密和/或完整性保护得到的信息。
  3. 如权利要求1或2所述的方法，其特征在于，所述第一信息包括：
    至少通过所述第一电子控制单元的身份信息、所述第一密钥的索引和所述第二密钥的索引级联得到的第二信息，
    通过第三密钥对所述第一密钥加密得到的第三信息，以及
    通过第四密钥，对至少由所述第二信息和所述第三信息级联的信息进行完整性保护得到的第四信息，其中，所述第三密钥和所述第四密钥是所述第二密钥的派生密钥。
  4. 如权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：
    通过所述客户端接收第五信息，所述第五信息来自所述密钥管理实体，所述第五信息通过第五密钥的信息指示所述第二密钥，
    其中，所述第五密钥用于认证所述第二密钥。
  5. 如权利要求4所述的方法，其特征在于，所述第五信息包括通过所述第五密钥的派生密钥进行加密和/或完整性保护得到的信息。
  6. 如权利要求4或5所述的方法，其特征在于，所述第五信息包括：
    至少通过所述第一电子控制单元的身份信息、所述第二密钥的索引和所述第五密钥的索引级联得到的第六信息，
    通过第六密钥对所述第二密钥加密得到的第七信息，以及
    通过第七密钥对至少由所述第六信息和所述第七信息级联的信息进行完整性保护得到的第八信息，其中，所述第六密钥和所述第七密钥是所述第五密钥的派生密钥。
  7. 如权利要求3至6任一项所述的方法，其特征在于，所述第一电子控制单元的身份信息包括所述第一电子控制单元的身份标识或者所述第一电子控制单元的组标识，其中：
    所述第一电子控制单元的身份标识用于唯一标识所述第一电子控制单元；
    所述第一电子控制单元的组标识中包含至少一个通配符，所述第一电子控制单元的组标识用于标识所述第一电子控制单元所属的设备组。
  8. 如权利要求1至7任一项所述的方法，其特征在于，所述第一验证信息包括通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息。
  9. 一种验证方法，其特征在于，包括：
    生成第一信息和第二验证信息，所述第一信息通过第二密钥的信息指示第一密钥，所 述第二密钥被配置用于认证第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能，所述第二验证信息包括用于所述第一密钥的完整性验证的信息；
    向客户端发送所述第一信息和所述第二验证信息。
  10. 如权利要求9所述的方法，其特征在于，所述第一信息包括通过所述第二密钥的派生密钥进行加密和/或完整性保护得到的信息。
  11. 如权利要求9或10任一项所述的方法，其特征在于，所述方法还包括：
    向所述客户端发送第五信息，所述第五信息通过第五密钥的信息指示所述第二密钥，
    其中，所述第五密钥用于认证所述第二密钥。
  12. 如权利要求11所述的方法，其特征在于，所述第五信息包括通过所述第五密钥的派生密钥进行加密和/或完整性保护得到的信息。
  13. 如权利要求9至12任一项所述的方法，其特征在于，所述第二验证信息包括：
    第二验证参数，以及通过所述第一密钥对所述第二验证参数进行完整性保护得到的信息，
    其中，所述第二验证参数用于验证所述第一密钥的完整性。
  14. 如权利要求9至13任一项所述的方法，其特征在于，所述方法还包括：
    接收来自所述客户端的第二密钥更新请求信息，所述第二密钥更新请求信息用于请求更新所述第二密钥，
    其中，所述第二密钥更新请求信息包括所述客户端的身份认证信息。
  15. 如权利要求9至14任一项所述的方法，其特征在于，所述方法还包括：
    接收来自所述客户端的所述第二密钥的更新结果，所述第二密钥的更新结果包括以下一项或多项：所述第二密钥的完整性信息，所述第一电子控制单元的身份标识，或者所述第一密钥的完整性信息，
    其中，所述第一电子控制单元的身份标识用于唯一标识所述第一电子控制单元。
  16. 一种验证方法，其特征在于，包括：
    接收来自密钥管理实体的第一信息；
    向第一电子控制单元发送所述第一信息，所述第一信息通过第二密钥的信息指示第一密钥，所述第二密钥被配置用于认证所述第一电子控制单元的至少一个功能密钥，所述至少一个功能密钥对应所述第一电子控制单元的至少一个业务功能；
    向所述第一电子控制单元发送第一验证参数，所述第一验证参数用于验证所述第一密钥的完整性；
    接收来自所述第一电子控制单元的第一验证信息，所述第一验证信息用于表征所述第一密钥的完整性；
    根据本地验证信息与所述第一验证信息，确定所述第二密钥的完整性，其中所述本地验证信息包括通过所述第一密钥对所述第一验证参数进行完整性保护得到的信息。
  17. 如权利要求16所述的方法，其特征在于，所述第一验证参数来自所述密钥管理实体；或者，所述第一验证参数为所述客户端生成的信息。
  18. 如权利要求16或17所述的方法，其特征在于，所述第一信息包括通过所述第二 密钥的派生密钥进行加密和/或完整性保护得到的信息。
  19. 如权利要求16至18任一项所述的方法，其特征在于，所述方法还包括：
    向所述第一电子控制单元发送第五信息，所述第五信息通过第五密钥的信息指示所述第二密钥，
    其中，所述第五密钥用于认证所述第二密钥。
  20. 如权利要求19所述的方法，其特征在于，所述第五信息包括通过所述第五密钥的派生密钥进行加密和/或完整性保护得到的信息。
  21. 如权利要求16至20任一项所述的方法，其特征在于，所述方法还包括：
    向所述密钥管理实体发送第二密钥更新请求信息，所述第二密钥更新请求信息用于请求更新所述第二密钥，
    其中，所述第二密钥更新请求信息包括所述客户端的身份认证信息。
  22. 一种控制装置，其特征在于，包括用于执行如权利要求1至8中任一项，或，权利要求9至15中任一项，或权利要求16至22中任一项所述方法的单元。
  23. 一种控制装置，其特征在于，所述控制装置包括至少一个处理器和存储器，所述存储器用于存储计算机程序或指令，所述至少一个处理器用于调用所述存储器中的所述计算机程序或指令，以使得所述控制装置执行如权利要求1至8中任一项，或，权利要求9至15中任一项，或，权利要求16至22中任一项所述的方法。
  24. 一种车辆，其特征在于，包括用于执行如权利要求1至8中任一项所述方法的控制装置。
  25. 一种密钥管理实体，其特征在于，包括用于执行如权利要求中9至15任一项所述方法的控制装置。
  26. 一种密钥刷写工具，其特征在于，包括用于执行如权利要求16至22中任一项所述方法的控制装置。
  27. 一种系统，其特征在于，包括如权利要求24中所述的车辆、如权利要求25所述的密钥管理实体或者如权利要求26所述的密钥刷写工具中的一个或多个。
  28. 一种芯片，其特征在于，包括一个或多个处理器和接口电路，所述接口电路用于为所述一个或多个处理器提供信息输入和/或输出，所述芯片用于执行如权利要求1至8中任一项，或，权利要求9至15中任一项，或，权利要求16至22中任一项所述的方法。
  29. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被处理器执行时，实现如权利要求1至8中任一项，或，权利要求9至15中任一项，或，权利要求16至22中任一项所述的方法。
  30. 一种计算机程序产品，其特征在于，所述计算机程序产品在一个或多个处理器上运行时，实现如权利要求1至8中任一项，或，权利要求9至15中任一项，或，权利要求16至22中任一项所述的方法。
PCT/CN2021/108185 2021-07-23 2021-07-23 一种密钥验证方法及相关装置 WO2023000313A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2021/108185 WO2023000313A1 (zh) 2021-07-23 2021-07-23 一种密钥验证方法及相关装置
CN202180100210.6A CN117597688A (zh) 2021-07-23 2021-07-23 一种密钥验证方法及相关装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/108185 WO2023000313A1 (zh) 2021-07-23 2021-07-23 一种密钥验证方法及相关装置

Publications (1)

Publication Number Publication Date
WO2023000313A1 true WO2023000313A1 (zh) 2023-01-26

Family

ID=84980546

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/108185 WO2023000313A1 (zh) 2021-07-23 2021-07-23 一种密钥验证方法及相关装置

Country Status (2)

Country Link
CN (1) CN117597688A (zh)
WO (1) WO2023000313A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115865533A (zh) * 2023-02-27 2023-03-28 蓝象智联(杭州)科技有限公司 高并发场景下代理重加密管理方法、装置及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105794146A (zh) * 2014-11-13 2016-07-20 松下电器（美国）知识产权公司 密钥管理方法、车载网络系统以及密钥管理装置
CN106027260A (zh) * 2016-05-12 2016-10-12 成都信息工程大学 基于密钥预分配的汽车ecu完整性验证和加密通信方法
EP3148152A1 (en) * 2015-09-22 2017-03-29 BAE Systems PLC Cryptographic key distribution
US20190028267A1 (en) * 2016-01-18 2019-01-24 Kddi Corporation In-vehicle computer system, vehicle, key generation device, management method, key generation method, and computer program
US20200059359A1 (en) * 2017-05-16 2020-02-20 Denso Corporation Vehicular system for processing encryption key and electronic control device
CN112543914A (zh) * 2018-08-10 2021-03-23 株式会社电装 车辆用主装置、更新数据的验证方法以及更新数据的验证程序
CN112740212A (zh) * 2020-12-24 2021-04-30 华为技术有限公司 密钥写入方法及装置
CN113056898A (zh) * 2021-02-26 2021-06-29 华为技术有限公司 获取密钥的方法、装置及密钥管理系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105794146A (zh) * 2014-11-13 2016-07-20 松下电器（美国）知识产权公司 密钥管理方法、车载网络系统以及密钥管理装置
EP3148152A1 (en) * 2015-09-22 2017-03-29 BAE Systems PLC Cryptographic key distribution
US20190028267A1 (en) * 2016-01-18 2019-01-24 Kddi Corporation In-vehicle computer system, vehicle, key generation device, management method, key generation method, and computer program
CN106027260A (zh) * 2016-05-12 2016-10-12 成都信息工程大学 基于密钥预分配的汽车ecu完整性验证和加密通信方法
US20200059359A1 (en) * 2017-05-16 2020-02-20 Denso Corporation Vehicular system for processing encryption key and electronic control device
CN112543914A (zh) * 2018-08-10 2021-03-23 株式会社电装 车辆用主装置、更新数据的验证方法以及更新数据的验证程序
CN112740212A (zh) * 2020-12-24 2021-04-30 华为技术有限公司 密钥写入方法及装置
CN113056898A (zh) * 2021-02-26 2021-06-29 华为技术有限公司 获取密钥的方法、装置及密钥管理系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115865533A (zh) * 2023-02-27 2023-03-28 蓝象智联(杭州)科技有限公司 高并发场景下代理重加密管理方法、装置及存储介质

Also Published As

Publication number Publication date
CN117597688A (zh) 2024-02-23

Similar Documents

Publication Publication Date Title
EP3073668B1 (en) Apparatus and method for authenticating network devices
US9118467B2 (en) Generating keys using secure hardware
CN106572106B (zh) 一种tbox终端和tsp平台之间报文传输的方法
US9253162B2 (en) Intelligent card secure communication method
JP2018121328A (ja) 電子デバイスのためのイベント証明書
KR102450811B1 (ko) 차량 내부 네트워크의 키 관리 시스템
WO2020073206A1 (zh) 芯片、生成私钥的方法和可信证明的方法
US20220006650A1 (en) Secure device communication
CN113016201B (zh) 密钥供应方法以及相关产品
CN112740212B (zh) 密钥写入方法及装置
CN113138775B (zh) 车载诊断系统固件保护方法及系统
US11516194B2 (en) Apparatus and method for in-vehicle network communication
EP4250631A1 (en) Vehicle diagnosis system, method and apparatus
WO2020000491A1 (zh) 一种文件存储方法、装置及存储介质
US20220131856A1 (en) Remote Attestation Method and Apparatus
WO2023000313A1 (zh) 一种密钥验证方法及相关装置
WO2021170049A1 (zh) 一种访问行为的记录方法、装置
WO2021022802A1 (zh) 安全启动方法、控制器和控制系统
US20240089097A1 (en) Key update management system and key update management method
CN116631093A (zh) 用于从车辆提取数据的方法和设备
US11171786B1 (en) Chained trusted platform modules (TPMs) as a secure bus for pre-placement of device capabilities
WO2022241799A1 (zh) 一种密钥生成方法及装置
CN118101340B (zh) 数据安全传输方法、装置和电子设备
CN117118613B (zh) 整车仪表数据安全保护方法、设备及可读存储介质
CN116633618A (zh) 秘钥加密和解密方法及存储、应用控制系统、电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21950562

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180100210.6

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21950562

Country of ref document: EP

Kind code of ref document: A1