CN117597688A - Key verification method and related device - Google Patents

Abstract

The embodiment of the application provides a key verification method and a related device, which are applied to the field of information security. In a specific application, the client forwards first information from the key management entity to the first electronic control unit, wherein the first information indicates the first key by means of information of the second key, and the client sends a first verification parameter to the first electronic control unit, the first verification parameter being used for verifying the integrity of the first key, and receives first verification information in response to the first verification parameter, the first verification information being used for characterizing the integrity of the first key. The client determines the integrity of the second key according to the local verification information and the first verification information. By adopting the mode, the integrity of the second secret key is indirectly verified through the integrity of the first secret key, and the second secret key is prevented from being exposed out of the secret key management entity and the first electronic control unit in a plaintext form, so that the safety of the core asset of the whole vehicle factory is ensured.

Description

A key verification method and related devices Technical field

Embodiments of the present application relate to the field of information security, and in particular, to a key verification method and related devices.

Background technique

Information security is a prerequisite for autonomous driving. Currently, various function keys can be used in the vehicle system to protect the information security of the vehicle. For example, the security of the in-vehicle communication network can be protected through the security onboard communication (SecOC) key (SecOC key), and the authenticity of the device can also be ensured through the device key (device key) used for device authentication. wait.

Generally speaking, the normal use of the function key requires authentication by the authentication key. Therefore, how to ensure the integrity of the authentication key and thereby ensure the normal use of the function key is an urgent technical problem that needs to be solved by those skilled in the art.

Contents of the invention

The embodiment of the present application discloses a key verification method and related devices, 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.

In a first aspect, a key verification method is provided, which method can be executed by an electronic control unit or a chip configured in the electronic control unit. The method includes: receiving, by a client, first information from a key management entity, the first information indicating a first key through information of a second key, the second key being configured with For authenticating at least one function key of the first electronic control unit, the at least one function key corresponding 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.

In an optional design, the method may also be executed by a functional component including an electronic control unit or a chip configured in the functional component. Illustratively, the functional component is a domain controller containing one or more electronic control units.

According to the key verification method provided by this application, since the first verification information used to characterize the integrity of the first key is obtained based on the second key and the first verification parameter, the integrity of the first key can be 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. In addition, since 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 expressed in plain text. The form is exposed outside the key management entity and electronic control unit, thereby ensuring the security of the OEM's core assets.

In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: receiving fifth information from the client, the fifth information coming from the key management entity, and the fifth information passing through a fifth The information of the key indicates the second key, wherein the fifth key is used to authenticate the second key.

Using this solution, the second key can be written into the first electronic control unit through the fifth information, which can satisfy the requirements of the vehicle production line and/or the maintenance party authorized by the vehicle manufacturer to correctly write the second key into the first electronic control unit. The requirements of the electronic control unit will provide authentication conditions for subsequent writing of function keys, ensuring the normal use of function keys and the information security of the entire vehicle.

In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: generating ninth information according to the first information and the challenge-response mechanism, the ninth information including a method for verifying the first Key integrity information; sending the ninth information to the client.

In this solution, the ninth information generated based on the challenge-response mechanism can realize the integrity verification of the first key, simplifying the verification process and improving verification efficiency.

In connection with the first aspect, in some implementations of the first aspect, the method further includes: generating tenth information according to the fifth information and the challenge-response mechanism, the tenth information including a method for verifying the first 2. Key integrity information; sending the tenth information to the client.

In this solution, the tenth information generated based on the challenge-response mechanism can realize the integrity verification of the second key, simplifying the verification process and improving verification efficiency.

In an optional design, the first verification information includes information obtained by performing integrity protection on the first verification parameter using the first key. Since the first information indicates the first key through the information of the second key, only when the second key saved locally by the first electronic control unit is consistent with the second key saved by the key management entity, the first Only then can the key be correctly written into the first electronic control unit based on the first information. Based on this, indirect verification of the integrity of the second key can be achieved through the information obtained by integrity protecting the first verification parameter with the first key.

In the second aspect, a key verification method is provided, which method 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 verification information, the first information being indicative of a first key through information of a second key, the second key being configured to authenticate at least one of the first electronic control units. A function key, the at least one function key corresponds to at least one business function of the first electronic control unit, and the second verification information includes information for integrity verification of the first key; to the customer The terminal sends the first information and the second verification information.

In an optional design, the key management entity includes a key management server (KMS).

According to the key verification method provided by this application, writing of the first key can be achieved by sending first information indicating the first key and 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. And because 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, 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 form of plain text. In addition to key management entities and electronic control units, it ensures the security of the core assets of the OEM. In addition, 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 vehicle production line does not need to collect in advance all target electronic control units that need to update the second key. The identification information reduces the burden and management costs of the vehicle production line.

Through this solution, the key management entity can also prepare the information for the first key integrity verification (such as the first information, the second verification information) in advance and send it to the client in advance. Based on this, the Offline verification of the electronic control unit's authentication key (i.e., the second key), even if it does not rely on KMS, can achieve real-time verification of the integrity of the second key, reducing time overhead.

In an optional design, the second verification information includes the first key, so that the client determines the local verification information based on the first key combined with a locally generated first verification parameter. , wherein the local verification information can be used for integrity verification of the first key and/or the second key; or the second verification information includes a second verification parameter, and the second verification information is passed through the first key. Information obtained by performing integrity protection on the second verification parameter using the key.

In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: sending fifth information to the client, the fifth information indicating the second key through information of the fifth key , wherein the fifth key is used to authenticate the second key.

Through this solution, the writing of the second key can be realized, thereby meeting the needs of the vehicle production line and/or the maintenance party authorized by the vehicle manufacturer to correctly write the second key into the first electronic control unit, thereby providing sufficient support for 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 entire vehicle. In addition, this solution can be adapted to various scenarios where the second key needs to be written. Through a unified solution adapted to various scenarios, the key management process of the key management entity or the OEM can be simplified. Key writing process.

In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving second key update request information from the client, the second key update request information being used to request to update the the second key, or used to request verification of the integrity of the second key stored locally in the first electronic control unit.

Through this solution, the second key update request information is used to generate information adapted to the second key update or the second key integrity verification, thereby realizing the integrity verification of the second key and ensuring the function key's integrity. Normal use and vehicle information security.

In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving an update result of the second key from the client.

Through this solution, the update status of the second key can be known, and then it can be determined whether the function key can be written, thereby ensuring the normal use of the function key and the information security of the entire vehicle.

In the third aspect, a key verification method is provided, which method can be performed by the client or a chip configured in the client. The method includes: receiving first information from a key management entity; sending said first information to a first electronic control unit, said first information indicating a first key through information of a second key, said second The key is configured to authenticate at least one function key of the first electronic control unit, the at least one function key corresponding to at least one business function of the first electronic control unit; to the first electronic control unit Send a first verification parameter, the first verification parameter is used to verify the integrity of the first key; receive first verification information from the first electronic control unit, the first verification information is used to characterize the The integrity of the first key; determining the integrity of the second key according to local verification information and the first verification information, wherein the local verification information includes pairing the third key with the first key. A verification parameter is used to perform integrity protection on the information obtained.

In an optional design, the client includes an OEM key flashing device or a dealer diagnostic instrument.

Through this solution, the client serves as an intermediary between the key management entity and the first electronic control unit, and can forward the first information of the key management entity to the first electronic control unit, thereby realizing the first key in the first electronic control unit. Writing on the electronic control unit side indirectly verifies the integrity of the second key by verifying the integrity of the first key based on 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 in plain text outside the key management entity and the electronic control unit, thus ensuring that the core assets of the OEM safety. In addition, the integrity verification of the second key is implemented through the client as an intermediate medium, which is simple to implement and adapts to vehicle production line assembly, after-sales maintenance scenarios, and parts developer key rewriting scenarios, thereby reducing key management Entity or OEM administrative costs.

In an optional design, the first verification parameter comes from the key management entity, for example, corresponds to the second verification parameter from the key management entity, that is, the client will come 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.

In an optional design, the local verification information comes from the key management entity, for example, corresponds to the integrity of the second verification parameter through the first key from the key management entity. The obtained information is protected; or the local verification information is information determined by the client.

Combined with the third aspect, in some implementations of the third aspect, determining the integrity of the second key according to the local verification information and the first verification information includes: if the local verification information and the first verification information 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.

Through this solution, the client can judge the integrity of the second key, and then judge whether the function key can be written, thereby ensuring the normal use of the function key.

In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: sending fifth information to the first electronic control unit, the fifth information indicating the A second key, wherein the fifth key is used to authenticate the second key.

Through this solution, it can meet the needs of the vehicle production line and/or the maintenance party authorized by the vehicle manufacturer to correctly write the second key into the first electronic control unit, thereby providing authentication conditions for subsequent writing of the function key, ensuring Normal use of function keys and information security of the entire vehicle.

In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: sending ninth information from the first electronic control unit to the key management entity, the ninth information including using Information for verifying the integrity of the first key; the client does not parse the ninth information.

Through this solution, 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, simplifying client operations.

In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: sending tenth information from the first electronic control unit to the key management entity, the tenth information including Information for verifying the integrity of the second key; the client does not parse the tenth information.

Through this solution, 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, simplifying client operations.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: sending second key update request information to the key management entity, the second key update request information being used to request Update the second key, or be used to request verification of the integrity of the second key stored locally in the first electronic control unit.

Through this solution, the key management entity can be assisted to generate information adapted to the second key update or the second key integrity verification through the second key update request information, thereby realizing the integrity verification of the second key. , ensuring the normal use of function keys and the information security of the entire vehicle.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: sending the update result of the second key to the key management entity.

Through this solution, the key management entity can be assisted to learn the update status of the second key, and then determine whether the function key can be written, thereby ensuring the normal use of the function key and the information security of the entire vehicle.

Combining the second aspect and the third aspect, in some implementations of the second aspect and the third aspect, 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 stored locally in the electronic control unit, and the version number of the electronic control unit.

In an optional design, the client's identity authentication information is used to represent 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. By including the identity authentication information of the client in the second key update request information, it can be ensured that the key writing information is only provided to clients authorized by the key management entity, thereby ensuring the security of the key.

In addition, 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 unit The version number of the authentication key stored locally in 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 batch writing of the second key and/or the second key Batch integrity verification reduces the cost of key management.

Combining the second aspect and the third aspect, in some implementations of the second aspect and the third aspect, the update result of the second key includes one or more of the following: 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.

Through this solution, the key management entity can determine whether the second key is written to the first electronic control unit and/or determine the authentication key saved locally by the first electronic control unit based on the update result of the second key. Whether it is the second key, thereby ensuring the normal use of the function key and the information security of the entire vehicle. In addition, collecting the identity of the first electronic control unit also facilitates the key management entity to manage the electronic control unit that writes the second key.

In combination with the first aspect, the second aspect and the third aspect, in some implementations of the first aspect, the second aspect and the third aspect, the first information includes a key derived from the second key. Encrypt and/or integrity protect the resulting information.

Through this solution, it is possible to write the first key to the first electronic control unit while the first key is safe, and to ensure that the second key is not exposed in plain text to the key management entity and the electronic control unit. outside the unit.

Combining the first aspect, the second aspect and the third aspect, in some implementations of the first aspect, the second aspect and the third aspect, the first information includes: at least 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 a third key, and the fourth information The key is the fourth information obtained by performing integrity protection on the information concatenated by at least the second information and the third information, wherein the third key and the fourth key are the third information. The derived key of the second key.

Through this solution, it is possible to write the first key to the first electronic control unit while the first key is safe, and to ensure that the second key is not exposed in plain text to the key management entity and the electronic control unit. Outside the unit, and easy to implement.

In combination with the first aspect, the second aspect and the third aspect, in some implementations of the first aspect, the second aspect and the third aspect, the fifth information includes a key derived from the fifth key. Encrypt and/or integrity protect the resulting information.

Through this solution, it is possible to write the second key to the first electronic control unit while ensuring the security of the second key.

Combining the first aspect, the second aspect and the third aspect, in some implementations of the first aspect, the second aspect and the third aspect, the fifth information includes: at least the identity of the first electronic control unit information, the sixth information obtained by concatenating 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 performs integrity protection on the eighth information obtained by at least concatenating the sixth information and the seventh information, wherein the sixth key and the seventh key are the fifth information. The derived key for the key.

Through this solution, it is possible to write the second key to the first electronic control unit while ensuring the security of the second key, and the implementation is simple.

Combining the first aspect, the second aspect and the third aspect, in some implementations of the first aspect, the second aspect and the third aspect, the identity information of the first electronic control unit includes the first electronic control unit The identity identifier or the group identifier of the first electronic control unit, wherein the identity identifier of the first electronic control unit is used to uniquely identify the first electronic control unit; the group identifier of the first electronic control unit is To identify the equipment group to which the first electronic control unit belongs.

In an optional design, the group identifier of the first electronic control unit includes at least one wildcard.

Through this solution, based on the group identification of the first electronic control unit, it is possible for the key management entity to batch write the first keys and/or second keys of multiple electronic control units, and to complete the second key Persistent 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 the second key can be achieved, as well as verification of the integrity of the second key. .

A fourth aspect provides a control device, which includes a unit or module for executing the method in any possible implementation of the above first aspect, or for executing any one of the above second aspects. A unit or module that may implement the method in the possible implementation manner, or a unit or module that is used to perform the method in any possible implementation manner of the above third aspect.

In a fifth aspect, a control device is provided, the control device including a processor and a memory. The memory is used to store computer programs or instructions, and the processor is used to call the computer program or instructions in the memory, so that the control device executes the method in any possible implementation of the first aspect. , or used to perform the method in any possible implementation of the above second aspect, or used to perform the method in any possible implementation of the above third aspect. In an optional design, the control device further includes a communication interface, the communication interface is coupled to the processor, the communication interface is used to input and/or output information, the information includes, for example, one or more of the following information Items: the first information, the fifth information, the first verification parameter, the first verification information, the second verification information, the second key update request information, the second password Key update result.

In an optional design, there are one or more processors and one or more memories.

In an optional design, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

In combination with the fourth and fifth aspects, in an optional design, the control device used to perform the method in any possible implementation of the first aspect may be an electronic control unit or include one or more electronic The domain controller of the control unit.

A sixth aspect provides an electronic component, which includes a control device that implements the method in any possible implementation of the first aspect. Illustratively, the electronic component includes an ECU.

A seventh aspect provides a vehicle, which includes a control device that implements the method in any possible implementation of the first aspect, or the vehicle includes the electronic component provided in the sixth aspect.

An eighth aspect provides a key management entity that can implement the method in any possible implementation manner of the second aspect. In an optional design, the key management entity may be a key management server.

A ninth aspect provides a key flashing tool that can implement any of the possible implementation methods of the third aspect. In an optional design, the key flash tool may be an OEM key flash tool or a dealer diagnostic tool.

In a tenth aspect, a system is provided, which system includes the electronic component provided in the sixth aspect, the vehicle provided in the seventh aspect, the key management entity provided in the eighth aspect, or the key provided in the ninth aspect. One or more of the flash tools.

In an eleventh aspect, a system is provided, which system includes a control device for executing the method in any possible implementation of the above-mentioned first aspect, and a control device for executing any possible implementation of the above-mentioned second aspect. One or more of the control devices for the method in or for executing the method in any possible implementation of the third aspect.

In a twelfth aspect, a chip is provided, the chip 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 of the above first aspect, or to execute the method in any possible implementation of the above second aspect, or to execute any of the above third aspects. Methods in possible implementations.

In a thirteenth aspect, a computer-readable storage medium is provided. Computer programs or instructions are stored in the computer-readable storage medium. When the computer programs or instructions are executed by a processor, the processor is caused to execute the above-mentioned The method in any possible implementation of the first aspect, or used to perform the method in any possible implementation of the second aspect, or used to perform the method in any possible implementation of the third aspect method.

A fourteenth aspect provides a computer program product, which when the computer program product is run on one or more processors, causes the one or more processors to execute any possible implementation of the first aspect. The method in the above-mentioned aspect, or used to perform the method in any possible implementation manner of the above-mentioned second aspect, or used to perform the method in any possible implementation manner of the above-mentioned third aspect.

Description of drawings

The drawings used in the embodiments of this application are introduced below.

Figure 1 is a network architecture of a possible key verification method provided by an embodiment of the present application;

Figure 2 is a schematic flow chart of a possible key verification method provided by the embodiment of the present application;

Figure 3 is a schematic flow chart of a possible key writing method provided by an embodiment of the present application;

Figure 4 is a schematic flow chart of a possible method for implementing a key update request and a key update result provided by an embodiment of the present application;

Figure 5 is a schematic flow chart of a possible method for implementing key verification information provided by an embodiment of the present application;

Figure 6 is a schematic flow chart of another possible method for implementing key verification information provided by the embodiment of the present application;

Figure 7 is a schematic diagram of a possible control device provided by an embodiment of the present application;

Figure 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.

Detailed ways

The embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. It should be noted that in this application, words such as "exemplarily" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described herein as "exemplary" or "such as" is not intended to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

"At least one item" mentioned in the embodiments of this application refers to one item (item) or multiple items (items), and "multiple items (item)" refers to two items (items) or two items (items). above. "At least one of the following" or similar expressions thereof refers to any combination of these items, including any combination of a single item (items) or a plurality of items (items). For example, at least one of a, b, or c can 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. "And/or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and/or B can mean: A alone exists, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character "/" generally indicates that the related objects are in an "or" relationship.

And, unless otherwise stated, the use of ordinal numbers such as "first" and "second" in the embodiments of this application is used to distinguish multiple objects and is not used to limit the order, timing, priority or importance of multiple objects. degree. For example, the first information and the second information are only used to distinguish different information, but do not indicate the difference in content, priority, sending order or importance of the two types of information.

First, the technical terms involved in the embodiments of this application will be briefly explained.

1. Electronic Control Unit (ECU)

The electronic control unit ECU can also be called an on-board controller and can be used to control various functions in the vehicle. For example, ECUs may include but are not limited to: ECUs with engine control functions, ECUs with handle control functions, and ECUs with brake control functions.

For example, an ECU can also be understood as an electronic unit that has integrity protection functions and encryption functions and includes secure memory. Among them, secure memory can be implemented based on non-volatile memory (NvM). Secure memory has strict access control mechanisms to control the reading and use of critical key materials. For example, the secure memory is a secure storage area in an automotive open system architecture (AUTOSAR) secure hardware extension (SHE).

It should be noted that in some technical scenarios, the name of an electronic unit with similar functions that control various functions used in the vehicle may not be called ECU. Electronic units with integrity protection functions and encryption functions and including secure memory may not be called ECUs. The name of the unit may not be called ECU, but for the convenience of description, in the embodiment of this application, the electronic unit that controls various functions used in the vehicle is collectively called ECU, which has integrity protection functions and encryption functions and includes security The electronic unit of memory is also collectively referred to as ECU.

2. Authentication key

The authentication key is used to authenticate the function key. Only when the electronic control unit ECU has the correct authentication key can the function key be written and/or integrity verified. Based on this, the authentication key can also be understood as the authentication key of the function key or the authority key of the function key. For example, the ECU has a 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.

In addition, in addition to being used for the authentication of the function key, the authentication key can also be used to authenticate the hardware function key of the ECU, where the hardware function key can also be used for the authentication of the function key. For example, the authentication key can be used to authenticate a key corresponding to a subsequent version of the authentication key (as an example of a hardware function key). Taking the authentication key as the ECU master key (MEK) as an example, the electronic control unit ECU can only write and/or integrity verify the new version of the MEK if it has the correct previous version of the MEK. Specifically, if the latest MEK version saved by the current key management server is 2.0 (for ease of description, denoted as MEK2.0), if MEK2.0 can be successfully written to the target ECU, the target ECU needs to have the correct MEK Previous versions such as MEK1.0. Based on this, the authentication key can also be understood as the authentication key of the ECU hardware function key or the permission key of the ECU hardware function.

The authentication key can correspond to all the entire vehicles included in a model, or it can correspond to one entire vehicle, or it can also correspond to a functional component in the entire vehicle, or it can correspond to one ECU in the entire vehicle. Correspondingly, 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, in the vehicle A functional component in the vehicle has an authentication key, and other functional components in the vehicle have other authentication keys, or an ECU in the vehicle has an authentication key, and different ECUs have different authentication keys. The functional components here may include functional components composed of multiple ECUs, such as functional components composed of multiple ECUs for cabin control.

In the embodiment of this application, the ECU master key MEK may also be called the ECU hardware authority key.

3. Function key

Function keys can also be called business keys, which can be used to encrypt ECU keys for various functions in the vehicle to ensure the security of the vehicle computer system. Function keys may include, for example, but are not limited to: pre-shared key (PSK), master key (MK) for business applications, session key (SK). Among them, the PSK may include a security onboard communication (SecOC) key (SecOC key) used to protect vehicle network communication security and a device key (device key) used for device authentication.

In the embodiment of this application, the function key may be allocated based on a complete vehicle and a service. For example, for a complete vehicle, one or more ECUs used for the same service may share the same function key. For different vehicles, the ECUs of the same business can be different. For example, if multiple ECUs in the same vehicle are used for board-side encrypted communication, the multiple ECUs can share the same function key, and the multiple ECUs can perform encrypted communication with each other based on the function key. Specifically, ECUs communicating with each other can encrypt and decrypt messages based on the same function key to achieve encryption and integrity protection of messages. For another example, if multiple ECUs in the same vehicle are used for device certification, the multiple ECUs can also share the same function key. Any ECU among the plurality of ECUs authenticates other ECUs of the service based on the function key.

It can be understood that the function key used for board-side encrypted communication and the function key used for device authentication are keys for different services, and therefore are different keys. In the embodiment of this application, board-end encrypted communication and device authentication can be understood as different services.

Additionally, the feature key can also be distributed on a smaller granularity basis. For example, the function key may be allocated based on a complete vehicle, a service, or a pair of ECUs. For example, if multiple ECUs are used for the same service, every two ECUs in the multiple ECUs can form a pair of ECUs. Each pair of ECUs can share a function key. Specifically, for example, the plurality of ECUs include ECU-1, ECU-2 and ECU-3. ECU-1 and ECU-2 can share the same function key, such as function key 1; ECU-2 and ECU-3 can share another function key, such as function key 2; The function key can be shared between ECU-1 and ECU-3, for example, it is recorded as function key 3.

4.Message authentication code (MAC)

Message Authentication Code (MAC) is a verification mechanism used by both communicating entities in cryptography and is a tool used to ensure message integrity. For example, before sending a message, the sender first calculates the MAC using an integrity protection algorithm (or a key) negotiated by both communicating 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 the calculated MAC with the received MAC to see whether it is consistent. If the two are consistent, the message passes integrity verification.

5. Integrity protection algorithm

MAC can be generated by an integrity protection algorithm, which may also be called a MAC algorithm or a integrity protection algorithm. Generally speaking, the integrity protection algorithm includes at least the following three algorithms: (1) Key generation algorithm, used to generate the label calculation key and verification key. The label calculation key can be the same as the verification key (such as using (different from the key of the message authentication code), or it can be different (such as the key used for digital signature); (2) The label calculation algorithm takes the label calculation key and the information to be protected as input, and generates a corresponding The protection label of the information to be protected; (3) Verification algorithm, which takes the verification key, the label calculation key, and the information to be protected as input, and outputs a logical true value if and only if the verification is passed. In addition, the integrity protection algorithm group must also satisfy at least the following two properties. (1) Correctness, that is, the protection label generated using the label calculation key and label calculation algorithm must be verified as true by the verification key and verification algorithm. (2) Unforgeability, that is, if the attacker does not master the tag calculation key, he cannot forge a tag for the information to be protected with a non-negligible probability.

Illustratively, for example, the integrity protection algorithm implemented based on a hash algorithm is called a hash-based message authentication code (HMAC) algorithm, where the hash algorithm can be MD5, SHA-1, One of SHA-256, or other implementation methods, without specific limitations. These different HMAC implementations can usually be labeled: HMAC-MD5, HMAC-SHA1, HMAC-SHA256. For another example, the MAC algorithm implemented based on the cryptographic algorithm can be called the Cipher-based Message Authentication Code (CMAC) algorithm, and the block encryption algorithm can be the Advanced Encryption Standard (AES). Since the working modes of AES block encryption include but are not limited to ECB, CBC, CFB, and OFB, the integrity protection algorithms implemented based on the block encryption algorithms of different working modes can be respectively called: ECB-MAC algorithm, CBC-MAC algorithm, CFB -MAC algorithm, OFB-MAC algorithm. In addition, the integrity protection algorithm can also include Galois message authentication code mode (GMAC) and Zu Chongzhi cryptographic algorithms (such as ZUC128, ZUC256, etc.).

It should be noted that in the embodiment of the present application, the integrity protection algorithm may have other forms and is not specifically limited.

6. Encryption algorithm

Encryption algorithms include symmetric encryption algorithms and asymmetric encryption algorithms. Generally speaking, the encryption key and decryption key of symmetric encryption algorithm are the same, and the encryption key and decryption key of asymmetric encryption algorithm are different. Common symmetric encryption algorithms include, but are not limited to: data encryption standard (DES), triple data encryption algorithm (triple data encryption algorithm, 3DES), and AES; common asymmetric algorithms include, but are not limited to: RSA encryption algorithm.

It should be noted that in some specific scenarios, through the authenticated encryption algorithm, the data can be encrypted and the message authentication code can be generated for a given original text. Therefore, the authenticated encryption algorithm can be used as both an encryption algorithm and a complete security algorithm. For example, the AES algorithm based on GMAC and counting encryption mode (AES-Galois/Counter Mode, AES-GCM), the AES algorithm based on CMAC and counting encryption mode (AES-CMAC/Counter Mode, AES-CCM) can all process messages. Authentication encryption, and the MAC can be generated during the authentication encryption process to protect the integrity of the message.

In addition, there is a type of hash algorithm that does not require a key, such as for the generation of partial information in information produced based on encryption algorithms or based on integrity algorithms. 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).

7. Key derivation algorithm

Key derivation is the process of deriving one or more keys from a key, and the algorithm used to derive keys is called the key derivation function (KDF), also known as the key derivation algorithm. For example, the new key derived from the key Key can be expressed as: DK=KDF(Key). Commonly used key derivation algorithms include but are not limited to: password-based key derivation function (PBKDF) and scrypt algorithm. Among them, the PBKDF algorithm includes the first generation PBKDF1 and the second generation PBKDF2.

It should be noted that in each embodiment of the present application, in order to conveniently describe the KDF used in each key derivation process, the "first KDF", "second KDF" and "third KDF" will be used for description. The "third KDF" The first KDF, the second KDF and the third KDF can be different KDFs or the same KDF.

8. Challenge-Response Mechanism

The challenge-response mechanism is a mode in the authentication protocol. An authentication protocol that implements a challenge-response mechanism usually involves two parties. The challenger is usually the party that needs to verify the identity of the other party, and the responder is the party that needs to self-certify its identity.

The criteria of the challenge-response mechanism are as follows: the challenger sends a challenge to the responder, and the responder determines the corresponding response (response) to send to the challenger based on the locally saved authentication information (or secret authentication information) and the challenge. The challenger combines the challenge with the verification information it holds to verify whether the responder has passed the challenge, and/or determines whether the responder should be authenticated. For example, the challenging party may use information containing a fresh random string or information containing a pseudo-random string as a challenge.

Secondly, the system architecture and business scenarios of the embodiments of this application are described. It should be noted that the system architecture and business scenarios described in this application are for the purpose of explaining the technical solution of this application more clearly and do not constitute a limitation on the technical solution provided by this application. Those of ordinary skill in the art will know that with the system architecture With the evolution of the Internet and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

Please refer to Figure 1. Figure 1 is a network architecture of a possible key verification method provided by an embodiment of the present application. As shown in FIG. 1 , the network architecture 100 may include a key management server, an OEM key writing device (also called an OEM tool), a complete vehicle, and an ECU. Communication between KMS and the OEM key flashing device, and between the OEM key flashing device and the ECU, can be accomplished through local connections (such as local area networks, direct hardware connections (such as the key flashing device and the ECU directly)). Communication can also be carried out through a secure connection protocol (such as transport layer security specification (TLS) or virtual private network (VPN)) to ensure communication security.

It can be understood that for the production of complete vehicles, the above-mentioned OEM may specifically refer to the complete vehicle manufacturer or foundry.

It should be understood that Figure 1 is only for ease of understanding and shows the key writing/verification process used in the vehicle production line, but this should not constitute any limitation on this application. The key writing/verification method provided by this application can also be applied to after-sales service, such as the key update process for after-sales service. When used in 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 above-mentioned KMS dealer diagnostic tools, dealer diagnostic tools and ECU can also communicate through local connection or secure connection.

It can be understood that since the functions of OEM servers and dealer servers are similar and their application scenarios are different, the hardware structures of OEM servers and dealer servers can be similar. The OEM key writing device and the dealer diagnostic instrument have similar functions but different application scenarios. Therefore, the hardware structures of the OEM key writing device and the dealer diagnostic instrument may also be similar.

In an optional design, KMS further includes a KMS front-end server and a KMS back-end server. The KMS front-end server is mainly responsible for communicating with the outside world, and 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 search, etc. The KMS front-end server and the KMS back-end server can be two physically independent devices, or they can be integrated into the same physical device. The embodiments of the present application do not limit this.

It should also be understood that two vehicles are shown in Figure 1 along with one or more ECUs deployed on each vehicle. This application does not limit the number of complete vehicles in the network architecture and the number of deployed ECUs.

It should be noted that, for the sake of clarity of description, the following content in each embodiment of the present application uses MEK as an example of the authentication key. It can be understood that MEK can also be replaced with other authentication keys.

Due to the key properties of MEK (for example, MEK is used as an authentication key or authority key for function keys included in the entire vehicle), MEK can be considered a 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, after-sales 4S stores) in the form of clear text, and is not allowed to be exposed outside KMS. Based on this, existing vehicle manufacturers write MEK into the electronic control unit under a safe monitoring environment. In the absence of security monitoring (for example, when implementing remote key flashing), the security of the MEK cannot be guaranteed and there is a risk of being tampered with.

In view of this, embodiments of the present application provide a method for key verification. In this method, 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 through the information of the second key, the second key being configured to authenticate at least one function key of the first electronic control unit, the at least one function key corresponding to the first electronic control unit At least one business function; the client also sends a first verification parameter to the first electronic control unit, and the first verification parameter is used to verify the integrity of the above-mentioned 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. The first verification information is used to characterize the first The 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 based on the first verification information and local verification information. In this solution, since the first verification information used to characterize the integrity of the first key is obtained based on the second key and the first verification parameter, the second key can be indirectly verified through the integrity of the first key. The integrity of the 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. In addition, since 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 expressed in plain text. The form is exposed outside the key management entity and electronic control unit, thereby ensuring the security of the OEM's core assets.

The key verification method provided by the embodiment of the present application will be introduced below with reference to specific embodiments. It should be noted that in this embodiment of the present application, verifying the key may include verifying the integrity of the key, or may be understood as verifying the integrity of the key. For example, integrity verification 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 without tampering, it can mean that the key is correctly written or completely written into the ECU. Illustratively, the key here includes a function key (eg SecOC key, device key) and/or an authentication key (eg MEK).

Please refer to Figure 2, which is a schematic flowchart of a possible key verification method provided by an embodiment of the present application. Further, this method can be implemented based on the architecture of Figure 1. The method can include:

S201. The key management entity generates first information and second verification information.

In this embodiment of the present application, the key management entity is used to manage keys. For example, the key management entity can implement one or more of the following functions: generating keys, authorizing the use of keys, and managing the cancellation of keys. It should be noted that the keys here include various keys used in the car, such as function keys and authentication keys, as well as other forms of keys such as temporary keys used during the key flashing process.

For example, the key management entity can be a KMS. Further, the KMS is managed by the OEM, thereby ensuring the security of various keys used in the car; or the key management entity can also be a KMS that includes a KMS. OEM server, or the key management entity can also be the OEM, or the key management entity can also be directly the OEM server. For the description of KMS, please refer to the foregoing description and will not be repeated here. In addition, for the sake of clarity of description, the embodiments of this application are described using KMS as an example of a key management entity. It is understandable that KMS can also be replaced by other forms of key management entities.

In this embodiment of the present application, 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 function key of the first ECU, and the at least one function key Corresponds to at least one service function of the first ECU. Alternatively, the first information is associated with the second key, or the first information is associated with information of the second key. For clarity of description, each embodiment of the present application uses 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 second key can be associated with the first information, and the implementation method of the first key can be indicated by the information of the second key corresponding to the first information.

For clarity of description, each embodiment of the present application uses ECU-1 as an example of the first ECU. It should be understood that ECU-1 can also be replaced by other representations of the first ECU.

Illustratively, the second key is an authentication key, such as MEK. As mentioned before, in addition to being used to authenticate at least one function key of ECU-1, MEK can also be used to authenticate the hardware function key of ECU-1. The hardware function key here can be multiple or one, and there is no specific limit. As a possible implementation, the MEK can be obtained from KMS.

It should be noted that at least one function key of ECU-1 can include one of the following implementation methods:

Method 1: A function key for ECU-1. Further, the function key may correspond to one or more service functions of the ECU-1. For example, this function key can be used for board-side encrypted communication and/or device authentication.

Method 2: Multiple function keys of ECU-2. Further, for example, 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; for example, the ECU-1 Multiple function keys can also be used for the same service. For example, when ECU-1 communicates with different ECUs (such as ECU-2 and ECU-3) in the vehicle, different function keys (such as board-side encrypted communication) can be used. key) to achieve board-side encrypted communication, that is, ECU-1 and ECU-2 can share the same function key, for example, recorded as function key 1; ECU-2 and ECU-3 can share another function key. key, for example, recorded as function key 2.

In addition, as mentioned above, the MEK can also be configured to authenticate at least one function key of multiple ECUs, and the at least one function key corresponds to at least one service function of the multiple ECUs. Illustratively, at least one business function of the multiple ECUs may include one of the following implementation methods:

Method A: One function key for multiple ECUs. Further, the function key may correspond to one or more business functions of the multiple ECUs. For example, if multiple ECUs are used for board-side encrypted communication, the multiple ECUs can use the same function key (such as the board-side encrypted communication key) to implement board-side encrypted communication, or the function key can be used in addition to the board-side encrypted communication key. End-to-end encrypted communication can also be used for device authentication.

Method B: Multiple function keys for multiple ECUs. Further, the multiple function keys may correspond to one business function or multiple business functions of the multiple ECUs. For example, 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; for another example, some of the multiple ECUs correspond to one type of business, and some The ECU corresponds to another service. At this time, these multiple function keys can correspond to different services respectively.

It should be noted that in the embodiment of the present application, the function key corresponds to a business function, which can be understood to mean that the function key will be used in the process of realizing the business function.

For example, the first key may be a functional key or a temporary key. The temporary key may include a MEK or a derived key of the function key, which is used for encryption and/or integrity protection of the generated intermediate key. In this embodiment of the present application, in order to implement integrity verification of the MEK, the first key can be used as the intermediate key. In a possible implementation manner, the first key can be obtained from KMS. For example, the first key may be a key pre-generated by KMS and stored in a locally maintained database, or it may be a randomly generated key. This is not limited in the embodiments of the present application. In order to simplify the description, the following content in the embodiment of the present application is described using VRF_K as a representation form of the first key. It can be understood that the first key may also have other representation forms.

In a possible implementation, the first information includes information encrypted and/or integrity protected through MEK. Based on this, KMS can realize that the first information indicates the first key through the information of the second key. For example, for example, 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.

In yet another possible implementation, the first information includes information encrypted and/or integrity protected using the derived key of the MEK. Based on this, KMS can realize that the first information indicates the first key through the information of the second key. The first information may be information obtained by encrypting and/or integrity protecting calculations using one or more derived keys of the MEK. Further, in an optional design, the first information may be used to write VRK_K. Since the first information includes information obtained by encryption and/or integrity protection using 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. It should be noted that in various embodiments of the present application, the information obtained by integrity protection using the MEK derived key may include information obtained by using the MEK derived key combined with one or more algorithms in the integrity protection algorithm. Information is not specifically limited in the embodiments of this application. For example, the information obtained by combining the MEK derived key with the label calculation algorithm in the integrity protection algorithm can be understood as the information obtained by integrity protection using the MEK derived key. It should be understood that a derived key can be used for encryption and integrity protection calculations, or it can be used only for encryption or integrity protection calculations. Based on this, when a derived key is only used for encryption or integrity protection calculations, the first information needs to implement encryption and integrity protection calculations through multiple derived keys of the MEK.

For example, KMS can use KDF to derive two derived keys K1' and K2' corresponding to MEK based on MEK, parameters Key_update_ENC_C and Key_update_MAC_C. These two derived keys are used for encryption and integrity protection respectively. Among them, the specific values of the parameters Key_update_ENC_C and Key_update_MAC_C may be predefined, for example, in relevant technical specifications. The technical specifications may be, for example, the security hardware extension SHE technical specifications released by the AUTOSAR organization. K1’, K2’ can be realized by the following formula (1) and formula (2), for example:

K1’ = first KDF (MEK, Key_update_ENC_C) formula (1)

K2’ = first KDF (MEK, Key_update_MAC_C) formula (2)

Thereafter, KMS can encrypt VRK_K based on the above K1' through the encryption algorithm to obtain the third information included in the first information. For example, KMS uses the AES algorithm to encrypt VRK_K by K1'; KMS can also use the MAC algorithm to encrypt VRF_K based on K2'. Integrity protection results from fourth information included in the first information. It should be understood that encryption algorithms and integrity protection algorithms include but are not limited to the specific implementations described above, and are not specifically limited in the embodiments of the present application.

Further, the KMS can also concatenate the identity information of ECU-1, the index of VRF_K, and the index of MEK to obtain the second information included in the first information.

Among them, the index of VRF_K can be used to uniquely identify VRF_K, and the index of MEK can 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 do not cover each other, thereby ensuring the 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 of the VRF_K stored in ECU-1. Similarly, the index of MEK can be used to indicate that MEK is stored 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 specifications, 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 can correspond to function keys, and RAM_KEY can correspond to temporary keys.

The identity information of ECU-1 is the identity identifier of ECU-1 or the group identifier of ECU-1.

In this embodiment of the present application, the identity of ECU-1 is used to uniquely identify the ECU-1. For example, the identity of ECU-1 includes: the device identification code of ECU-1 and the device type of ECU-1. The device identification code of ECU-1 may be, for example, a part number (PART#), and the device type of ECU-1 may include, for example, but is not limited to: engine management system (engine management system, EMS), automatic transmission control Transmission control unit (TCU), body control module (BCM), electronic stability program (ESP), battery management system (BMS), vehicle control unit, VCU), etc. In some cases, the device identification code of ECU-1 may include indication information of the device type of the ECU-1. In this case, ECU-1 may be directly identified by the device identification code.

In this embodiment of the present application, 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. For example, the group identifier of ECU-1 can be used to identify the production line batch corresponding to the ECU-1. Correspondingly, all 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 device type corresponding to the ECU-1. Correspondingly, all ECUs included in the device group to which the ECU-1 belongs correspond to the same device type; and/or, the ECU- The group identifier of 1 can be used to identify the service function corresponding to the ECU-1. Correspondingly, all ECUs included in the device group to which the ECU-1 belongs correspond to the same service function. For example, the equipment identification code of an ECU consists of W digits, of which 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 Information unique to other ECUs in the device group, W=W1+W2. In this case, 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 device group. The wildcard character may be implemented by special characters such as #, %, #, etc. , can also be achieved through special number combinations such as all-0 number combinations. It should be understood that wildcards are included in the group identifier based on ECU-1, so that the second information can be valid for multiple ECUs, thereby enabling KMS to flash the first keys of multiple ECUs in batches, thus saving signaling overhead.

In order to further understand how the first information indicates VRF_K through the MEK information, the following illustrates an implementation of the first information. Specifically, the first information includes second information M1', third information M2' and fourth information M3'. For example, the first information can be expressed as M1'||M2'||M3'. Where M1' can be M1'=UID||VRF_K_ID||MEK_ID, UID represents the identity information of ECU-1, VRF_K_ID and MEK_ID represent the index of the first key and the index of MEK respectively, || represents the information cascade operation, for example A||B means concatenating information A and B. M2' can be M2'=ENC _{CBC,K1',IV'=0} (C _ID '||F _ID '||VRF_K), that is, after KMS cascades C _ID ', F _ID ' and VRF_K, and then K1 ' is the key that is encrypted in CBC mode to form the third information. M3' can be M3'=CMAC _K2' (M1'||M2'), that is, the MAC value calculated by KMS through CMAC after concatenating M1' and M2' using K2' as the key is M3 '. In the above process, K1' and K2' are both derived keys of MEK. C _ID ' is the count value output by the KMS local counter (count, CNT), which can be used for counting. It can be automatically added by 1 before each encryption. Subsequently, by verifying the size relationship between the received CNT and the locally generated CNT, it can be achieved The purpose of preventing replay attacks is that the attacker sends a packet that has been received by the destination host to deceive the system. It is mainly used in the identity authentication process to destroy 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. The security flag can include the write protection flag (WRITE_PROTECTION), the startup protection flag (BOOT_PROTECTION), the debugging Protection flag (DEBUGGER_PROTECTION), key usage flag (KEY_USAGE), wildcard flag (WILDCARD), IV'=0 indicates that the initialization vector used for encryption based on CBC mode is an all-0 vector. It should be noted that in the embodiment of the present application, in addition to the above information, the above-mentioned cascade information may also include other information, which is not specifically limited in the embodiment of the present application. It should be understood that 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 on the embodiments of the present application. Encryption algorithms and integrity protection algorithms may also include but are not Limited to the specific implementation described above, the embodiments of the present application are not specifically limited here.

In this embodiment of the present application, the second verification information includes information used for VRF_K integrity verification. For example, the second verification information includes VRF_K, which can be used to verify the integrity of VRF_K. Specifically, the client can determine the local verification information by receiving the VRF_K and combining it with the locally generated first verification parameter. The local verification information can be used Integrity verification of VRF_K and/or MEK. For another example, the second verification information includes a second verification parameter and information obtained by performing integrity protection on the second verification parameter through VRF_K. The second verification parameter is used to verify the integrity of VRF_K. The second verification parameter may be KMS random. The generated information can also be information generated by KMS according to certain rules, or information generated by other methods, which is not specifically limited here. In an optional design, the second verification parameter (for example, marked as VRF_M) and the information obtained by integrity protecting the second verification parameter through VRF_K (for example, marked as VRF_MAC) satisfy the following relationship: VRF_MAC=CMAC _{VRF_K} (VRF_M ). KMS uses VRF_K as the key to generate the integrity verification information (i.e. VRF_MAC) of VRF_K through CMAC calculation. VRF_MAC can be used to characterize the integrity of VRF_K.

S202: The key management entity sends the first information and the second verification information to the client.

Correspondingly, the client receives the first information and the second verification information from the key management entity.

In this embodiment of the present application, the client can be used for key writing, that is, the client can write keys (such as authentication keys, authentication keys, and other temporary keys) into the ECU in the vehicle. For example, the client can be an OEM key flashing device, a dealer diagnostic instrument, or an on-board diagnostic (On Board Diagnostics, OBD). The OEM key writing 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 writing device, which is not specifically limited in the embodiments of this application. In addition, the client can also include an OEM server or a dealer server.

For example, if the client is an OEM key writing device, KMS sends the first information and the second verification information to the client, which may include: KMS directly sends the first information and the second verification information to the OEM key writing 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 writing device.

For example, if the client includes an OEM server and an OEM key writing device, 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 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.

For example, if the client is a dealer diagnostic device, 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 dealer diagnostic device, or the KMS first sending the first information and the second verification information to the dealer diagnostic device. 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.

For example, if the client includes a dealer server and a 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. Further, 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. In the latter case, the OEM server may first receive the first information and the second verification information from the KMS.

For clarity of description, the embodiments of this application are described using an OEM key writing device as an example of a client. It can be understood that the OEM key writing device can also be replaced by other forms of clients.

In this embodiment of the present application, the first information may be applied to one ECU or to multiple ECUs, and the second verification information may be applied to one ECU or to multiple ECUs. For example, the ECUs to be verified for MEK integrity include ECU-1, ECU-2 and ECU-3. In one case, these three ECUs can correspond to the same VRF_K. Correspondingly, the KMS can pass the same VRF_K. A message indicates the first key, and the second verification information corresponding to these three ECUs is also the same; in another case, these three ECUs can correspond to different VRF_K, and accordingly, the first verification information corresponding to these three ECUs The information is different from each other, and the corresponding second verification information is also different from each other.

It should be understood that the KMS may carry and 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 second information, third information and fourth information, the KMS can use different signaling to send the different information included in the first information respectively, or it can also send the different information included in the first information through the same process. One piece of 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, as well as the second verification information-1, the second verification information-2, and the second verification information-3. In this case, KMS can carry different first information and different second verification information in the same signaling and send it, or it can send the first information-1, the first information-2 and the first information-2 through different signaling respectively. 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 used through different signaling. Send them to the OEM key flashing device respectively, such as the first information-1 and the first verification information-1 through signaling 1, the first information-2 and the first verification information-2 through signaling 2, and the first information-2 and first verification information-2 through signaling 2. 3. Send the first information-3 and the first verification information-3 to the OEM key flashing device. Further, the OEM key flashing device can send these information to respective corresponding ECUs. The KMS may also send the first information and the second verification information in other ways, which are not specifically limited in the embodiments of this application.

S203. The OEM key rewriting device sends the first information and the first verification parameter to the ECU-1.

Accordingly, ECU-1 receives the first information and the first verification parameter.

The OEM key flashing device forwards the first information from the KMS to the ECU-1, so that the ECU-1 can determine VRF_K based on the first information.

It should be noted that in each embodiment of the present application, forwarding can be understood as transparent transmission, that is, in this scenario, the OEM key flashing device can directly transparently transmit the first information of the KMS to ECU-1. In this process , the OEM key device does not perform any processing on the first information.

In the embodiment of this application, the first verification parameter is used to verify the integrity of VRF_K. For example, the first verification parameter is the second verification parameter, that is, the OEM key flashing device can directly forward the second verification parameter from the KMS to the first ECU. For another example, the first verification parameter is information generated by the OEM key writing device, such as information generated randomly by the OEM key writing device, or information generated by the OEM key writing device according to certain rules. In addition, the OEM key flashing device can also generate the first verification parameter through other methods, which are not specifically limited here. It should be understood that the first verification parameter may also be applied to multiple ECUs, that is, the first verification parameter may be the same for multiple ECUs including ECU-1.

It should be understood that the OEM key flashing device carries the first information and the first verification parameter in the same signaling and sends it to save signaling overhead, or it can also send the first information and the first verification parameter separately through different signaling. , achieving flexibility in indication of the first information and the first verification parameter.

It should be noted that in the embodiment of the present application, the OEM key writing device can directly send the first information and the first verification parameter to the ECU-1. For example, the OEM key writing device is directly connected to the ECU-1. and send the first information and the first verification parameter to ECU-1; or, if the functional component including the ECU-1 supports the forwarding mechanism, the OEM key flashing device can send the first information and the first verification parameter first. is sent to the functional component, and then the functional component sends the first information and the first verification parameter to ECU-1 through the internal forwarding mechanism. In this case, it can be understood that the OEM key flashing device can communicate with the Functional components are directly connected. For example, the functional component is a domain controller (DC) containing one or more ECUs or a key management system in the car. In addition, in various embodiments of the present application, the domain controller can also be regarded as an electronic functional component ECU, that is, the domain controller can directly receive the first information from the client.

S204, ECU-1 generates first verification information based on the MEK and the first verification parameter.

The first verification information is used to represent the integrity of the first key.

Exemplarily, ECU-1 generates first verification information based on MEK and the first verification parameter, which may include: ECU-1 decrypts and/or integrity checks the received first information through MEK to determine VRF_K, Then, according to the VRF_K and the received first verification parameter, first verification information used to represent the integrity of the first key is generated. Further, in an optional design, ECU-1 decrypts and/or integrity checks the received first information through MEK to determine VRF_K, which may include: ECU-1 first based on the received first information For a piece of information, it is determined that the MEK is used to decrypt and/or integrity check the first information, and then the locally saved MEK is used to perform specific decryption and/or integrity check on the first information, and then the VRF_K is determined. In addition, ECU-1 can obtain the first verification information based on the MAC algorithm through the determined VRF_K and the first verification parameter. For example, the first verification information (such as MAC_T) and the first verification parameter (such as VRF_M) satisfy the following relationship :MAC_T=CMAC _{VRF_K} (VRF_M).

In an optional design, after the ECU-1 determines VRF_K, it can store VRF_K locally.

Corresponding to a specific implementation method of the first information in step S201, the following example illustrates a specific implementation method for ECU-1 to generate the first verification information based on the MEK and the first verification parameter. In this example, the first information It includes second information M1', third information M2' and fourth information M3'. For the specific implementation of M1', M2' and M3', reference can be made to the corresponding description in step 201, which will not be described again here. ECU-1 determines the index of the MEK (i.e. MEK_ID) based on the received M1'. Based on this, ECU-1 uses the locally saved key corresponding to the MEK_ID as the MEK for integrity verification and decryption of the VRF_K. For example, ECU-1 can first complete the integrity check of VRF_K or the first information based on the locally saved MEK and the received M3' 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 then decrypts M2' according to the locally saved MEK to determine VRF_K. In an optional design, after ECU-1 determines VRF_K, it can store the VRF_K determined by decrypting M2' in the local memory corresponding to the address information based on the address information indicated by the index of VRF_K included in M1'. . Further, after determining VRF_K, ECU-1 can generate the first verification information based on the determined VRF_K and the first verification parameter. For the specific generation process, please refer to the above description, which will not be described again here.

It should be noted that 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. '. It should be understood that the derivation algorithm used by ECU-1 in the process of determining VRF_K is the same as the derivation algorithm used by KMS in the process of determining the first information. The derivation algorithm may be an algorithm pre-configured in ECU-1.

S205, ECU-1 sends the first verification information to the OEM key flashing device.

Correspondingly, the OEM key flashing device receives the first verification information.

S206: The OEM key rewriting device determines the integrity of the MEK based on the local verification information and the first verification information, where the local verification information is information obtained by integrity protection through VRF_K and the first verification parameter.

In a possible implementation, the local verification information comes directly from the KMS. For example, the local verification information is the information obtained by integrity protecting the second verification parameter through VRF_K (for example, recorded as VRF_MAC) included in the second verification information in step 201. ). In this case, 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 (for example, marked as MAC_T) from the ECU-1, and determines the integrity of the MEK based on the comparison result. Based on the above description, it should be understood that since VRF_MAC is obtained by KMS based on VRF_K and the second verification parameter, and MAC_T is obtained by ECU-1 based on the locally determined VRF_K and the first verification parameter, therefore by comparing VRF_MAC and MAC_T, it can Determine whether the VRF_K determined locally by ECU-1 is the same as the VRF_K from the KMS. And because the VRF_K from KMS is indicated by the MEK information, and the VRF_K determined locally by ECU-1 is determined based on the locally saved MEK, therefore equivalently, by comparing VRF_MAC and MAC_T, the local VRF_K of ECU-1 can be determined Whether the saved MEK is the same as the MEK saved by KMS, thereby realizing the integrity verification of the MEK saved locally in ECU-1. Specifically, if VRF_MAC matches MAC_T (for example, MAC_T==VRF_MAC), it can be determined that the MEK locally saved by ECU-1 is complete; otherwise, it can be determined that the MEK locally saved by ECU-1 is incomplete. For example, MAC_T==VRF_MAC may indicate that the bit value of each bit position included in MAC_T is the same as the bit value of the corresponding bit position included in VRF_MAC.

It should be noted that in an optional design, the MEK saved locally by ECU-1 is complete and can include: the MEK saved locally by ECU-1 is the same as the MEK saved by KMS, or the MEK saved locally by ECU-1 The MEK is a valid key. In an optional design, the MEK saved locally by ECU-1 is incomplete, which may include: the MEK saved locally by ECU-1 is different from the MEK saved by KMS, or the MEK saved locally by ECU-1 is not a valid password. key. It should be understood that only if the MEK stored locally in 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 vehicle.

In another possible implementation manner, the local verification information is information determined locally by the OEM key flashing device. Exemplarily, the OEM key flashing device determines local verification information based on the second verification information from the KMS and the locally generated first verification parameters, where the second verification information includes VRF_K. Specifically, in this manner, the local verification information (for example, recorded as VRF_MAC) and the first verification parameter (for example, as VRF_M) satisfy: VRF_MAC=CMAC _{VRF_K} (VRF_M). Similarly, since VRF_MAC is obtained by the OEM key flashing device based on the VRF_K from the KMS and the locally generated first verification parameter, and MAC_T is obtained by ECU-1 based on the VRF_K determined locally and the VRF_K 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 ECU-1 is the same as the VRF_K from KMS. Equivalently, by comparing VRF_MAC and MAC_T, it can be determined whether the MEK saved locally by ECU-1 is the same as the MEK saved by KMS, thereby achieving integrity verification of the MEK saved locally by ECU-1. Through the comparison results of VRF_MAC and MAC_T, the specific implementation of determining MEK integrity can refer to the above description, and will not be described in detail.

Based on the above description, it can be understood that 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 that the functional key normal use and information security of the entire vehicle, and because the OEM key flashing device between KMS and ECU-1 indicates the first key by directly forwarding the first information from KMS, therefore, the second key is avoided. The second key is exposed outside the KMS and ECU in plain text, thereby ensuring the security of the OEM's core assets. In addition, the information used for the integrity verification of the first key does not include the identification information of the ECU. Therefore, the vehicle production line does not need to collect the identification information of all target ECUs to be updated with the second key in advance, thereby reducing the cost of the entire vehicle. The burden and management costs of the production line. Further, the KMS can also prepare the filling key material for the first key integrity verification in advance (such as the first information and the second verification information in the above embodiment), and send it to the OEM key in advance The flash writing device can also realize offline verification of the second key of the ECU based on this, that is, it does not rely on KMS and can also realize real-time verification of the integrity of the second key, reducing time overhead. It should be understood that this solution also avoids the deployment of KMS near the existing vehicle production line, simplifies the design of the vehicle production line, and reduces the management cost of the vehicle factory.

Through the key verification method shown in Figure 2, the integrity verification of the second key can be achieved. In an optional design, before sending the first information, KMS can also write the second key into the ECU through the client. For example, when the second key saved locally by the ECU is different from the second key saved by the KMS, in order to ensure the normal use of the function key of the ECU, the KMS needs to first write the second key saved locally by the KMS into in the ECU. For example, during the vehicle production process, the OEM can first pass some preset root keys to 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 for the ECU. Then these ECUs with preset root keys written into them are transported to the vehicle production line, where the OEM replaces the ECU's preset root keys with MEK to ensure that the function key can be written into the ECU. , to ensure the normal use of the ECU. It should be understood that due to the key attribute of MEK, in this scenario, the second key saved locally by the ECU (which can be understood as the preset root key, or the initial hardware permission key) and the second key saved by the KMS (to be The written MEK) is different; for another example, during the use of the vehicle, there will inevitably be hardware damage or hardware upgrades. At this time, a repair party (such as a 4S store) authorized by the OEM or component developer is required to repair the damaged Or the ECU that needs to be upgraded is replaced with a new ECU. It should be understood that in this scenario, the second key saved locally by the new ECU may be different from the second key saved by the KMS. At this time, in order to ensure that the replaced ECU can work normally, the function key needs to be written to the new ECU. As mentioned above, the successful writing of the function key requires the authentication key to be authenticated first, so the 4S store needs to first The second key saved by KMS is written into the ECU through the key flashing device. After the KMS writes the second key into the ECU, it implements integrity verification of the second key based on the method in the embodiment shown in FIG. 2 .

Based on this, as a possible implementation method, the key verification method described in the embodiment of the present application can 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.

It should be noted that, in order to better understand the relationship between the methods described in the following embodiments and the method in the embodiment shown in FIG. 2, ECU-1 is still used as an example of the first ECU below. KMS is an example of the key management entity, the OEM key flash device is an example of the client, MEK is an example of the second key, and VRF_K is an example of the first key. The details of steps S301-S304 are as follows:

S301, 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. For example, the fifth key may be a pre-master ECU key (PMEK) preset in ECU-1, or may be a previous version of the MEK stored locally in ECU-1. For example, the MEK saved locally in KMS is MEK2.0, and the previous version of the MEK saved locally in ECU-1 is MEK1.0. In this case, the MEK1.0 saved locally in ECU-1 needs to be authenticated before the ECU can be MEK1.0 in -1 is replaced with MEK2.0 to ensure the normal use of the ECU-1 function key. For clarity of description, each embodiment of the present application uses PMEK as an example of the fifth key. It can be understood that PMEK can also be replaced by other authentication keys used to authenticate MEK.

In a possible implementation manner, the fifth information indicates MEK through PMEK information, and may include: the fifth information includes information obtained by encryption and/or integrity protection calculation through PMEK. Based on this, KMS can realize that the fifth information indicates the second key through the PMEK information. Illustratively, for example, the fifth information may include information generated based on the authentication key PMEK and the key MEK to be written through an encryption algorithm and/or an integrity protection algorithm, and the fifth information may be used to write the MEK.

In yet another possible implementation manner, the fifth information indicates the MEK through the PMEK information, and may include: the fifth information includes information obtained by encrypting and/or integrity protecting using the derived key of the PMEK. Based on this, KMS can realize that the fifth information indicates MEK through PMEK information. The fifth information may be information obtained by encryption and/or integrity protection calculations using one or more derived keys of the PMEK and the fifth information may be used to write the MEK. Here, 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 calculations, the fifth information needs to implement encryption and integrity protection calculations through multiple derived keys of PMEK.

For example, KMS can use KDF to derive two derived keys K1 and K2 corresponding to PMEK based on PMEK, parameters Key_update_ENC_C and Key_update_MAC_C. These two derived keys are used for encryption and integrity protection respectively. Among them, the specific values of the parameters Key_update_ENC_C and Key_update_MAC_C may be predefined, for example, in relevant technical specifications. The technical specification may be, for example, the SHE technical specification published by the AUTOSAR organization. K1 and K2 can be realized by the following formula (3) and formula (4), for example:

K1=Second KDF(PMEK,Key_update_ENC_C) Formula (3)

K2 = second KDF (PMEK, Key_update_MAC_C) formula (4)

Thereafter, KMS can encrypt MEK based on the above K1 through the encryption algorithm to obtain the seventh information included in the fifth information. For example, 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. It should be understood that encryption algorithms and integrity protection algorithms include but are not limited to the specific implementations described above, and are not specifically limited in the embodiments of the present application.

Further, the KMS may also concatenate the identity information of the ECU-1, the index of the MEK, and the index of the PMEK to obtain the sixth information included in the fifth information. Among them, the identity information of ECU-1 and the index of MEK can refer to the specific description in S201 above, which will not be described again here. The index of PMEK is used to uniquely identify PMEK and can be used to indicate the address information of PMEK stored in ECU-1. It should be noted that when the identity information of ECU-1 is a group identifier containing wildcard characters, the fifth information can be effective for multiple ECUs, thereby enabling KMS to batch flash the second keys of multiple ECUs, saving time. Signaling overhead.

In order to further understand how the fifth information indicates MEK through PMEK information, the following illustrates an implementation method of the fifth information. Specifically, the fifth information includes sixth information M1, seventh information M2, and eighth information M3. Where M1 can be M1=UID||MEK_ID||PMEK_ID, UID represents the identity information of ECU-1, MEK_ID and PMEK_ID represent the index of MEK and the index of PMEK respectively, || represents information cascade operation, for example, A||B represents Concatenate information A and B. M2 can be M2=ENC _{CBC, K1, IV=0} (C _ID ||F _ID ||MEK), that is, KMS concatenates C _ID , F _ID and MEK, and then uses K1 as the key to encrypt it in CBC mode. Seventh message. M3 can be M3=CMAC _K2 (M1||M2), that is, the MAC value calculated by KMS through CMAC after concatenating M1 and M2 using K2 as the key is M3. In the above process, K1 and K2 are both derived keys of PMEK. C _ID is the count value output by the local counter CNT of KMS. It can be used for counting. It can be automatically incremented by 1 before each encryption. Subsequently, by verifying the size relationship between the received CNT and the locally generated CNT, it can prevent replay attacks. Purpose. F _ID is used to configure the security flag of the storage area corresponding to MEK_ID. For specific instructions on the security flag, please refer to the relevant instructions in S201, which will not be described here. IV=0 means that the initialization vector used for encryption based on CBC mode is an all-0 vector. It should be noted that in the embodiment of the present application, in addition to the above information, the above-mentioned cascade information may also include other information, which is not specifically limited in the embodiment of the present application. It should be understood that 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 on the embodiment of the present application. Those skilled in the art know that the encryption algorithm and the integrity protection algorithm may also include but are not limited to the specific implementation methods described above, and are not specifically limited here in the embodiments of the present application.

S302: KMS sends fifth information to the OEM key writing device.

Correspondingly, the OEM key flashing device receives the fifth information. Similarly, if the fifth information includes multiple pieces of information, for example, the fifth information includes sixth information, seventh information and eighth information, the KMS can use different signaling to send different information included in the fifth information respectively, or All information included in the fifth information may also be sent through the same signaling. In addition, the KMS can also carry the fifth information (or part of the information included in the fifth information) together with other information sent to the OEM key flashing device (such as the first information or part of the information included in the first information). It can be sent in one signaling, or it can be sent in different signaling. The embodiments of this application do not limit the specific manner of transmitting the fifth information.

S303. The OEM key writing device sends the fifth information to ECU-1.

Accordingly, ECU-1 receives the fifth information. The OEM key flashing device forwards the fifth information from the KMS to the ECU-1, so that the ECU-1 can determine the MEK based on the fifth information. For the specific implementation method of the OEM key flashing device sending the fifth information to the ECU-1, please refer to the corresponding description in S203, which will not be described again here.

S304, ECU-1 determines the MEK based on the fifth information.

For example, ECU-1 determines the MEK based on the fifth information, which may include: ECU-1 decrypts and/or integrity checks the received fifth information based on the PMEK to determine the MEK. Specifically, for example, ECU-1 first determines to use PMEK to decrypt and/or integrity check the fifth information based on the received fifth information, and then performs specific decryption of the fifth information through the locally saved PMEK. and/or integrity check to determine the MEK.

Corresponding to a specific implementation method of the fifth information in step S301, the following example illustrates a specific implementation method for ECU-1 to determine MEK based on the fifth information. In this example, the fifth information includes sixth information M1, For the seventh information M2 and the eighth information M3, the specific implementation of M1, M2 and M3 can refer to the corresponding description in step S301, and will not be described again here. ECU-1 determines the index of the PMEK (ie, PMEK_ID) based on the received M1. Based on this, ECU-1 uses the locally saved key corresponding to the PMEK_ID as the PMEK for integrity verification and decryption of the MEK. For example, ECU-1 can first complete the integrity check of the MEK or the fifth information based on the locally saved PMEK and the received M3 to ensure that the MEK or the fifth information has not been tampered with. When the integrity verification of the MEK or the fifth information is successful, ECU-1 then decrypts M2 based on the locally saved PMEK to determine the MEK.

Further, after determining the MEK, the ECU-1 stores the MEK locally. For example, 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 index of the MEK included in M1 (ie, MEK_ID), or store the locally saved PMEK Replace with this MEK.

Based on the method in the embodiment shown in Figure 3, before verifying the MEK, the MEK can be written into the ECU first, thereby satisfying the requirements of the vehicle production line and/or the repair party authorized by the vehicle manufacturer to correctly write the MEK first. The requirements of the electronic control unit will provide authentication conditions for subsequent writing of function keys, ensuring the normal use of function keys and the information security of the entire vehicle. 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 OEMs can be simplified. Simplify the key writing process. In addition, since the second information includes information obtained by encrypting and/or integrity protecting the MEK, it can also be avoided that the MEK is exposed in plain text outside the KMS and ECU during the writing process of the MEK, thereby ensuring that the OEM Security of core assets.

Further, in an optional design, the key verification method described in the embodiments of this application may also include one or more of steps S401-S404 shown in Figure 4. The one or more steps This step may be necessary for some specific scenarios. The details of steps S401-S404 are as follows:

Step S401: The OEM key rewriting device sends MEK update request information to the KMS.

Correspondingly, KMS receives the MEK update request information.

The MEK update request information is used to request to update the MEK of ECU-1. Alternatively, the MEK update information can be used to request KMS to verify the integrity of the MEK stored locally in ECU-1, or the MEK update request information can be used to request KMS to write the MEK to ECU-1 (including the integrity of the MEK verify).

In an optional design, 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 with the MEK (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 in the ECU, and the different version numbers of the ECU. The identity authentication information can be used to represent whether the OEM key writing device has the authority to obtain one or more pieces of information obtained from the key management entity by the client included in the embodiments of this application, such as the first information. , fifth information, and 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 locally saved authentication key of the ECU. For example, the locally saved authentication key is PMEK, or MEK1.0, or MEK2.0, etc. It should be understood that the above-mentioned ECU to be updated with MEK or the ECU with MEK integrity verification includes ECU-1.

Step S402: KMS verifies the MEK update request information.

Correspondingly, after receiving the MEK update request information, the KMS can verify the MEK update request information. And based on the verification result, it is determined whether or not the method described in the embodiment of the present application is passed, and the first information used to indicate the first key and the second verification used for the integrity verification of the first key are 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. Information is sent to the OEM key flashing device.

In an optional design, KMS verifies the MEK update request information, which may include one or more of the following: KMS verifies the validity of the MEK update request information, and KMS determines whether to write the MEK (including the MEK The KMS determines the specific information used to verify the integrity of the MEK.

For example, KMS verifying the legality of the MEK update request information can be understood as: KMS determines whether the OEM key flash device that initiated the MEK update request information has the authority to obtain the key information related to MEK writing and/or integrity verification. Information, such as the first information, the fifth information, and the second verification information in the embodiments of the present application; or, KMS verifying the legitimacy of the MEK update request information can also be understood as: KMS uses the OEM key flash device The identity authentication information determines whether the OEM key writing device is an OEM-authorized key writing device. If the OEM key flash device is an OEM-authorized key flash device, it can be assumed that the OEM key flash device has the authority to obtain information related to MEK writing and/or integrity verification, such as the implementation of this application. The first information, the fifth information, and the second verification information in the example. For example, for after-sales maintenance scenarios, the identity authentication information can indicate whether the 4S store or maintenance party that initiated the MEK update request is an OEM-authorized dealer. It should be understood that in this scenario, the OEM key flash device can be replaced by a dealer diagnostic device. If the identity authentication information can represent the 4S store or repair party as an OEM-authorized dealer, KMS can send MEK writing and/or integrity verification-related information to the dealer diagnostic instrument. Based on this, it can be ensured that information related to MEK writing and/or integrity verification is only provided to KMS or clients authorized by the OEM, thus ensuring the security of MEK.

For example, KMS can determine the specific information used to write the MEK (including 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. Among them, the following information is: the number of ECUs whose MEK needs to be updated (or the number of ECUs whose integrity needs to be verified), the vehicle identification number (VIN) to which the ECU belongs, and the authentication key stored locally in the ECU. Version number, different version numbers of the ECU. For example, KMS can determine one or more of the following information through the number of ECUs whose MEK needs to be updated or the number of ECUs whose MEK integrity needs to be verified: the number of first information, the number of second verification information, and the fifth information. The number can then realize batch writing of MEK and/or batch integrity verification of MEK for batch ECUs, reducing the cost of key management. For another example, KMS can determine the version number of the MEK to be written through different version numbers of the ECU or the version number of the authentication key stored locally in the ECU, thereby ensuring effective MEK writing, and further writing functions based on the MEK. key to ensure the normal use of the ECU.

In an optional design, before step S401, step S403 may also be included. Step S403 is specifically as follows:

S403, ECU-1 sends the locally saved MEK version number to the OEM key flashing device.

Correspondingly, the OEM key flashing device receives the version number of the locally saved MEK.

In an optional design, 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, namely VIN, the Different version numbers, device identification code of ECU-1, and device type of ECU-1.

It should be understood that the OEM key flashing device can determine the number of ECUs whose MEK needs to be updated or the number of ECUs whose MEK integrity needs to be verified by collecting the above information of multiple ECUs.

S404: The OEM key rewriting device sends the MEK update result to the KMS.

Accordingly, the KMS receives the OEM key flashing device.

The update result of the MEK includes one or more of the following: MEK integrity, VRF_K integrity, and ECU-1 identity. The integrity of the MEK is used to indicate whether the MEK is written to ECU-1 and passes the integrity verification, or the integrity of the MEK is used to indicate whether the MEK saved locally by KMS is the same as the MEK saved locally by ECU-1; the integrity of VRF_K Used to characterize whether VRF_K is written to ECU-1 and passes integrity verification.

For example, based on the update result, KMS can determine whether the MEK has been completely written into ECU-1. If it is determined that the MEK has not been completely written into ECU-1, it can retry to write the MEK into the ECU through the OEM key flash 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.

In an optional design, as a possible implementation manner, before the methods in the above embodiments, steps S401 to S403 shown in Figure 4 may be included, and after the methods in the above embodiments, Including step S404 shown in Figure 4.

Through the above MEK update request information, KMS can generate information suitable for MEK update or MEK integrity verification, thereby realizing MEK integrity verification and ensuring the normal use of function keys and the information security of the entire vehicle. Through the above update results, the KMS can determine whether the MEK is written to the first electronic control unit and/or determine whether the authentication key stored locally in the first electronic control unit is the MEK, thereby ensuring the normal use of the function key and the information of the entire vehicle. Safety. In addition, collecting the identity of the ECU-1 also facilitates the key management entity to manage the electronic control unit that writes the MEK and/or the electronic control unit that has verified the integrity of the authentication key.

In addition, as a possible implementation manner, the key verification method described in the embodiment of the present application may also include step S501-step S502 shown in Figure 5, or may also include step S501-step shown in Figure 5 S503. The details of steps S501-S503 are as follows:

S501, ECU-1 generates ninth information based on the first information and the challenge-response mechanism.

Among them, the ninth information includes information used to verify the integrity of VRF_K. For example, corresponding to a specific first information generation method in step S201, the ninth information generated here may include eleventh information and twelfth information, where the eleventh information is generated by at least the ECU-1 The identity identifier, the index of VRF_K, the index of MEK and the information obtained by cascading the thirteenth information. The twelfth information is the information obtained by integrity protecting the eleventh information through the derived key of VRF_K. The thirteenth information The information is information obtained by encrypting the count value (for example, C _ID ') contained in the first information using the derived key of VRF_K. It should be understood that based on this, not only the integrity verification of VRF_K can be achieved, but also the effect of anti-replay estimation can be achieved through the eleventh information including the thirteenth information. It should be noted that the derivation algorithm, encryption algorithm and integrity protection algorithm used to generate the derived key may include but are not limited to the specific implementation methods described above, and are not specifically limited here in the embodiments of the present application.

S502, ECU-1 sends the ninth information to the OEM key flashing device.

Correspondingly, the OEM key flashing device receives the ninth information.

In an optional design, 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, 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.

S503. The OEM key rewriting device sends the ninth information to the KMS.

Correspondingly, the KMS receives the ninth information.

In an optional design, the OEM key flashing device does not further process the received ninth information, for example, does not parse the ninth information.

In an optional design, KMS can determine the identity of ECU-1 based on the ninth information, which is used by the OEM to record the ECU that has confirmed the integrity of the MEK.

For example, in this scenario, ECU-1 may correspond to the responder in the challenge-response mechanism, and the OEM key rewriting device may correspond to the challenger in the challenge-response mechanism. The first information includes a message sent by the challenger. For the challenge, the ninth information may correspond to the corresponding response made by the responding party. The difference is that in this scenario, the OEM key flash device does not parse the ninth information, but sends it to KMS for further processing. KMS determines whether the responder has passed the challenge and/or judges the responder. whether it should be certified. Using this method, the integrity verification of VRF_K can be achieved, and the implementation is simple.

It should be noted that the ninth information may be used to indicate the integrity of VRF_K. Based on this, the ninth information may be understood as an example of the integrity information of 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.

In addition, when the key verification method described in the embodiments of this application includes the method in the embodiment shown in Figure 3, the key verification method described in the embodiment of this application may also include the method shown in Figure 6 Step S601 to step S602, or may also include step S601 to step S603 shown in FIG. 6 . The details of steps S601-S603 are as follows:

S601, ECU-1 generates the tenth information based on the fifth information and the challenge-response mechanism.

The tenth information includes information used to verify the integrity of the MEK. For example, corresponding to a specific fifth information generation method in step S301, the tenth information generated here may include fourteenth information and fifteenth information, where the fourteenth information is generated by at least the ECU-1 The identity identifier, the index of MEK, the index of PMEK and the information obtained by concatenating the sixteenth information. The fifteenth information is the information obtained by integrity protecting the fourteenth information through the derived key of MEK. The sixteenth information The information is information obtained by encrypting the count value (for example, C _ID ) contained in the second information using the derived key of the MEK. It should be understood that based on this, not only the integrity verification of the MEK can be achieved, but also the effect of anti-replay estimation can be achieved through the fourteenth information including the sixteenth information. It should be noted that the derivation algorithm, encryption algorithm and integrity protection algorithm used to generate the derived key may include but are not limited to the specific implementation methods described above, and are not specifically limited here in the embodiments of the present application.

S602. ECU-1 sends the tenth information to the OEM key flashing device.

Correspondingly, the OEM key flashing device receives the tenth information.

In an optional design, ECU-1 can carry the tenth information and other information sent to the OEM key flashing device (such as the first verification information, the ninth information) in the same signaling and send it, or The tenth information and other information sent to the OEM key flashing device may also be sent separately through different signaling.

S603. The OEM key rewriting device sends the tenth information to the KMS.

Correspondingly, the KMS receives the tenth information.

In an optional design, the OEM key flashing device does not further process the received tenth information, for example, does not parse the tenth information.

In an optional design, KMS can determine the identity of ECU-1 based on the tenth information, which is used by the OEM to record the ECU that has confirmed the integrity of the MEK.

For example, in this scenario, ECU-1 may correspond to the responder in the challenge-response mechanism, the OEM key rewriting device may correspond to the challenger in the challenge-response mechanism, and the fifth information includes a message sent by the challenger. For the challenge, the tenth information may correspond to the response made by the responding party. The difference is that in this scenario, the OEM key flashing device does not parse the tenth information, but sends it to KMS for further processing. KMS determines whether the responder has passed the challenge and/or judges the responder. whether it should be certified. Using this method, the integrity verification of MEK can be achieved and the implementation is simple.

It should be noted that 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 to the KMS by the OEM key flashing device. The update result may include the tenth information.

It should be noted that the steps included in the methods in the embodiments of the present application can be sequentially adjusted, combined, and deleted according to actual needs.

The key verification method provided by the embodiment of the present application is introduced above with reference to Figures 2 to 6. The device provided by the embodiment of the present application will be described in detail below with reference to Figures 7 to 9.

Figure 7 is a schematic block diagram of a control device provided by an embodiment of the present application. As shown in Figure 7, the control device may include at least one processor and a memory to execute the method in any of the above possible implementations. The memory is used to store computer programs or instructions, and the at least one processor is used to call the computer program or instructions in the memory. Exemplarily, the at least one processor may be used to perform internal processing within the control device, for example, generate first verification information based on the second key and the first verification parameter, and the first verification information is used to Characterizing the integrity of the first key; for another example, generating first information and second verification information; for another example, determining the integrity of the second key based on local verification information and the first verification information, The local verification information includes information obtained by performing integrity protection on the first verification parameter using the first key.

Further, in an optional design, the control device may also include a transceiver, as shown in FIG. 8 . Figure 8 is a schematic block diagram of a control device provided by an embodiment of the present application. Wherein, the transceiver is coupled with at least one processor and memory included in the control device. It can be understood that the transceiver, the at least one processor and the memory communicate with each other through internal connection paths. Specifically, the transceiver can provide information input and/or output to 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. For example, the transceiver can be used to receive the first information; for another example, the transceiver can be used to receive the first verification parameter; for another example, the transceiver can be used to send the first verification information, and so on.

In yet another implementation manner, the control device includes a unit for executing the method in any possible implementation manner in the embodiments of the present application.

In an optional design, the above-mentioned control device may be a control device of an electronic component, used to execute any of the methods executed by the ECU-1 above; or the above-mentioned control device may be a control device of a key management entity, used to execute Execute any method performed by the KMS above; or the above control device is a control device of the key flash tool, used to perform any method performed by the OEM key flash device above.

The embodiment of the present application also provides a vehicle. The vehicle includes a control device that implements any of the possible implementation methods executed by the ECU-1 above, or the vehicle includes a control device that implements the method executed by the ECU-1 above. Electronic components of the method in any of the possible ways.

The embodiment of the present application also provides a system, which system includes electronic components for executing any of the possible implementation methods executed by ECU-1 above, including electronic components for executing the method executed by ECU-1 above. A vehicle with a control device for the method in any possible implementation manner, a vehicle including an electronic component for executing the method in any possible implementation manner executed by the ECU-1 above, a vehicle for executing the above KMS method One of the key management entities that perform the method in any possible implementation manner, or the key flash tool used to perform the method in any possible implementation manner performed by the OEM key flash device above or more.

The embodiment of the present application also provides a system, which includes a control device for executing any of the methods in the possible implementation manners executed by the ECU-1 above, and a control device for executing any of the methods executed by the KMS above. A control device for a method in any possible implementation manner, or one or more control devices for executing the method in any possible implementation manner performed by the OEM key flashing device above.

In addition, the embodiment of the present application also provides a chip, as shown in Figure 9. Figure 9 shows a schematic structural diagram of a chip. The chip includes one or more processors and an interface circuit, which is used to provide information input and/or output to the one or more processors for executing the method in any of the above possible implementations. In an optional design, the chip can also include a bus. Wherein, for example, the processor is an integrated circuit chip with signal processing capabilities. For example, the processor may be a field programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), or an 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 (central unit processor, CPU), or network processing It can be a network processor (NP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips. Each method, step and logical block diagram disclosed in the embodiment of this application can be implemented or executed. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field. 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 to send or receive data, instructions or information. The processor can process the data, instructions or other information received by the interface circuit, and can send the processed information through the interface circuit.

In an alternative design, the chip also includes memory, which may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically removable memory. Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory may be random access memory (RAM), which is used as an external cache. By way of illustration, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synchlink DRAM, SLDRAM) ) and direct memory bus random access memory (direct rambus RAM, DR RAM).

It should be noted that the corresponding functions of the processor and the interface circuit can be realized through hardware design, software design, or a combination of software and hardware. There are no restrictions here.

It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

Embodiments of the present application also provide a computer program product. The computer program product includes: computer program code. When the computer program code is run on a computer, it causes the computer to execute any possible implementation performed by the first node above. method in the method, or execute the method in any possible implementation method executed by the second node above.

This application also provides a computer-readable medium, which stores program code. When the program code is run on a computer, it causes the computer to execute the method in any of the above possible implementation modes.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. 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 described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. 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, data center, etc. that contains one or more available media integrated therein. The usable media may be magnetic media (eg, floppy disks, hard disks, tapes), optical media (eg, high-density digital video discs (DVD)), or semiconductor media (eg, solid state discs, SSD)) etc.

Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be described again here.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the 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 they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application. should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (30)

A verification method, characterized by including: The first information is received by the client, the first information comes from the key management entity, the first information indicates the first key through the information of the second key, the second key is configured to authenticate the first key. At least one function key of the electronic control unit, the at least one function key corresponding to at least one service function of the first electronic control unit; receiving a first verification parameter from the client; Generate first verification information according to the second key and the first verification parameter, where the first verification information is used to characterize the integrity of the first key; Send the first verification information to the client. The method of claim 1, wherein the first information includes information encrypted and/or integrity protected using a derived key of the second key. The method of claim 1 or 2, wherein the first information includes: second information obtained by concatenating at least the identity information of the first electronic control unit, the index of the first key and the index of the second key, third information obtained by encrypting the first key with a third key, and Fourth information obtained by performing integrity protection on at least the information concatenated by the second information and the third information through a fourth key, wherein the third key and the fourth key are The derived key of the second key. The method according to any one of claims 1 to 3, characterized in that the method further includes: receiving, by the client, fifth information from the key management entity, the fifth information indicating the second key through information of the fifth key, Wherein, the fifth key is used to authenticate the second key. The method of claim 4, wherein the fifth information includes information encrypted and/or integrity protected using a derived key of the fifth key. The method of claim 4 or 5, wherein the fifth information includes: at least sixth information obtained by concatenating the identity information of the first electronic control unit, the index of the second key and the index of the fifth key, seventh information obtained by encrypting the second key with a sixth key, and The eighth information obtained by performing integrity protection on the information concatenated by at least the sixth information and the seventh information through a seventh key, wherein the sixth key and the seventh key are the The derived key of the fifth key. The method according to any one of claims 3 to 6, characterized in that the identity information of the first electronic control unit includes an identity identification of the first electronic control unit or a group identification of the first electronic control unit. ,in: The identity of the first electronic control unit is used to uniquely identify the first electronic control unit; The group identifier of the first electronic control unit includes at least one wildcard, and the group identifier of the first electronic control unit is used to identify the device group to which the first electronic control unit belongs. The method according to any one of claims 1 to 7, wherein the first verification information includes information obtained by integrity protecting the first verification parameter through the first key. A verification method, characterized by including: Generating first information and second verification information, the first information being indicative of a first key through information of a second key, the second key being configured to authenticate at least one functional 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, and the second verification information includes information used for integrity verification of the first key; Send the first information and the second verification information to the client. The method of claim 9, wherein the first information includes information encrypted and/or integrity protected using a derived key of the second key. The method according to any one of claims 9 or 10, characterized in that the method further includes: sending fifth information to the client, the fifth information indicating the second key through information of the fifth key, Wherein, the fifth key is used to authenticate the second key. The method of claim 11, wherein the fifth information includes information encrypted and/or integrity protected using a derived key of the fifth key. The method according to any one of claims 9 to 12, characterized in that the second verification information includes: a second verification parameter, and information obtained by integrity protecting the second verification parameter through the first key, Wherein, the second verification parameter is used to verify the integrity of the first key. The method according to any one of claims 9 to 13, characterized in that the method further includes: receiving second key update request information from the client, the second key update request information being used to request an update of the second key, Wherein, the second key update request information includes the identity authentication information of the client. The method according to any one of claims 9 to 14, characterized in that the method further includes: Receive an update result of the second key from the client, the update result of the second key includes one or more of the following: integrity information of the second key, the first electronic control The identity of the unit, or 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. A verification method, characterized by including: receiving first information from the key management entity; sending said first information to a first electronic control unit, said first information indicating a first key through information of a second key configured to authenticate said first electronic control unit At least one function key corresponding to at least one service function of the first electronic control unit; sending a first verification parameter to the first electronic control unit, the first verification parameter being used to verify the integrity of the first key; receiving first verification information from the first electronic control unit, the first verification information being used to characterize the integrity of the first key; Determine the integrity of the second key according to local verification information and the first verification information, where the local verification information includes integrity protection of the first verification parameter by the first key. information. The method of claim 16, wherein the first verification parameter comes from the key management entity; or the first verification parameter is information generated by the client. The method of claim 16 or 17, wherein the first information includes information encrypted and/or integrity protected using a derived key of the second key. The method according to any one of claims 16 to 18, characterized in that the method further includes: sending fifth information to said first electronic control unit, said fifth information being indicative of said second key through information of a fifth key, Wherein, the fifth key is used to authenticate the second key. The method of claim 19, wherein the fifth information includes information encrypted and/or integrity protected using a derived key of the fifth key. The method according to any one of claims 16 to 20, characterized in that 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 an update of the second key, Wherein, the second key update request information includes the identity authentication information of the client. A control device, characterized in that it includes a method for executing the method described in any one of claims 1 to 8, or any one of claims 9 to 15, or any one of claims 16 to 22. unit. A control device, characterized in that the control device includes at least one processor and a memory, the memory is used to store computer programs or instructions, and the at least one processor is used to call the computer program in the memory or Instructions are provided to cause the control device to execute the method described in any one of claims 1 to 8, or any one of claims 9 to 15, or any one of claims 16 to 22. A vehicle, characterized by comprising a control device for executing the method according to any one of claims 1 to 8. A key management entity, characterized in that it includes a control device for executing the method according to any one of claims 9 to 15. A key flashing tool, characterized by comprising a control device for executing the method according to any one of claims 16 to 22. A system, characterized by comprising one or more of the vehicle as claimed in claim 24, the key management entity as claimed in claim 25, or the key flashing tool as claimed in claim 26. A chip, characterized in that it includes one or more processors and an interface circuit, the interface circuit is used to provide information input and/or output to the one or more processors, and the chip is used to perform the following tasks: Any one of claims 1 to 8, or any one of claims 9 to 15, or the method of any one of claims 16 to 22. A computer-readable storage medium, characterized in that computer programs or instructions are stored in the computer-readable storage medium. When the computer programs or instructions are executed by a processor, any one of claims 1 to 8 is implemented. item, or any one of claims 9 to 15, or the method described in any one of claims 16 to 22. A computer program product, characterized in that, when the computer program product is run on one or more processors, it implements any one of claims 1 to 8, or any one of claims 9 to 15, Or, the method of any one of claims 16 to 22.