CN117597688A

CN117597688A - Key verification method and related device

Info

Publication number: CN117597688A
Application number: CN202180100210.6A
Authority: CN
Inventors: 段立; 耿峰; 李�泳
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-07-23
Filing date: 2021-07-23
Publication date: 2024-02-23
Also published as: WO2023000313A1

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

Key verification method and related device

Technical Field

The embodiment of the application relates to the field of information security, in particular to a key verification method and a related device.

Background

Information security is a precondition for automatic driving. At present, the information security of the whole vehicle can be protected through multiple functional keys in the whole vehicle system. For example, the security of the vehicle-mounted communication network may be protected by a board-side encrypted communication (security onboard communication, secOC) key (SecOC key), the authenticity of the device may be ensured by a device key (device key) for device authentication, or the like.

Generally, the normal use of the function key needs to pass the authentication of the authentication key, so how to ensure the integrity of the authentication key, and further ensure the normal use of the function key is a technical problem to be solved by those skilled in the art.

Disclosure of Invention

The embodiment of the application discloses a key verification method and a related device, which can realize the integrity verification of an authentication key, thereby ensuring the normal use of a function key and the information security of the whole vehicle.

In a first aspect, a key verification method is provided, which may be performed by an electronic control unit or a chip arranged in the electronic control unit. The method comprises the following steps: receiving, by a client, first information from a key management entity, the first information indicating a first key by information of a second key, the second key being configured to authenticate at least one function key of a first 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; generating first verification information according to the second key and the first verification parameter, wherein the first verification information is used for representing the integrity of the first key; and sending the first verification information to the client.

In an alternative design, the method may also be performed by a functional unit comprising an electronic control unit or a chip arranged in the functional unit. Illustratively, the functional component is a domain controller comprising one or more electronic control units.

According to the key verification method, since the first verification information for representing the integrity of the first key is obtained based on the second key and the first verification parameter, the integrity of the second key can be indirectly verified through the integrity of the first key, the integrity and the safety of the second key are guaranteed, and then the normal use of the functional key and the information safety of the whole vehicle are guaranteed. In addition, the first information indicates the first key through the information of the second key and is forwarded to the first electronic control unit through the key management entity by the client, so that the second key is prevented from being exposed out of the key management entity and the electronic control unit in a plaintext form, and the safety of the core asset of the whole vehicle factory is further ensured.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: and receiving fifth information from the client, wherein the fifth information is from a key management entity, and the fifth information indicates the second key through information of a fifth key, and the fifth key is used for authenticating the second key.

By adopting the scheme, the second secret key can be written into the first electronic control unit through the fifth information, so that the requirement that the second secret key is correctly written into the first electronic control unit by an authorized maintenance party of the whole vehicle production line and/or the whole vehicle factory can be met, authentication conditions are provided for writing of the subsequent function secret key, and normal use of the function secret key and information safety of the whole vehicle are ensured.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: generating ninth information according to the first information and a challenge-response mechanism, wherein the ninth information comprises information for verifying the integrity of the first key; and sending the ninth information to the client.

In the scheme, the ninth information generated based on the challenge-response mechanism can realize the integrity verification of the first secret key, so that the verification process is simplified, and the verification efficiency is improved.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: generating tenth information according to the fifth information and a challenge-response mechanism, wherein the tenth information comprises information for verifying the integrity of the second key; and sending the tenth information to the client.

In the scheme, the tenth information generated based on the challenge-response mechanism can realize the integrity verification of the second secret key, so that the verification process is simplified, and the verification efficiency is improved.

In an alternative design, the first verification information includes information obtained by integrity protecting the first verification parameter with the first key. Since the first information indicates the first key by the information of the second key, the first key can be correctly written into the first electronic control unit based on the first information only when the second key stored locally by the first electronic control unit coincides with the second key stored by the key management entity. Based on the information obtained by carrying out integrity protection on the first verification parameter by the first key, indirect verification on the integrity of the second key can be realized.

In a second aspect, a key verification method is provided, which may be performed by a key management entity or a chip configured in the key management entity. The method comprises the following steps: generating first information indicating a first key by information of a second key, the second key being configured to authenticate at least one functional key of a first electronic control unit, the at least one functional key corresponding to at least one service function of the first electronic control unit, and second verification information comprising information for integrity verification of the first key; and sending the first information and the second verification information to a client.

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

According to the key verification method, the first information indicating the first key and the second verification information which can be used for verifying the integrity of the first key are sent to the client, so that the writing of the first key and the verification of the integrity of the first key can be realized. 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 through verification of the integrity of the first key, and the safety of the second key is ensured. On the other hand, 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, so that the second key is prevented from being exposed out of the key management entity and the electronic control unit in a plaintext form, and the safety of the core asset of the whole vehicle factory is further ensured. In addition, the integrity of the second key is indirectly verified through the integrity of the first key, and the identification information of the electronic control unit is not required to be relied on, so that the whole vehicle production line is not required to collect the identification information of all target electronic control units of the second key to be updated in advance, and the burden and the management cost of the whole vehicle production line are reduced.

By means of the scheme, the key management entity can also prepare information (such as first information and second verification information) for verifying the integrity of the first key in advance and send the information to the client in advance, and based on the information, the off-line verification of the authentication key (namely the second key) of the electronic control unit can be achieved, real-time verification of the integrity of the second key can be achieved even though the key management entity does not depend on a KMS, and time expenditure is reduced.

In an alternative design, the second authentication information includes the first key, so that the client determines local authentication information according to the first key and a locally generated first authentication parameter, wherein the local authentication information can be used for integrity authentication of the first key and/or the second key; or the second verification information comprises a second verification parameter and information obtained by carrying out integrity protection on the second verification parameter through the first key.

With reference to the second aspect, in certain implementations of the second aspect, the method further includes: and sending fifth information to the client, wherein the fifth information indicates the second key through information of a fifth key, and the fifth key is used for authenticating the second key.

Through the scheme, the second secret key can be written in, so that the requirement that the second secret key is correctly written in the first electronic control unit by an authorized maintenance party of the whole vehicle production line and/or the whole vehicle factory is met, authentication conditions are further provided for writing in the subsequent function secret key, and normal use of the function secret key and information safety of the whole vehicle are ensured. In addition, the scheme can be adapted to various scenes to be written with the second secret key, and the secret key management process of a secret key management entity or a whole vehicle factory can be simplified through a unified solution adapted to the various scenes, so that the secret key writing process is simplified.

With reference to the second aspect, in certain implementations of the second aspect, the method further includes: and receiving second key update request information from the client, wherein the second key update request information is used for requesting to update the second key or for requesting to verify the integrity of the second key locally stored by the first electronic control unit.

According to the scheme, the second key updating request information is used for generating information suitable for second key updating or second key integrity verification, so that the second key integrity verification is realized, and normal use of the function keys and information security of the whole vehicle are ensured.

With reference to the second aspect, in certain implementations of the second aspect, the method further includes: and receiving an updating result of the second key from the client.

Through the scheme, the updating condition of the second key can be obtained, and whether the function key can be written in or not is further judged, so that the normal use of the function key and the information safety of the whole vehicle are ensured.

In a third aspect, a key verification method is provided, which may be performed by a client or a chip configured in the client. The method comprises the following steps: receiving first information from a key management entity; transmitting the first information to a first electronic control unit, the first information indicating a first key by information of a 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 at least one service function of the first electronic control unit; transmitting a first verification parameter to the first electronic control unit, wherein the first verification parameter is used for verifying 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; and determining the integrity of the second key according to the local verification information and the first verification information, wherein the local verification information comprises information obtained by carrying out integrity protection on the first verification parameter through the first key.

In an alternative design, the client includes an OEM key swiping device, or includes a dealer diagnostic.

Through the scheme, the client side is used as an intermediate medium between the key management entity and the first electronic control unit, first information of the key management entity can be forwarded to the first electronic control unit, writing of the first key on the first electronic control unit side is further achieved, and verification of the integrity of the second key is indirectly achieved through verification of the integrity of the first key according to the local verification information. The first information indicates the first secret key through the information of the second secret key, so that the second secret key is ensured not to be exposed outside the secret key management entity and the electronic control unit in a plaintext form, and the safety of the core asset of the whole vehicle factory is further ensured. In addition, the client side is used as an intermediate medium to realize the integrity verification of the second secret key, the realization is simple, the whole vehicle production line assembly, the after-sales maintenance scene and the secret key refreshing scene of the part developer are adapted, and the management cost of a secret key management entity or a whole vehicle factory can be further reduced.

In an alternative design, the first verification parameter is from the key management entity, e.g. corresponds to a second verification parameter from the key management entity, i.e. the client forwards the second verification parameter from the key management entity to the first electronic control unit for verifying the integrity of the first key; alternatively, the first verification parameter includes information generated by the client.

In an alternative design, the local authentication information is from the key management entity, e.g. corresponds to information from the key management entity resulting from integrity protection of the second authentication parameter by the first key; or the local authentication information is information determined by the client.

With reference to the third aspect, in some implementations of the third aspect, determining the integrity of the second key according to local authentication information and the first authentication information includes: if the local verification information is matched with the first verification information, determining that the second key is complete; or if the local verification information does not match the first verification information, determining that the second key is incomplete.

Through the scheme, the client can judge the integrity of the second key, and further judge whether the function key can be written in, so that the normal use of the function key is ensured.

With reference to the third aspect, in certain implementations of the third aspect, the method further includes: and sending fifth information to the first electronic control unit, wherein the fifth information indicates the second key through information of a fifth key, and the fifth key is used for authenticating the second key.

Through the scheme, the requirement that the second secret key is correctly written into the first electronic control unit by an authorized maintenance party of the whole vehicle production line and/or the whole vehicle factory can be met, and then authentication conditions are provided for writing of the subsequent function secret key, so that normal use of the function secret key and information safety of the whole vehicle are ensured.

With reference to the third aspect, in certain implementations of the third aspect, the method further includes: transmitting ninth information from the first electronic control unit to the key management entity, the ninth information including information for verifying the integrity of the first key; the client does not parse the ninth information.

By the scheme, the key management entity can acquire the integrity verification result of the first key, the client does not analyze the ninth information, the safety of the first key can be ensured, and the operation of the client is simplified.

With reference to the third aspect, in certain implementations of the third aspect, the method further includes: transmitting 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.

By the scheme, the key management entity can acquire the integrity verification result of the second key, the client does not analyze the tenth information, the safety of the first key can be ensured, and the operation of the client is simplified.

With reference to the third aspect, in certain implementations of the third aspect, the method further includes: and sending second key updating request information to the key management entity, wherein the second key updating request information is used for requesting updating of the second key or verifying the integrity of the second key locally stored in the first electronic control unit.

By the scheme, the key management entity can be assisted to generate information suitable for second key update or second key integrity verification through the second key update request information, so that the second key integrity verification is realized, and normal use of the function keys and information security of the whole vehicle are ensured.

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

By the scheme, the key management entity can be assisted to acquire the update condition of the second key, so that whether the function key can be written in or not is judged, and normal use of the function key and information safety of the whole vehicle are ensured.

With reference to the second aspect and the third aspect, in certain implementations of the second aspect and the third aspect, the second key update request information includes one or more of the following information: the identity authentication information of the client, the number of the electronic control units to be updated with the second secret key, the identification code of the whole vehicle to which the electronic control units belong, the version number of the authentication secret key locally stored by the electronic control units and the version number of the electronic control units.

In an alternative design, the identity authentication information of the client is used to characterize that the client has the right to obtain key writing information from the key management entity, wherein the key writing information comprises one or more of the following information: the first information, the fifth information, and the second authentication information. The second key updating request information comprises the identity authentication information of the client, so that the key writing information can be ensured to be only provided for the client authorized by the key management entity, and the security of the key is further ensured.

In addition, the second key update request information includes one or more of the following information: the number of the electronic control units to be updated of the second secret key, the identification code of the whole vehicle to which the electronic control units belong, the version number of the authentication secret key locally stored by the electronic control units and the version number of the electronic control units are also convenient for a secret key management entity to determine the second secret key to be written in, batch writing of the second secret key and/or batch integrity verification of the second secret key are realized, and the cost of secret key management is reduced.

With reference to the second aspect and the third aspect, in certain implementations of the second aspect and the third aspect, the update result of the second key includes one or more of: the second key comprises integrity information of the second key, and identity identification of the first electronic control unit, wherein the identity identification of the first electronic control unit is used for uniquely identifying the first electronic control unit.

According to the scheme, the key management entity can determine whether the second key is written into the first electronic control unit or not and/or determine whether the authentication key locally stored by the first electronic control unit is the second key or not based on the updating result of the second key, so that normal use of the function key and information security of the whole vehicle are ensured. In addition, by collecting the identity of the first electronic control unit, the key management entity is further facilitated to manage the electronic control unit written with the second key.

With reference to the first aspect, the second aspect, and the third aspect, in certain implementations of the first aspect, the second aspect, and the third aspect, the first information includes information obtained by encryption and/or integrity protection by a derivative key of the second key.

By this solution it is achieved that the first key is written to the first electronic control unit with the first key secure, and that the second key is not exposed in the form of plaintext outside the key management entity and the electronic control unit.

With reference to the first aspect, the second aspect, and the third aspect, in certain implementations of the first aspect, the second aspect, and the third aspect, the first information includes: and the third key and the fourth key are derivative keys of the second key, wherein the second information is obtained by cascading at least the identity information of the first electronic control unit, the index of the first key and the index of the second key, the third information is obtained by encrypting the first key through a third key, and the fourth information is obtained by integrity protecting at least the information cascading the second information and the third information through a fourth key.

By means of the scheme, the first secret key can be written into the first electronic control unit under the condition that the first secret key is safe, the second secret key is ensured not to be exposed out of the secret key management entity and the electronic control unit in a plaintext mode, and the implementation is simple.

With reference to the first aspect, the second aspect, and the third aspect, in certain implementations of the first aspect, the second aspect, and the third aspect, the fifth information includes information obtained by encryption and/or integrity protection by a derivative of the fifth key.

By means of the scheme, the second secret key can be written into the first electronic control unit under the condition that the second secret key is ensured to be safe.

With reference to the first aspect, the second aspect, and the third aspect, in certain implementations of the first aspect, the second aspect, and the third aspect, the fifth information includes: sixth information obtained by concatenating at least 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 by the sixth key, and eighth information obtained by integrity-protecting at least the information concatenated by the sixth information and the seventh information by the seventh key, wherein the sixth key and the seventh key are derivative keys of the fifth key.

By means of the scheme, the second secret key can be written into the first electronic control unit under the condition that the second secret key is ensured to be safe, and the implementation is simple.

With reference to the first aspect, the second aspect, and the third aspect, in certain implementation manners of the first aspect, the identity information of the first electronic control unit includes an identity of the first electronic control unit or a group identity of the first electronic control unit, where 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 is used for identifying the equipment group to which the first electronic control unit belongs.

In an alternative design, the group identifier of the first electronic control unit includes at least one wild card.

By the scheme, based on the group identification of the first electronic control unit, batch writing of the first keys and/or the second keys of the plurality of electronic control units by the key management entity and batch verification of the integrity of the second keys can be realized, the flow is simplified, and the cost is saved; based on the identity of the first electronic control unit, writing of the point-to-point first key and/or the second key and verification of the integrity of the second key can be achieved.

In a fourth aspect, a control device is provided, the control device comprising means or modules for performing the method in any of the possible implementations of the first aspect described above, or means or modules for performing the method in any of the possible implementations of the second aspect described above, or means or modules for performing the method in any of the possible implementations of the third aspect described above.

In a fifth aspect, a control device is provided that includes a processor and a memory. The memory is configured to store a computer program or instructions, and the processor is configured to invoke the computer program or instructions in the memory to cause the control device to perform the method in any of the possible implementations of the first aspect, or to perform the method in any of the possible implementations of the second aspect, or to perform the method in any of the possible implementations of the third aspect. In an alternative design, the control device further comprises a communication interface coupled with the processor, the communication interface for inputting and/or outputting information, for example comprising one or more of the following information: the first information, the fifth information, the first verification parameter, the first verification information, the second key update request information, and the second key update result.

In an alternative design, the processor is one or more and the memory is one or more.

In an alternative design, the memory may be integrated with the processor or the memory may be separate from the processor.

With reference to the fourth and fifth aspects, in an alternative design, the control device for performing the method in any one of the possible implementations of the first aspect may be an electronic control unit or a domain controller comprising one or more electronic control units.

In a sixth aspect, an electronic component is provided, comprising control means implementing the method in any of the possible implementations of the first aspect described above. Illustratively, the electronic component includes an ECU.

In a seventh aspect, a vehicle is provided, which comprises a control device implementing the method in any of the possible implementations of the first aspect, or which comprises the electronic component provided in the sixth aspect.

In an eighth aspect, a key management entity is provided, which can implement the method in any one of the possible implementations of the second aspect. In an alternative design, the key management entity may be a key management server.

In a ninth aspect, a key swiping tool is provided, which can implement the method in any one of the possible implementations of the third aspect. In an alternative design, the key swiping tool may be an OEM key swiping tool or a dealer diagnostic instrument.

In a tenth aspect, a system is provided, the system comprising 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 one or more of the key swiping tools provided in the ninth aspect.

An eleventh aspect provides a system comprising control means for performing the method of any of the possible implementations of the first aspect, control means for performing the method of any of the possible implementations of the second aspect or one or more of control means for performing the method of any of the possible implementations of the third aspect.

In a twelfth aspect, a chip is provided, the chip comprising one or more processors and interface circuitry for providing information input and/or output to the one or more processors, the chip being for performing the method of any one of the possible implementations of the first aspect described above, or for performing the method of any one of the possible implementations of the second aspect described above, or for performing the method of any one of the possible implementations of the third aspect described above.

In a thirteenth aspect, a computer readable storage medium is provided, in which a computer program or instructions is stored which, when executed by a processor, cause the processor to perform the method of any one of the possible implementations of the first aspect described above, or to perform the method of any one of the possible implementations of the second aspect described above, or to perform the method of any one of the possible implementations of the third aspect described above.

In a fourteenth aspect, there is provided a computer program product which, when run on one or more processors, causes the one or more processors to perform the method of any one of the possible implementations of the first aspect described above, or to perform the method of any one of the possible implementations of the second aspect described above, or to perform the method of any one of the possible implementations of the third aspect described above.

Drawings

The drawings used in the embodiments of the present application are described below.

Fig. 1 is a network architecture of one possible key verification method provided in an embodiment of the present application;

FIG. 2 is a schematic flow chart of one possible key verification method provided by an embodiment of the present application;

FIG. 3 is a schematic flow chart of one possible key writing method provided in an embodiment of the present application;

FIG. 4 is a schematic flow chart of one possible method for implementing a key update request and key update results provided by embodiments of the present application;

FIG. 5 is a schematic flow chart diagram of one possible method for implementing key verification information provided by embodiments of the present application;

FIG. 6 is a schematic flow chart diagram of yet another possible method for implementing key verification information provided by embodiments of the present application;

FIG. 7 is a schematic diagram of one possible control device provided in an embodiment of the present application;

FIG. 8 is a schematic diagram of another possible control device provided by an embodiment of the present application;

fig. 9 is a schematic diagram of one possible chip structure provided in an embodiment of the present application.

Detailed Description

Embodiments of the present application are described below with reference to the accompanying drawings in the embodiments of the present application. In this application, the terms "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

The "at least one item" referred to in the embodiments herein means one item(s) or a plurality of items(s), and the "plurality of items" means two items(s) or more than two items(s). "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a. b, c, (a and b), (a and c), (b and c), or (a and b and c), wherein a, b, c may be single or plural. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: three cases of a alone, a and B together, and B alone, wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

And, unless otherwise indicated, the use of ordinal numbers such as "first," "second," etc., in the embodiments herein are used for distinguishing between multiple objects and not for defining a sequence, timing, priority, or importance of the multiple objects. For example, the first information and the second information are only for distinguishing different information, and are not indicative of the difference in content, priority, transmission order, importance, or the like of the two information.

First, technical terms involved in the embodiments of the present application will be briefly described.

1. Electronic control unit (Electronic Control Unit, ECU)

The electronic control unit ECU may also be referred to as a vehicle-mounted controller, and may be used to control various functions in the use of the entire vehicle. The ECU may include, for example, but is not limited to: an ECU having an engine control function, an ECU having a grip control function, an ECU having a brake control function.

The ECU may also be understood as an electronic unit having an integrity protection function and an encryption function and comprising a secure memory, for example. The secure memory may be implemented based on nonvolatile memory (NvM). Secure memory has a strict access control mechanism that can control the reading and use of key material. The secure memory is illustratively a secure memory area in an automotive open system architecture (automotive open system architecture, AUTOSAR) secure hardware extension (secure hardware extension, SHE).

It should be noted that, in some technical scenarios, the names of electronic units having similar functions for controlling the use of the whole vehicle may not be called ECU, and the names of electronic units having integrity protection functions and encryption functions and including secure memory may not be called ECU, but for convenience of description, in the embodiment of the present application, electronic units having functions for controlling the use of the whole vehicle are collectively called ECU, and electronic units having integrity protection functions and encryption functions and including secure memory are also collectively called ECU.

2. Authentication key

The authentication key is used for authenticating the function key, and the electronic control unit ECU can only realize the writing and/or the integrity verification of the function key if the electronic control unit ECU has the correct authentication key. Based on this, the authentication key can also be understood as an authentication key of the function key or a rights key of the function key. Illustratively, the ECU has the correct authentication key, it being understood that the authentication key locally held by the ECU is the same as the authentication key locally held by the KMS.

In addition, the authentication key may be used for authentication of a function key, and may also be used for authentication of a hardware function key of the ECU, which may also be used for authentication of the function key. Illustratively, the authentication key may be used to authenticate a key (as an example of a hardware function key) corresponding to a subsequent version of the authentication key. Taking the authentication key as an ECU master key (MEK) as an example, the electronic control unit ECU can only implement writing and/or integrity verification of a new version of MEK if it has a previous version of the correct MEK. Specifically, if the latest version of MEK held by the current key management server is 2.0 (noted as MEK2.0 for convenience of description), if the MEK2.0 is enabled to be successfully written to the target ECU, the target ECU is required to possess the correct MEK previous version such as MEK1.0. Based on this, the authentication key may also be understood as an authentication key of the ECU hardware function key or a rights key of the ECU hardware function.

The authentication key may correspond to all vehicles included in one vehicle type, or may correspond to one vehicle, or may also correspond to one functional unit in the vehicle, or corresponds to one ECU in the vehicle, and accordingly, all vehicles included in one vehicle type have the same authentication key, vehicles of different vehicle types have different authentication keys, or one vehicle has one authentication key, different vehicles have different authentication keys, or one functional unit in the vehicle has one authentication key, other functional units in the vehicle have other authentication keys, or one ECU in the vehicle has one authentication key, and different ECUs have different authentication keys. The functional components herein may include functional components composed of a plurality of ECUs, for example, functional components for cabin control composed of a plurality of ECUs.

In the present embodiment, the ECU master key MEK may also be referred to as an ECU hardware authority key.

3. Function key

The function key can also be called a service key and can be used for encrypting ECU keys of various functions in the whole vehicle, so that the safety of a whole vehicle computer system is ensured. The function keys may include, for example, but are not limited to: pre-shared key (PSK), master Key (MK) for business applications, session Key (SK). The PSK may include a key (SecOC key) for securing the board-side encrypted communication (security onboard communication, secOC) and a device key (device key) for device authentication, among others.

In the embodiment of the application, the function key can be distributed based on a whole vehicle and a service. For example, one or more ECUs for the same service may share the same function key for one whole vehicle. And the ECUs of the same service may be different for different whole vehicles. For example, if multiple ECUs in the same whole vehicle are used for on-board encrypted communication, the multiple ECUs may share the same function key, and the multiple ECUs may each perform encrypted communication with each other based on the function key. In particular, between the ECUs in communication with each other, messages can be encrypted and decrypted based on the same functional key to achieve encryption and integrity protection of the messages. For another example, if a plurality of ECUs in the same whole vehicle are used for device authentication, the plurality of ECUs may share the same function key. Any one of the plurality of ECUs authenticates the other ECUs of the service based on the function key.

It will be appreciated that the function key for board side encrypted communications and the function key for device authentication are keys for different services and thus different keys. In the embodiment of the application, the board-end encryption communication and the equipment authentication can be understood as different services.

Furthermore, the function key may also be assigned based on a smaller granularity. The function key may be assigned based on a whole vehicle, a business, and a pair of ECUs, for example. For example, if a plurality of ECUs are used for the same service, each two ECUs of the plurality of ECUs may constitute a pair of ECUs. Each pair of ECUs may share a function key. Specifically, the plurality of ECUs include, for example, ECU-1, ECU-2, and ECU-3. The ECU-1 and the ECU-2 may share the same function key, such as the function key 1; another function key, such as function key 2, may be shared between ECU-2 and ECU-3; the function key may be shared between ECU-1 and ECU-3, such as denoted as function key 3.

4. Message authentication code (message authentication code, MAC)

Message Authentication Codes (MACs) are a verification mechanism used by both communicating entities in cryptography and are a tool for guaranteeing message integrity. Illustratively, before sending the message, the sender first calculates the MAC using an integrity protection algorithm (or also including a key) negotiated by both parties. The MAC and data are then sent together. After receiving the message, the receiver calculates the MAC using the same integrity protection algorithm (or also including the key) as the sender and compares whether the calculated MAC is consistent with the received MAC. If the two are consistent, the message passes the integrity verification.

5. Integrity protection algorithm

The MAC may be generated by an integrity protection algorithm, which may also be referred to as a MAC algorithm or a full protection algorithm. Generally, the integrity protection algorithm comprises at least the following three algorithms: (1) A key generation algorithm for generating a tag computation key and a verification key, the tag computation key may be the same as the verification key (e.g., a key for a message authentication code) or may be different (e.g., a key for a digital signature (digital signature)); (2) The label computing algorithm takes a label computing key and information to be protected as input and generates a protection label corresponding to the information to be protected; (3) The verification algorithm takes the verification key, the tag calculation key and the information to be protected as input, and outputs a logic true value if and only if the verification passes. Furthermore, the set of integrity protection algorithms needs to meet at least the following two properties. (1) Correctness, i.e. the protection tag generated using the tag calculation key and the tag calculation algorithm must be verified as true by the verification key and the verification algorithm. (2) Tamper resistance (tamper), i.e. the fact that an attacker cannot tamper with non-negligible probability as the information to be protected without knowing the tag calculation key.

For example, the integrity protection algorithm implemented based on a hash algorithm is referred to as a hash-based message authentication code (hash-based message authentication code, HMAC) algorithm, where the hash algorithm may be one of MD5, SHA-1, SHA-256, or other implementations, without specific limitation. These different HMAC implementations may be generally labeled: HMAC-MD5, HMAC-SHA1, HMAC-SHA256. For another example, the MAC algorithm implemented based on the cryptographic algorithm may be referred to as a Cipher-based message authentication code (Cipher-based Message Authentication Code, CMAC) algorithm, where the block encryption algorithm may be an advanced encryption standard (Advanced Encryption Standard, AES), and since the operation mode of AES block encryption includes, but is not limited to, ECB, CBC, CFB, OFB, the integrity protection algorithm implemented based on the block encryption algorithm of different operation modes may be respectively referred to as: ECB-MAC algorithm, CBC-MAC algorithm, CFB-MAC algorithm, OFB-MAC algorithm. The integrity protection algorithm may also include Galois message authentication code (Galois message authentication code mode, GMAC), a cryptographic algorithm for ancestor (e.g., ZUC128, ZUC256, etc.).

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

6. Encryption algorithm

The encryption algorithm includes a symmetric encryption algorithm and an asymmetric encryption algorithm. Generally, the encryption key of a symmetric encryption algorithm is the same as the decryption key, and the encryption key of an asymmetric encryption algorithm is different from the decryption key. Common symmetric encryption algorithms include, but are not limited to: data encryption standard (data encryption standard, DES), triple data encryption algorithm (triple data encryption algorithm,3 DES), AES; common asymmetric algorithms include, but are not limited to: RSA encryption algorithm.

In some specific scenarios, the authentication encryption algorithm may encrypt data and generate a message authentication code for a given original document, so that the authentication encryption algorithm may be used as an encryption algorithm or a full-protection algorithm. For example, an AES algorithm (AES-Galois/Counter Mode, AES-GCM) based on GMAC and a Counter encryption Mode, and an AES algorithm (AES-CMAC/Counter Mode, AES-CCM) based on CMAC and a Counter encryption Mode may each perform authentication encryption on the message, and a MAC can be generated during the authentication encryption to protect the integrity of the message.

Furthermore, there are also a class of hash algorithms that do not require a key, such as for the generation of part of the information in the information produced on the basis of encryption algorithms or on the basis of integrity algorithms. Hashing algorithms include, but are not limited to: secure hash algorithm (secure hash algorithm, SHA-1), message Digest (MD) algorithm (e.g., MD2, MD4, or MD 5).

7. Key derivation algorithm

Key derivation is the process of deriving one or more keys from a key, and the algorithm used to derive the key is referred to as the key derivation algorithm (key derivation function, KDF), also known as the key derivation algorithm. For example, a new Key derived from the Key can be expressed as: dk=kdf (Key). Common key derivation algorithms include, but are not limited to: cipher-based key derivation function (password-based key derivation function, PBKDF), schryptopine (scrypt) algorithm. The PBKDF algorithm comprises a first generation PBKDF1 and a second generation PBKDF2.

It should be noted that, in the embodiments of the present application, for convenience in describing the KDF used in each key derivation process, a description will be made using "first KDF", "second KDF", and "third KDF", where the "first KDF", "second KDF", and "third KDF" may be different KDFs or may be the same KDF.

8. Challenge-response mechanism

The challenge-response mechanism is one mode in authentication protocols. One authentication protocol implementing a challenge-response mechanism typically involves 2 parties. A challenger (challenge) is typically the party that needs to verify the identity of the other party, and a responder (responder) is the party that needs to authenticate the identity of the other party.

The challenge-response mechanism criteria are as follows: the challenger transmits a challenge (challenge) to the responder, and the responder determines a corresponding response (response) to transmit to the challenger based on the locally stored authentication information (or secret authentication information) and the challenge. The challenger combines the challenge with the authentication information held by the challenger to authenticate whether the responder has passed the challenge and/or to determine whether the responder should be authenticated. Illustratively, the challenger may challenge information containing a fresh random string or information containing a pseudo-random string.

Next, a system architecture and a service scenario of the embodiment of the present application will be described. It should be noted that, the system architecture and the service scenario described in the present application are for more clearly describing the technical solution of the present application, and do not constitute a limitation on the technical solution provided in the present application, and those skilled in the art can know that, with the evolution of the system architecture and the appearance of the new service scenario, the technical solution provided in the present application is also applicable to similar technical problems.

Referring to fig. 1, fig. 1 is a network architecture of a possible key verification method according to an embodiment of the present application. As shown in fig. 1, the network architecture 100 may include a key management server, OEM key swiping devices (also referred to as OEM tools), a whole vehicle, and an ECU. The KMS and the OEM key writing device, and the OEM key writing device and the ECU may communicate through a local connection (for example, a local area network, and hardware is directly connected (for example, the key writing device is directly connected with the ECU)), and may also communicate through a secure connection protocol (for example, a transport layer security protocol (transport layer security specification, TLS) or a virtual private network (virtual private network, VPN)) to ensure communication security.

It will be appreciated that for whole vehicle production, the OEM may refer specifically to the manufacturer or foundry of the whole vehicle.

It should be understood that fig. 1 illustrates the key writing/verification procedure for use in the whole vehicle production line for ease of understanding only, and this should not constitute any limitation to the present application. The key writing/verification method provided by the application can also be applied to after-sale services, such as a key updating process for the after-sale services. The OEM key swiping device of fig. 1 may be replaced with a dealer diagnostic instrument (also referred to as a dealer diagnostic tool) when applied to after-market services. The KMS dealer diagnostic instrument can also communicate with the ECU via a local or secure connection.

It will be appreciated that the OEM server and the dealer server may be similar in hardware structure, as the OEM server and the dealer server may function similarly, with different application scenarios. The OEM key swiping device functions similarly to the dealer diagnostic device and the application scenario is different, so the hardware structure of the OEM key swiping device and the dealer diagnostic device may also be similar.

In an alternative design, the KMS further includes a KMS front end server and a KMS back end server. The KMS front-end server is mainly responsible for communication with the outside, and can be understood as an interface between the KMS back-end server and the outside. The KMS background server is mainly responsible for key generation, key lookup, etc. The KMS front-end server and the KMS background server may be two physically independent devices, or may be integrated in the same physical device. The embodiments of the present application are not limited in this regard.

It should also be appreciated that two vehicles are shown in FIG. 1, along with one or more ECUs disposed on each vehicle. The number of vehicles and the number of ECUs deployed in the network architecture are not limited in the present application.

It should be noted that, for clarity of description, the following description in the embodiments of the present application describes MEK as an example of the authentication key, and it is understood that MEK may be replaced by other authentication keys.

MEK is prohibited from being exposed to outside third parties (e.g., component developers, OEM-authorized vendors, after-market 4S stores) in plain text, and also not allowed to be exposed outside the KMS, because of its key properties (e.g., MEK is used as an authentication key or rights key for a functional key included in the whole vehicle) which may be considered a core asset for original equipment manufacturers (original equipment manufacturer, OEMs). Based on this, existing whole car factories write MEK into the electronic control unit by the environment of safety monitoring. In the absence of security monitoring (e.g., when remote key swiping is implemented), the security of MEK is not guaranteed, with the risk of tampering.

In view of this, embodiments of the present application provide a method of key verification, in which a client receives first information from a key management entity, the first information indicating a first key through information of a second key 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 service function of the first electronic control unit, and transmits the first information to the first electronic control unit; the client also sends a first verification parameter to the first electronic control unit, the first verification parameter being used to verify the integrity of the first key. The first electronic control unit receives first information and first verification parameters from the client, and generates first verification information according to a second key and the first verification parameters, wherein the first verification information is used for representing the integrity of the first key; the first electronic control unit sends the first verification information to the client. The client receives the first verification information and determines the integrity of the second key according to the first verification information and the local verification information. In the scheme, because the first verification information for representing the integrity of the first key is obtained based on the second key and the first verification parameter, the integrity of the second key can be indirectly verified through the integrity of the first key, the integrity and the safety of the second key are ensured, the second key is prevented from being tampered, and then the normal use of the functional key and the information safety of the whole vehicle are ensured. In addition, the first information indicates the first key through the information of the second key and is forwarded to the first electronic control unit through the key management entity by the client, so that the second key is prevented from being exposed out of the key management entity and the electronic control unit in a plaintext form, and the safety of the core asset of the whole vehicle factory is further ensured.

The key verification method provided in the embodiment of the present application is described below with reference to specific embodiments. It should be noted that, in the 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. Illustratively, verifying the integrity of the key may include verifying whether the key is written in its entirety to the ECU, or whether it is written correctly to the ECU. Specifically, for example, if the storage area of the ECU includes the key that has not been tampered with, it may indicate that the key is correctly written or completely written to the ECU. Illustratively, the keys herein include a function key (e.g., a SecOC key, device key) and/or an authentication key (e.g., MEK).

Referring to fig. 2, fig. 2 is a flow chart of a possible key verification method according to an embodiment of the present application. Further, the method may be implemented based on the architecture of fig. 1. The method may include:

s201, the key management entity generates first information and second authentication information.

In the embodiment of the present application, the key management entity is configured to manage the key, for example, the key management entity may implement one or more of the following functions: generating a key, authorizing use of the key, and deregistering management of the key. It should be noted that the keys herein include various keys used in the vehicle, such as a function key and an authentication key, and other forms of keys such as a temporary key used in the key swiping process.

Illustratively, the key management entity may be a KMS, further, the KMS is managed by an OEM, so as to ensure security of various keys used in the vehicle; alternatively, the key management entity may be an OEM server including a KMS, or the key management entity may be a whole vehicle factory, or the key management entity may be an OEM server directly. The KMS may refer to the foregoing description, and will not be described in detail herein. Furthermore, for clarity of description, embodiments of the present application are described with KMS as one example of a key management entity, it being understood that KMS may be replaced with other forms of key management entities.

In an embodiment of the application, the first information indicates the first key by means of information of a second key, wherein the second key is configured for authenticating at least one function key of the first ECU, the at least one function key corresponding 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, embodiments of the present application are described in that the first information indicates the first key through the information of the second key, and it should be understood that the first information is associated with the second key, or the first information is associated with the information of the second key, and the implementation manner of the first key may be indicated by the information of the second key corresponding to the first information.

For clarity of description, embodiments of the present application are described with ECU-1 as one example of a first ECU, it being understood that ECU-1 may be replaced with other representations of the first ECU.

Illustratively, the second key is an authentication key, such as MEK. As previously described, MEK may be used to authenticate hardware function keys of ECU-1 in addition to at least one function key of ECU-1. The hardware function key may be plural or one, and is not particularly limited. As one possible implementation, the MEK may be obtained from the KMS.

It should be noted that the at least one function key of the ECU-1 may include one implementation as follows:

mode 1: a function key of the ECU-1. Further, the function key may correspond to one or more service functions of the ECU-1. For example, the function key may be used for board-side encrypted communications and/or device authentication.

Mode 2: a plurality of function keys of the ECU-2. Further, for example, the ECU-1 may be used for a plurality of services, so the ECU may have a plurality of function keys that may correspond to a plurality of service functions of the ECU-1; for example, multiple function keys of the ECU-1 may be used for the same service, for example, when the ECU-1 and different ECUs (for example, ECU-2 and ECU-3) perform in-vehicle communication, different function keys (for example, a board-end encryption communication key) may be used to implement board-end encryption communication, that is, the ECU-1 and the ECU-2 may share the same function key, for example, denoted as a function key 1; another function key, such as function key 2, may be shared between ECU-2 and ECU-3.

In addition, as previously described, the MEK may also be configured to authenticate at least one function key of a plurality of ECUs, the at least one function key corresponding to at least one business function of the plurality of ECUs. Illustratively, the at least one service function of the plurality of ECUs may include one implementation as follows:

mode a: one function key of a plurality of ECUs. Further, the function key may correspond to one or more service functions of the plurality of ECUs. For example, if multiple ECUs are all used for the peer-to-peer encrypted communication, the multiple ECUs may use the same function key (e.g., the peer-to-peer encrypted communication key) to implement the peer-to-peer encrypted communication, or the function key may be used for device authentication in addition to the corresponding peer-to-peer encrypted communication.

Mode B: a plurality of function keys of the plurality of ECUs. Further, the plurality of function keys may correspond to one service function or a plurality of service functions of the plurality of ECUs. For example, the multiple ECUs can be used for encryption communication at the board end, but different ECUs can realize encryption communication at the board end through different function keys; for another example, some of the plurality of ECUs may correspond to one service, and some of the plurality of ECUs may correspond to another service, and in this case, the plurality of function keys may correspond to different services, respectively.

In this embodiment of the present application, the function key corresponds to a service function, which may be understood that the function key is used in a process of implementing the service function.

The first key may be a function key, or a temporary key, for example. The temporary key may comprise a derivative of the MEK or the functional key, among other things, for encryption and/or integrity protection of the resulting intermediate key. In the embodiment of the application, in order to implement the integrity verification of MEK, the first key may be used as an intermediate key. In one possible implementation, the first key may be obtained from the KMS. The first key may be a key that is pre-generated by the KMS and stored in a locally maintained database, or may be a randomly generated key, for example. This is not limiting in the embodiments of the present application. For simplicity of description, the following description in the embodiments of the present application describes vrf_k as one representation of the first key, and it is understood that the first key may have other representations.

In one possible implementation, the first information includes information obtained by encryption and/or integrity protection by the MEK. Based on this, the KMS may implement that the first information indicates the first key through information of the second key. For example, the first information may include information generated based on the authentication key MEK and the key vrk_k to be written by 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 obtained by encryption and/or integrity protection of a derivative key of the MEK. Based on this, the KMS may implement that the first information indicates the first key through information of the second key. The first information may be information obtained by encryption and/or integrity protection calculations using one or more derivative keys of the MEK, and further, in an alternative design, may be used to write vrk_k. Since the first information includes information obtained by encryption and/or integrity protection of the derived key of the MEK, it is ensured that the MEK is not exposed outside the KMS in plain text form, and the security of the MEK is ensured. In the embodiments of the present application, the information obtained by integrity protection through the derivative key of the MEK may include information obtained by combining the derivative key of the MEK with one algorithm or multiple algorithms in the integrity protection algorithm, which is not specifically limited in the embodiments of the present application. For example, information obtained by combining a derivative key of MEK with a tag calculation algorithm in the integrity protection algorithm may be understood as information obtained by integrity protection of the derivative key of MEK. It should be appreciated that one derivative key may be used for encryption and integrity protection calculations, or may be used only for encryption or integrity protection calculations. Based on this, when one derivative key is used only for encryption or integrity protection computation, the first information needs to implement encryption and integrity protection computation through multiple derivative keys of MEK.

Illustratively, the KMS may derive two derivative keys K1', K2' corresponding to MEK based on the MEK, the parameters key_update_enc_c, and key_update_mac_c through a KDF, the two derivative keys being used for encryption and integrity protection, respectively. The specific values of the parameters key_update_enc_c and key_update_macc may be predefined, for example, in the relevant technical specifications. The technical specification may be, for example, a secure hardware extension SHE technical specification issued by the AUTOSAR organization. K1', K2' can be realized, for example, by the following formula (1) and formula (2):

k1' =first KDF (MEK, key_update_enc_c) formula (1)

K2' =first KDF (MEK, key_update_mac_c) formula (2)

Thereafter, the KMS may encrypt the vrk_k based on the above K1 'by an encryption algorithm to obtain third information included in the first information, for example, the KMS may encrypt the vrk_k by using the AES algorithm using the K1'; the KMS may also perform integrity protection on vrf_k based on K2' using a MAC algorithm to obtain fourth information included in the first information. It should be appreciated that the encryption algorithm and the integrity protection algorithm include, but are not limited to, the specific implementations described above, and embodiments of the present application are not specifically limited thereto.

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

Wherein, 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 appreciated that different keys need to be stored separately in the ECU to ensure that the different keys do not overlap each other, and thus ensure normal use of the different keys. Based on this, in an alternative design, the index of VRF_K may also be understood as indicating the address information that the VRF_K maintains within ECU-1, and similarly, the index of MEK may be used to indicate the address information that MEK maintains within ECU-1. The address information of the different KEYs stored in the ECU may be predefined in a related technical specification, for example, in the SHE technical specification, it is specified that the address information corresponding to MEK is 0x1, the address information corresponding to KEY1 to KEY10 is 0x4 to 0xd, the address information corresponding to ram_key is 0xe, where KEY1 to KEY10 may correspond to a function KEY, and ram_key may correspond to a temporary KEY.

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

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

In the embodiment of the application, the group identifier of the ECU-1 is used to identify the device group to which the ECU-1 belongs, and all the ECUs included in the device group have a common attribute. Illustratively, the group identifier of the ECU-1 may be used to identify the line lot to which the ECU-1 corresponds, and correspondingly, all of the ECUs included in the equipment group to which the ECU-1 belongs belong to the same line lot; and/or the group identifier of the ECU-1 may be used to identify the device type to which the ECU-1 corresponds, and correspondingly, all the ECUs included in the device group to which the ECU-1 belongs correspond to the same device type; and/or, the group identifier of the ECU-1 may be used to identify the service function corresponding to the ECU-1, and correspondingly, all the ECUs included in the device group to which the ECU-1 belongs correspond to the same service function. For example, the device identification code of the ECU is composed of W digits, wherein the W1 digits represent one or more of the following corresponding to the ECU: line lot, equipment type, business function, W2 number of bits indicates that the ECU is different from information specific to other ECUs in the equipment set, w=w1+w2. In this case, at least one wild card may be included in the group identification of the ECU-1 for indicating the unique information corresponding to each of all the ECUs included in the equipment group, and the wild card may be implemented by special characters such as #,%, # and the like, or by special numerical combinations such as all 0 numerical combinations. It is understood that the second information can be effective to a plurality of ECUs based on the wildcards included in the group identifier of the ECU-1, so that batch refreshing of the first keys of the ECUs by the KMS is realized, and signaling overhead is saved.

To further understand how the first information indicates vrf_k through the information of MEK, one implementation of the first information is exemplified below. Specifically, the first information includes second information M1', third information M2', and fourth information M3', and for example, the first information may be expressed as M1' |m2 '|m3'. Wherein M1 'may be M1' =uid VRF K ID MEK ID, UID indicates identity information of ECU-1, VRF_K_ID andmek_id represents an index of the first key and an index of MEK, respectively, ||represents an information concatenation operation, e.g., a||b represents concatenating information a and B. M2 'may be M2' =enc _{CBC,K1’,IV’＝0} (C _ID ’||F _ID ' VRF_K), i.e. KMS will C _ID ’、F _ID After 'and VRF_K are cascaded, third information is formed by CBC mode encryption by taking K1' as a key. M3 'may be M3' =cmac _K2’ (M1 '||M2'), namely M3 'is the MAC value obtained by performing CMAC calculation by taking K2' as a secret key after M1 'and M2' are cascaded by the KMS. In the above procedure, both K1 'and K2' are derived keys of MEK. C (C) _ID The 'count value' output by a Counter (CNT) of the KMS can be used for counting, 1 can be automatically added before each encryption, and the aim of preventing replay attack can be achieved by verifying the size relation between the received CNT and the CNT generated locally, wherein the replay attack is that an attacker sends a packet received by a target host to achieve the aim of spoofing a system, and the method is mainly used for identity authentication process and damages the correctness of authentication. F (F) _ID The ' security flag for configuring the storage area corresponding to the vrf_k_id ' may include, for example, a security flag defined in the auto sar technical specification, which may include a WRITE-protect flag (write_protect_protect), a BOOT-protect flag (boot_protect), a debug-protect flag (debug_protect), a KEY USAGE flag (key_use), a wild card flag (wild), and IV ' =0 indicates that an initialization vector used based on CBC mode encryption is an all-0 vector. In this embodiment of the present application, the cascade information may include other information besides the above information, and the embodiment of the present application is not limited specifically. It should be understood that the encryption algorithm for generating M2 'and the MAC algorithm for generating M3' listed herein are merely examples, and should not be construed as limiting the embodiments herein in any way, and the encryption algorithm and the integrity protection algorithm may also include, but are not limited to, the specific implementations described above, and the embodiments herein are not specifically limited thereto.

In an embodiment of the present application, the second verification information includes information for vrf_k completeIntegrity verification information. For example, the second authentication information includes vrf_k, which may be used for integrity verification of vrf_k, in particular, the client may determine local authentication information by receiving the vrf_k in combination with locally generated first authentication parameters, which may be used for integrity verification of vrf_k and/or MEK. For another example, the second verification information includes a second verification parameter, and information obtained by integrity protecting the second verification parameter through vrf_k, where the second verification parameter is used to verify the integrity of vrf_k, and the second verification parameter may be information randomly generated by KMS, or may be information generated by KMS according to a certain rule, or may be information generated by other means, which is not specifically limited herein. In an alternative design, the second verification parameter (e.g., denoted as vrf_m) and the information obtained by integrity protecting the second verification parameter with vrf_k (e.g., denoted as vrf_mac) satisfy the following relationship: vrf_mac=cmac _{VRF_K} (VRF_M). The KMS generates integrity verification information (i.e., vrf_mac) of vrf_k by CMAC calculation using vrf_k as a key, and vrf_mac may be used to characterize the integrity of vrf_k.

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

Accordingly, the client receives the first information and the second authentication information from the key management entity.

In the embodiment of the application, the client may be used for key refreshing, that is, the client may implement writing of a key (such as an authentication key, and other temporary keys) into the ECU in the whole vehicle. The client may be, for example, an OEM key swiping device or a dealer diagnostic instrument or an on-board diagnostic (On Board Diagnostics, OBD). The OEM key swiping device may also be referred to as an OEM diagnostic tool or as an OEM diagnostic instrument, and the distributor diagnostic instrument may also be referred to as a distributor key swiping device, embodiments of the present application are not particularly limited. In addition, the client may also include an OEM server or include a dealer server.

Illustratively, if the client is an OEM key-brushing device, the KMS sends the first information and the second verification information to the client, which may include: the KMS directly sends the first information and the second verification information to the OEM key refreshing device, or the KMS firstly sends the first information and the second verification information to an OEM server, and then the OEM server forwards the first information and the second verification information to the OEM key refreshing device.

Illustratively, if the client includes an OEM server and an OEM key brushing device, the KMS transmitting the first information and the second verification information to the client may include: the KMS directly sends the first information and the second verification information to the client. Further, the OEM server may receive the first information and the second verification information from the KMS and then forward them to the OEM key brushing device. It should be appreciated that in this case, the key management entity described above may not include an OEM server.

Illustratively, if the client is a dealer diagnostic instrument, the KMS sends the first information and the second verification information to the client, which may include: the KMS directly sends the first information and the second verification information to the dealer diagnostic device, or the KMS firstly sends the first information and the second verification information to an OEM server or a dealer server, and then the OEM server or the dealer server forwards the first information and the second verification information to the dealer diagnostic device.

Illustratively, if the client includes a dealer server and a dealer diagnostic instrument, the KMS transmitting the first information and the second verification information to the client may include: the KMS directly sends the first information and the second authentication information to the client. Further, the dealer server may receive the first information and the second verification information from the KMS or from the OEM server and then forward them to the dealer diagnostic instrument. Wherein in the latter case the OEM server may first receive the first information and the second authentication information from the KMS.

For clarity of description, embodiments of the present application are described with an OEM key swiping device as one example of a client, it being understood that OEM key swiping devices may be replaced with other forms of clients.

In the embodiment of the present application, the first information may be applied to one ECU, or to a plurality of ECUs, and the second authentication information may be applied to one ECU, or to a plurality of ECUs. Illustratively, for example, the ECU to be subjected to MEK integrity verification includes ECU-1, ECU-2, and ECU-3, in which case these three ECUs may correspond to the same vrf_k, and accordingly the KMS may indicate the first key by the same first information, and the second verification information corresponding to these three ECUs is also the same; in another case, the three ECUs may correspond to different vrfs_ks, and accordingly, the first information corresponding to the three ECUs is different from each other, and the second verification information corresponding to the three ECUs is also different from each other.

It should be understood that the KMS may send the first information and the second authentication information in the same signaling, or may send the first information and the second authentication information separately through different signaling. If the first information includes a plurality of pieces of information, for example, the first information includes the second information, the third information, and the fourth information, the KMS may send the different pieces of information included in the first information separately using different signaling, or may send all the information included in the first information via the same signaling. Further, if different ECUs correspond to different first keys, the first information and the second authentication information generated based on the first keys are also different accordingly, for example, denoted as first information-1, first information-2 and first information-3, and second authentication information-1, second authentication information-2, second authentication information-3. In this case, the KMS may send the different first information and the different second verification information in the same signaling, may send the first information-1, the first information-2 and the first information-3, and the second verification information-1, the second verification information-2 and the second verification information-3 respectively through different signaling, or may send the first information and the second verification information corresponding to the respective ECUs to the OEM key writing device respectively through different signaling, for example, 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-3 and the first verification information-3 through signaling 3 to the OEM key writing device, and further, the OEM key writing device may send these information to the respective corresponding ECUs respectively. The KMS may also send the first information and the second verification information in other manners, which are not specifically limited herein.

S203, the OEM key refreshing device sends the first information and the first verification parameters to the ECU-1.

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

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

It should be noted that, in the embodiments of the present application, forwarding may be understood as transparent, that is, in this scenario, the OEM key brushing device may directly transparent the first information of the KMS to the ECU-1, and in this process, the OEM key device does not perform any processing on the first information.

In an embodiment of the present application, the first verification parameter is used to verify the integrity of vrf_k. For example, the first verification parameter is a second verification parameter, i.e. the OEM key brushing device may forward the second verification parameter from the KMS directly to the first ECU. For another example, the first verification parameter may be information generated by the OEM key swiping device, such as information randomly generated by the OEM key swiping device, or information generated by the OEM key swiping device according to a certain rule. In addition, the OEM key swiping device may also generate the first verification parameter by other means, which are not specifically limited herein. It should be appreciated that the first verification parameter may also be applied to a plurality of ECUs, i.e. the first verification parameter may be the same for a plurality of ECUs including ECU-1.

It should be understood that the OEM key refreshing device carries the first information and the first verification parameter to send in the same signaling, so as to save signaling overhead, or can send the first information and the first verification parameter respectively through different signaling, so as to realize flexibility of the 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 may 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 sends the first information and the first verification parameter to the ECU-1; alternatively, if the functional unit comprising the ECU-1 supports a forwarding mechanism, the OEM key flushing device may send the first information and the first verification parameter to the functional unit comprising the functional unit before the functional unit sends the first information and the first verification parameter to the ECU-1 via an internal forwarding mechanism, in which case it will be appreciated that the OEM key flushing device may be directly connected to the functional unit. Illustratively, the feature is a domain controller (domain controller, DC) containing one or more ECUs or is an in-vehicle key management system. In addition, in the embodiments of the present application, the domain controller may also be regarded as an electronic functional unit ECU, i.e. the domain controller may directly receive the first information from the client.

S204, the ECU-1 generates first verification information according to MEK and the first verification parameters.

Wherein the first authentication information is used to characterize the integrity of the first key.

Illustratively, the ECU-1 generating first authentication information from the MEK and the first authentication parameters may include: the ECU-1 decrypts and/or verifies the integrity of the received first information through the MEK to determine VRF_K, and generates first verification information used for representing the integrity of the first key according to the VRF_K and the received first verification parameters. Further, in an alternative design, the ECU-1 decrypts and/or integrity checks the received first information by the MEK to determine vrf_k, may include: the ECU-1 firstly determines that decryption and/or integrity check of the first information are realized through MEK based on the received first information, then executes specific decryption and/or integrity check on the first information through the MEK stored locally, and further determines VRF_K. Furthermore, the ECU-1 may obtain the first verification information through the determined vrf_k and the first verification parameter based on the MAC algorithm, for example, the first verification information (e.g., denoted as mac_t) and the first verification parameter (e.g., denoted as vrf_m) satisfy the following relationship: mact=cmac _{VRF_K} (VRF_M)。

In an alternative design, after the ECU-1 determines VRF_K, VRF_K may be stored locally.

Corresponding to a specific first information implementation manner in step S201, the following illustrates a specific implementation manner in which the ECU-1 generates the first verification information according to the MEK and the first verification parameter, where the first information includes the second information M1', the third information M2', and the fourth information M3', and specific embodiments of M1', M2', and M3' may refer to corresponding descriptions in step S201, and are not described herein. Based on the received M1', the ECU-1 determines the index of MEK (i.e., MEK_ID), and based on this, the ECU-1 uses the locally stored key corresponding to MEK_ID as MEK for integrity verification and decryption of VRF_K. For example, ECU-1 may first complete an integrity check of vrf_k or the first information based on the locally saved MEK and the received M3' to ensure that vrf_k or the first information has not been tampered with. In the event that the integrity verification of vrf_k or the first information is successful, ECU-1 decrypts M2' again from the locally saved MEK to determine vrf_k. In an alternative design, after the ECU-1 determines the vrf_k, the vrf_k determined by the decryption M2 'may be stored in the local memory corresponding to the address information based on the address information indicated by the index of the vrf_k included in the M1'. Further, after determining the vrf_k, the ECU-1 may generate the first verification information according to the determined vrf_k and the first verification parameter, and the specific generation process may refer to the above description and will not be repeated herein.

It should be noted that, the ECU-1 performs the integrity check according to MEK and M3', including the integrity check according to the derivative key of MEK, and the ECU-1 decrypts M2' according to MEK, including decrypting M2' according to the derivative key of MEK. It should be appreciated that the derivative algorithm used by the ECU-1 in determining vrf_k is the same as the derivative algorithm used by the KMS in determining the first information, and may be an algorithm pre-configured in the ECU-1.

S205, the ECU-1 transmits the first authentication information to the OEM key brushing apparatus.

Accordingly, the OEM key swiping device receives the first verification information.

S206, the OEM key refreshing device determines the integrity of MEK according to the local verification information and the first verification information, wherein the local verification information is obtained by carrying out integrity protection through VRF_K and the first verification parameter.

In one possible implementation, the local authentication information is directly from the KMS, for example, the local authentication information is information (e.g. denoted as vrf_mac) obtained by integrity protecting the second authentication parameter by the vrf_k included in the second authentication information in step 201. In this case, the first authentication parameter may be a second authentication parameter included in the second authentication information. The OEM key brushing apparatus compares the vrf_mac from the KMS with the first authentication information (e.g., denoted as mac_t) from ECU-1, and determines the integrity of the MEK based on the comparison result. Based on the above description, it should be appreciated that since VRF_MAC is derived by the KMS based on VRF_K and the second validation parameters, and MAC_T is derived by the ECU-1 based on VRF_K determined locally and the first validation parameters, by comparing VRF_MAC and MAC_T, it can be determined whether VRF_K determined locally by the ECU-1 is the same as VRF_K from the KMS. Because the vrf_k from the KMS is indicated by the MEK information, and the vrf_k determined locally by the ECU-1 is determined based on the locally stored MEK, equivalently, by comparing the vrf_mac and the mact, it can be determined whether the MEK stored locally by the ECU-1 is the same as the MEK stored by the KMS, thereby realizing the integrity verification of the MEK stored locally by the ECU-1. Specifically, if vrf_mac matches mac_t (e.g., mac_t= vrf_mac), then it may be determined that the MEK locally held by ECU-1 is complete, otherwise, it may be determined that the MEK locally held by ECU-1 is incomplete. Illustratively, mact= vrf_mac may represent that the bit value of each bit position included in mact is the same as the bit value of the corresponding bit position included in vrf_mac.

Note that in an alternative design, the MEK locally stored by ECU-1 is complete and may include: the MEK locally held by ECU-1 is the same as the MEK held by the KMS, or the MEK locally held by ECU-1 is a valid key. In an alternative design, where the MEK locally stored by the ECU-1 is incomplete, it may include: the MEK stored locally by ECU-1 is different from the MEK stored by the KMS, or the MEK stored locally by ECU-1 is not a valid key. It should be appreciated that the OEM key swiping device can only be implemented to write a functional key to the ECU-1 based on MEK, if the MEK locally stored by the ECU-1 is complete, thereby ensuring proper use of the ECU-1 throughout the vehicle.

In yet another possible implementation, the local verification information is information determined locally by the OEM key swiping device. Illustratively, the OEM key brushing device determines the local verification information based on second verification information from the KMS, wherein the second verification information includes vrf_k, and the locally generated first verification parameters. Specifically, in this manner, the local authentication information (e.g., denoted as vrf_mac) and the first authentication parameter (e.g., denoted as vrf_m) satisfy: vrf_mac=cmac _{VRF_K} (VRF_M). Similarly, since VRF_MAC is derived by the OEM key brushing device from VRF_K from the KMS and the locally generated first verification parameters, and MAC_T is derived by the ECU-1 based on the locally determined VRF_K and the first verification parameters from the OEM key brushing device, in this manner, by comparing VRF_MAC and MAC_T, it can also be determined whether the locally determined VRF_K of the ECU-1 is the same as the VRF_K from the KMS. Equivalently, by comparing vrf_mac and mact, it can be determined whether the MEK locally held by ECU-1 is the same as the MEK held by KMS, thereby achieving integrity verification of the MEK locally held by ECU-1. Specific implementation of determining the MEK integrity through the comparison result of vrf_mac and mac_t may 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 application indirectly verifies the integrity of the second key through the integrity of the first key, so that the integrity verification of the second key is realized, normal use of the function key and information security of the whole vehicle are ensured, and because the OEM key refreshing device between the KMS and the ECU-1 directly forwards the first information from the KMS to indicate the first key, the second key is prevented from being exposed out of the KMS and the ECU in a plaintext form, and further the security of core assets of the whole vehicle factory is ensured. In addition, the information for verifying the integrity of the first key does not include the identification information of the ECU, so that the whole vehicle production line does not need to collect the identification information of all target ECUs of the second key to be updated in advance, and the burden and the management cost of the whole vehicle production line are reduced. Furthermore, the KMS may also prepare the filling key material (e.g. the first information and the second verification information in the above embodiment) for the first key integrity verification in advance, and send the filling key material to the OEM key refreshing device in advance, so that the offline verification of the second key of the ECU may be implemented based on the filling key material, that is, the KMS is not dependent, and the real-time verification of the second key integrity may also be implemented, thereby reducing the time overhead. It is understood that by the scheme, the KMS is prevented from being deployed nearby the existing whole vehicle production line, the design of the whole vehicle production line is simplified, and the management cost of a whole vehicle factory is reduced.

The integrity verification of the second key can be achieved by the key verification method shown in fig. 2. In an alternative design, the KMS may also write the second key to the ECU via the client before sending the first information. Illustratively, when the second key stored locally by the ECU is different from the second key stored by the KMS, the KMS needs to write the second key stored locally by the KMS to the ECU in order to ensure normal use of the functional keys of the ECU. For example, during the whole vehicle production process, the OEM may first pass some preset root keys to the component developer (e.g., tier1 component developer), which first write them to the ECU as the ECU's initial hardware entitlement keys. And then the ECUs with the preset root keys written in are transported to a whole vehicle production line, and the OEM replaces the preset root keys of the ECUs with MEK in the whole vehicle production line, so that the function keys can be written in the ECUs, and the normal use of the ECUs is ensured. It should be appreciated that due to the key properties of the MEK, in this scenario, the second key (which may be understood as a preset root key, or an initial hardware rights key) that the ECU locally holds is different from the second key (MEK to be written) that the KMS holds; for another example, during use of the entire vehicle, there is an unavoidable condition of hardware damage or hardware upgrade, where a repair party (e.g., a 4S store) authorized by an OEM or component developer is required to replace the damaged or to-be-upgraded ECU with a new ECU, it being understood that in this scenario, the second key stored locally by the new ECU may be different from the second key stored by the KMS. In order to ensure that the replaced ECU can work normally, a new ECU needs to be written with a function key, and as described above, successful writing of the function key requires that the function key be authenticated first by an authentication key, so that the 4S store needs to write the second key stored in the KMS into the ECU through the key brushing device. After the KMS writes the second key to the ECU, the integrity verification of the second key is implemented based on the method in the embodiment shown in fig. 2.

Based on this, as a possible implementation manner, the key verification method described in the embodiment of the present application may further include steps S301 to S304 shown in fig. 3, which may be used to write the second key to the ECU, which may be necessary for some specific scenarios.

In order to better understand the relationship between the method described in the embodiments described below and the method in the embodiment shown in fig. 2, the following description uses ECU-1 as an example of the first ECU, KMS as an example of the key management entity, OEM key brushing device as an example of the client, MEK as an example of the second key, and vrf_k as an example of the first key. The steps S301-S304 are specifically as follows:

s301, the KMS generates fifth information.

Wherein the fifth information indicates MEK by information of a fifth key, the fifth key being used to authenticate MEK. The fifth key may be a preliminary ECU master key (PMEK) preset in the ECU-1, or may be a prior version of MEK stored locally in the ECU-1, for example. For example, the MEK stored locally in the KMS is MEK2.0, and the previous version of the MEK stored locally in the ECU-1 is MEK1.0, and at this time, the MEK1.0 in the ECU-1 can be replaced by MEK2.0 only by the authentication of the MEK1.0 stored locally in the ECU-1, so that the normal use of the function key of the ECU-1 is ensured. For clarity of description, the embodiments of the present application are described with PMEK as an example of the fifth key, and it is understood that PMEK may be replaced by other authentication keys for authenticating MEK.

In one possible implementation, the fifth information indicates MEK through information of PMEK, may include: the fifth information includes information obtained by encryption and/or integrity protection calculations by PMEK. Based on this, the KMS may implement that the fifth information indicates the second key through information of the PMEK. For example, the fifth information may include information generated based on the authentication key PMEK and the key MEK to be written by an encryption algorithm and/or an integrity protection algorithm, and may be used to write the MEK.

In yet another possible implementation, the fifth information indicates MEK through information of PMEK, and may include: the fifth information includes information obtained by encryption and/or integrity protection by the PMEK's derivative key. Based on this, the KMS may implement that the fifth information indicates MEK through information of PMEK. The fifth information may be information obtained by encryption and/or integrity protection calculations with one or more derivative keys of the PMEK and may be used to write the MEK. Here, one derivative key may be used for both encryption and integrity protection calculations, or may be used for encryption or integrity protection calculations only. It should be appreciated that when one derivative key is used only for encryption or integrity protection calculations, the fifth information requires that encryption and integrity protection calculations be accomplished by multiple derivative keys of the PMEK.

Illustratively, the KMS may derive two derivative keys K1, K2 corresponding to PMEK based on PMEK, parameters key_update_enc_c, and key_update_mac_c through KDF, the two derivative keys being used for encryption and integrity protection, respectively. The specific values of the parameters key_update_enc_c and key_update_macc may be predefined, for example, in the relevant technical specifications. The technical specification may be, for example, a SHE technical specification issued by the AUTOSAR organization. K1, K2 can be realized, for example, by the following equation (3) and equation (4):

k1 =second KDF (PMEK, key_update_enc_c) formula (3)

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

Thereafter, the KMS may encrypt the MEK based on the K1 to obtain seventh information included in the fifth information through an encryption algorithm, for example, the KMS may encrypt the MEK by using the AES algorithm; the KMS may also perform integrity protection on the MEK based on K2 using a MAC algorithm to obtain eighth information included in the fifth information. It should be appreciated that the encryption algorithm and the integrity protection algorithm include, but are not limited to, the specific implementations described above, and embodiments of the present application are not specifically limited thereto.

Further, the KMS may concatenate the identity information of the ECU-1, the index of the MEK, and the index of the PMEK to obtain sixth information included in the fifth information. The identity information of the ECU-1 and the index of the MEK may be described in the above S201, and will not be described here. The index of the PMEK is used to uniquely identify the PMEK and may be used to indicate address information that the PMEK holds in the ECU-1. When the identity information of the ECU-1 is the group identifier including the wildcard, the fifth information can be effective to a plurality of ECUs, so that batch brushing of the KMS on the second keys of the plurality of ECUs is realized, and signaling overhead is saved.

To further understand how the fifth information indicates MEK through the information of PMEK, an implementation of the fifth information is exemplified below. Specifically, the fifth information includes sixth information M1, seventh information M2, and eighth information M3. Where M1 may be m1=uid i mek_id i pmek_id, UID represents identity information of ECU-1, mek_id and pmek_id represent the index of MEK and the index of PMEK, respectively, ||represents an information concatenation operation, e.g., a||b represents concatenating information a and B. M2 may be m2=enc _{CBC,K1,IV＝0} (C _ID ||F _ID MEK), i.e., KMS will C _ID 、F _ID And after the MEK is cascaded, the seventh information is formed by encrypting the key K1 through a CBC mode. M3 may be m3=cmac _K2 (M1I M2), namely M3 is the MAC value obtained by the KMS through CMAC calculation by taking K2 as a key after cascading M1 and M2. In the above procedure, both K1 and K2 are derived keys of PMEK. C (C) _ID The count value output by a counter CNT local to the KMS can be used for counting, 1 can be automatically added before each encryption, and the aim of preventing replay attack can be achieved by verifying the size relation between the received CNT and the locally generated CNT. F (F) _ID For the specific description of the security flag used for configuring the storage area corresponding to the mek_id, reference may be made to the description related to S201, which is not described herein. Iv=0 means that the initialization vector used for CBC mode-based encryption is an all 0 vector. It should be noted that, in the embodiment of the present application, the concatenation information includes, in addition to the above information Other information may be included, and embodiments of the present application are not specifically limited. It should be understood that the encryption algorithm for generating M2 and the MAC algorithm for generating M3 listed herein are examples only and should not be construed as limiting the embodiments herein in any way. Those skilled in the art will recognize that the encryption algorithm and the integrity protection algorithm may also include, but are not limited to, the specific implementations described above, and the embodiments of the present application are not specifically limited thereto.

S302, the KMS sends fifth information to the OEM key refreshing device.

Accordingly, the OEM key swiping device receives the fifth information. Similarly, if a plurality of pieces of information are included in the fifth information, for example, the sixth information, the seventh information, and the eighth information are included in the fifth information, the KMS may transmit the different pieces of information included in the fifth information separately with different signaling, or may transmit all pieces of information included in the fifth information through the same signaling. In addition, the KMS may further carry the fifth information (or part of the information included in the fifth information) and other information (such as the first information or part of the information included in the first information) sent to the OEM key brushing device in the same signaling, or may also be sent through different signaling. The embodiment of the application does not limit a specific manner of implementing the fifth information transmission.

The OEM key overwriting device transmits this fifth information to the ECU-1S 303.

Accordingly, the ECU-1 receives the fifth information. The OEM key brushing device forwards the fifth information from the KMS to ECU-1 so that ECU-1 can determine MEK based on the fifth information. The specific implementation manner of the OEM key refreshing device for sending the fifth information to the ECU-1 may refer to the corresponding description in S203, and will not be described herein.

S304, the ECU-1 determines MEK according to the fifth information.

Illustratively, the ECU-1 determining MEK based on the fifth information may include: the ECU-1 decrypts and/or integrity checks the received fifth information according to the PMEK to determine MEK. Specifically, for example, the ECU-1 determines, based on the received fifth information, that decryption and/or integrity check of the fifth information is achieved through PMEK, and then performs specific decryption and/or integrity check of the fifth information through locally stored PMEK, thereby determining MEK.

Corresponding to a specific fifth information implementation manner in step S301, the following illustrates a specific implementation manner of determining MEK by the ECU-1 according to the fifth information, where in this example, the fifth information includes sixth information M1, seventh information M2, and eighth information M3, and specific embodiments of M1, M2, and M3 may refer to corresponding descriptions in step S301, and are not described herein. The ECU-1 determines the index of the PMEK (i.e., PMEK_ID) according to the received M1, and based on the index, the ECU-1 takes a locally stored key corresponding to the PMEK_ID as the PMEK for the integrity verification and decryption of the MEK. For example, the ECU-1 may first complete an integrity check of the MEK or fifth information based on the locally saved PMEK and the received M3 to ensure that the MEK or fifth information has not been tampered with. In the event that the integrity verification of the MEK or fifth information is successful, the ECU-1 decrypts M2 again based on the locally stored PMEK to determine the MEK.

Further, after the ECU-1 determines MEK, the MEK is stored locally. For example, the ECU-1 may store the MEK determined by decrypting M2 in a local memory corresponding to the address information based on the address information indicated by the index of the MEK (i.e., mek_id) included in M1, or replace the locally stored PMEK with the MEK.

Based on the method in the embodiment shown in fig. 3, before the MEK is verified, the MEK can be written into the ECU first, so that the requirement that the MEK is correctly written into the first electronic control unit by a maintenance party authorized by the whole vehicle production line and/or the whole vehicle factory is met, authentication conditions are further provided for writing of subsequent function keys, and normal use of the function keys and information security of the whole vehicle are ensured. The method for writing the MEK into the ECU can be suitable for various scenes to be written by the MEK, and can simplify the key management flow of a key management entity or a whole vehicle factory and simplify the key writing flow through a unified solution suitable for various scenes. In addition, as the second information comprises information obtained by encrypting and/or protecting the integrity of the MEK, the MEK can be prevented from being exposed outside the KMS and the ECU in a plaintext form in the MEK writing process, and the safety of the core assets of the whole vehicle factory is further ensured.

Further, in an alternative design, the key verification method described in the embodiments of the present application may further include one or more steps of steps S401-S404 shown in fig. 4, where the one or more steps may be necessary for some specific scenarios. The steps S401 to S404 are specifically as follows:

in step S401, the OEM key refreshing apparatus transmits MEK update request information to the KMS.

Accordingly, the KMS receives the MEK update request information.

The MEK update request information is used to request update of MEK of the ECU-1. Alternatively, the MEK update information may be used to request the KMS to verify the MEK integrity locally held by the ECU-1, or the MEK update request information may be used to request the KMS to write MEK to the ECU-1 (including integrity verification of MEK).

In an alternative design, the MEK update request information may further include one or more of the following: the OEM key is used for refreshing identity authentication information of the device, the number of ECUs of MEK to be updated (or the number of ECUs of MEK integrity to be verified), the identification code VIN of the whole vehicle to which the ECUs belong, the version number of the authentication key locally stored by the ECUs and different version numbers of the ECUs. The identity authentication information may be used to characterize whether the OEM key refreshing device has authority to acquire one or more pieces of information, such as first information, fifth information, and second verification information, acquired from a key management entity by a client included in embodiments of the present application. VIN may be used to identify a whole vehicle. Different version numbers of the ECU may be used to identify the version number of the locally stored authentication key of the ECU, for example PMEK, MEK1.0, MEK2.0, etc. It should be appreciated that the ECU to be updated with MEK or the ECU with verification of MEK integrity described above includes ECU-1.

In step S402, the KMS verifies the MEK update request information.

Accordingly, the KMS may verify the MEK update request information after receiving the MEK update request information. And according to the verification result, determining whether the first information indicating the first key and the second verification information for verifying the integrity of the first key are passed or determined to pass through the method described in the embodiment of the application, and sending the first information indicating the first key, the second verification information for verifying the integrity of the first key and the fifth information indicating the second key to the OEM key writing device.

In an alternative design, the KMS verifies the MEK update request information, which may include one or more of the following: the KMS verifies the validity of the MEK update request information, the KMS determines specific information for writing the MEK (including integrity verification of the MEK), and the KMS determines specific information for verifying the MEK integrity.

Illustratively, the KMS checking the validity of the MEK update request information can be understood as: the KMS determines whether the OEM key brushing device that initiated the MEK update request information has permission to acquire information related to MEK writing and/or integrity verification, such as first information, fifth information, second verification information in embodiments of the present application; alternatively, the KMS checking the validity of the MEK update request information can also be understood as: the KMS determines, via the identity authentication information of the OEM key updating device, whether the OEM key updating device is an OEM authorized key updating device. If the OEM key flush device is an OEM authorized key flush device, the OEM key flush device may be defaulted to have access to information related to MEK writing and/or integrity verification, such as first information, fifth information, second verification information in embodiments of the present application. In particular, for example, for an after-market repair scenario, the identity authentication information may characterize whether the 4S store or repair party initiating the MEK update request is an OEM-authorized dealer. It should be appreciated that in this scenario, the OEM key swiping device may be replaced with a dealer diagnostic instrument. If the identification information can characterize the 4S store or the service party as an OEM authorized dealer, the KMS can send MEK write and/or integrity verification related information to the dealer diagnostic device. Based on the method, the information related to MEK writing and/or integrity verification can be guaranteed to be only provided for the KMS or the authorized client of the whole vehicle factory, and therefore the safety of MEK is guaranteed.

Illustratively, the KMS may determine specific information for writing to the MEK (including integrity verification of the MEK) or specific information for verifying the integrity of the MEK by one or more of the following information included in the MEK update request information. The following information is: the number of ECUs of MEK to be updated (or the number of ECUs of MEK integrity to be verified), the identification code (vehicle identification number, VIN) of the whole vehicle to which the ECUs belong, the version number of the authentication key locally stored by the ECUs, and different version numbers of the ECUs. For example, the KMS may determine one or more of the following information by the number of ECUs to update the MEK or the number of ECUs to verify the integrity of the MEK: the number of the first information, the number of the second verification information and the number of the fifth information can further realize MEK batch writing and/or MEK batch integrity verification of batch ECUs, and the cost of key management is reduced. For another example, the 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 by the ECU, so as to ensure effective MEK writing, and further can write a function key based on the MEK, so as to ensure normal use of the ECU.

In an alternative design, step S403 may also be included prior to step S401. The step S403 specifically includes:

s403, the ECU-1 sends the version number of the MEK stored locally to the OEM key refreshing device.

Accordingly, the OEM key swiping device receives the locally saved version number of MEK.

In an alternative design, the ECU-1 may also send one or more of the following information to the OEM key brushing device: the identification code of the whole vehicle to which the ECU-1 belongs, namely VIN, different version numbers of the ECU-1, the equipment identification code of the ECU-1 and the equipment type of the ECU-1.

It should be appreciated that the OEM key swiping device may determine the number of ECUs for which MEK is to be updated or the number of ECUs for which MEK integrity is to be verified by collecting the above information for a plurality of ECUs.

S404, the OEM key brushing device sends the KMS an update result of MEK.

Accordingly, the KMS receives the OEM key brushing device.

The updated results of the MEK include one or more of the following: the integrity of MEK, the integrity of VRF_K, and the identity of ECU-1. Wherein the integrity of the MEK is used for representing whether the MEK is written into the ECU-1 and passes the integrity verification, or the integrity of the MEK is used for representing whether the MEK locally stored in the KMS is identical with the MEK locally stored in the ECU-1; the integrity of VRF_K is used to characterize whether VRF_K is written to ECU-1 and passed the integrity verification.

Illustratively, based on the updated results, the KMS may determine whether MEK is completely written to ECU-1, and if it is determined that MEK is not completely written to ECU-1, may retry writing MEK to ECU-1 by the OEM key swiping device; if it is determined that MEK is completely written to ECU-1, the updated results may be documented for possible subsequent use.

In an alternative design, as a possible implementation manner, before the method in the above embodiments, step S401 to step S403 shown in fig. 4 may be included, and after the method in the above embodiments, step S404 shown in fig. 4 may be included.

Through the MEK update request information, the KMS can generate information suitable for MEK update or MEK integrity verification, so that the MEK integrity verification is realized, and the normal use of a function key and the information safety of the whole vehicle are ensured. Through the updating result, the KMS can determine whether the MEK is written into the first electronic control unit and/or whether the authentication key locally stored in the first electronic control unit is the MEK, so that the normal use of the function key and the information security of the whole vehicle are ensured. In addition, by collecting the identity of the ECU-1, the key management entity is also facilitated to manage the electronic control unit written in the MEK and/or the electronic control unit with the verified authentication key integrity.

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

s501, the ECU-1 generates ninth information from the first information and the challenge-response mechanism.

Wherein the ninth information includes information for verifying the integrity of vrf_k. Illustratively, the ninth information generated in the step S201 may include eleventh information and twelfth information, where the eleventh information is at least obtained by concatenating the identity of the ECU-1, the index of the vrf_k, the index of the MEK, and thirteenth information, the twelfth information is obtained by integrity protecting the eleventh information by the derivative key of the vrf_k, and the thirteenth information is a count value (e.g., C _ID ') the resulting information is encrypted. It will be appreciated that based on this, not only can the integrity verification of vrf_k be achieved, but also the effect of anti-replay estimation can be achieved by the eleventh information comprising the thirteenth information. It should be noted that the derivation algorithm, encryption algorithm, and integrity protection algorithm used for generating the derived key may include, but are not limited to, the specific implementation described above, and the embodiments of the present application are not specifically limited herein.

S502, the ECU-1 transmits the ninth information to the OEM key brushing apparatus.

Accordingly, the OEM key swiping device receives the ninth information.

In an alternative design, the ECU-1 may carry the ninth information with other information sent to the OEM key flushing device (e.g., the first verification information) in the same signaling, or may send the ninth information separately from other information sent to the OEM key flushing device through different signaling.

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

Accordingly, the KMS receives the ninth information.

In an alternative design, the OEM key swiping device does not further process the received ninth information, e.g., does not parse the ninth information.

In an alternative design, the KMS can determine the identity of the ECU-1 according to the ninth information, and the identity is used for recording the ECU with the MEK integrity confirmed by the whole vehicle factory.

Illustratively, in this scenario, the ECU-1 may correspond to a responder in a challenge-response mechanism, the OEM key swiping device may correspond to a challenger in the challenge-response mechanism, the challenge issued by the challenger is included in the first information, and the ninth information may correspond to a corresponding response by the responder. In this scenario, the OEM key brushing device does not parse the ninth information, but instead sends it to the KMS for further processing, which determines whether the responder passed the challenge and/or determines whether the responder should be authenticated. In this way, the integrity verification of the 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, and based on this, the ninth information may be understood as an example of the integrity information of vrf_k. It should be appreciated that this ninth information may be included in the update results of vrf_k sent by the OEM key brushing device to the KMS.

In addition, when the key verification method described in the embodiments of the present application includes the method in the embodiment shown in fig. 3, the key verification method described in the embodiments of the present application may further include step S601 to step S602 shown in fig. 6, or may further include step S601 to step S603 shown in fig. 6. The steps S601 to S603 are specifically as follows:

s601, the ECU-1 generates tenth information according to the fifth information and the challenge-response mechanism.

Wherein the tenth information includes information for verifying the integrity of the MEK. Illustratively, the tenth information generated in the step S301 may include fourteenth information and fifteenth information, where the fourteenth information is obtained by at least the identity of the ECU-1, the index of the MEK, the index of the PMEK, and the concatenation of the fifteenth information, the fifteenth information is obtained by integrity protecting the fourteenth information by the derivative key of the MEK, and the sixteenth information is obtained by integrity protecting the count value (e.g., C _ID ) The resulting information is encrypted. It should be appreciated that, based on this, not only can the integrity verification of MEK be achieved,the effect of the playback prevention estimation can also be achieved by fourteenth information including sixteenth information. It should be noted that the derivation algorithm, encryption algorithm, and integrity protection algorithm used for generating the derived key may include, but are not limited to, the specific implementation described above, and the embodiments of the present application are not specifically limited herein.

S602, the ECU-1 transmits the tenth information to the OEM key brushing apparatus.

Accordingly, the OEM key swiping device receives the tenth information.

In an alternative design, the ECU-1 may carry the tenth information with other information (e.g., the first verification information, the ninth information) sent to the OEM key flushing device in the same signaling, or may send the tenth information separately from other information sent to the OEM key flushing device through different signaling.

And S603, the OEM key refreshing device sends the tenth information to the KMS.

Accordingly, the KMS receives the tenth information.

In an alternative design, the OEM key swiping device does not further process the received tenth information, e.g., does not parse the tenth information.

In an alternative design, the KMS may determine the identity of the ECU-1 based on the tenth information for the vehicle management facility to record the ECU with the MEK integrity confirmed.

Illustratively, in this scenario, the ECU-1 may correspond to a responder in a challenge-response mechanism, the OEM key brushing device may correspond to a challenger in the challenge-response mechanism, the fifth information includes a challenge issued by the challenger, and the tenth information may correspond to a response made by the responder. In this scenario, the OEM key brushing device does not parse the tenth information, but instead sends it to the KMS for further processing, which determines if the responder passed the challenge and/or determines if the responder should be authenticated. In this way, the MEK can be verified for integrity, and the implementation is simple.

It should be noted that, the tenth information may be used to indicate the integrity of the MEK, and based on this, the tenth information may be understood as an example of the integrity information of the MEK, that is, the tenth information may be included in the update result of the MEK sent to the KMS by the OEM key brushing device.

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

The key verification method provided by the embodiment of the present application is described above with reference to fig. 2 to 6, and the device provided by the embodiment of the present application is described in detail below with reference to fig. 7 to 9.

Fig. 7 is a schematic block diagram of a control device provided in an embodiment of the present application. As shown in fig. 7, the control device may include at least one processor and memory to perform the method in any of the possible implementations above. Wherein the memory is for storing a computer program or instructions and the at least one processor is for invoking the computer program or instructions in the memory. For example, the at least one processor may be configured to perform internal processing within the control device, for example, to generate first authentication information based on the second key and the first authentication parameter, the first authentication information being used to characterize the integrity of the first key; for another example, first information and second authentication information are generated; for another example, the integrity of the second key is determined according to local verification information and the first verification information, wherein the local verification information comprises information obtained by carrying out integrity protection on the first verification parameter through the first key.

Further, in an alternative design, the control device may also include a transceiver, as shown in fig. 8. Fig. 8 is a schematic block diagram of a control device provided in an embodiment of the present application. Wherein the transceiver is coupled to at least one processor, memory included in the control device, it being understood that the transceiver, the at least one processor, and the memory communicate with each other via an internal connection path. In particular, the transceiver may provide information input and/or output to the at least one processor and the memory to cause the control device to perform the method in any one of the possible implementations of the embodiments of the present application. For example, the transceiver may be configured to receive first information; for another example, the transceiver may be configured to receive a first verification parameter; for another example, the transceiver may be configured to transmit first authentication information, etc.

In a further implementation, the control device includes means for performing the method in any of the possible implementations of the embodiments of the present application.

In an alternative design, the control device may be a control device of an electronic component for performing any of the methods performed by the ECU-1 above; or the control device is a control device of a key management entity, and is used for executing any method executed by the KMS; or the control means is control means of a key swiping tool for performing any of the methods performed by the OEM key swiping means above.

There is also provided in an embodiment of the present application a vehicle comprising a control device implementing the method in any one of the possible implementations performed by the ECU-1 above, or an electronic component implementing the method in any one of the possible implementations performed by the ECU-1 above.

Also provided in embodiments of the present application is a system comprising one or more of an electronic component for performing the method in any of the possible implementations performed by the ECU-1 above, a vehicle comprising a control device for performing the method in any of the possible implementations performed by the ECU-1 above, a vehicle comprising an electronic component for performing the method in any of the possible implementations performed by the ECU-1 above, a key management entity for performing the method in any of the possible implementations performed by the KMS above, or a key swiping tool for performing the method in any of the possible implementations performed by the OEM key swiping device above.

Also provided in embodiments of the present application is a system comprising control means for performing the method in any of the possible implementations performed by the ECU-1 above, control means for performing the method in any of the possible implementations performed by the KMS above, or one or more of control means for performing the method in any of the possible implementations performed by the OEM key swiping means above.

In addition, a chip is further provided in the embodiment of the application, as shown in fig. 9. Fig. 9 shows a schematic diagram of the structure of a chip. The chip comprises one or more processors and interface circuitry for providing information input and/or output to the one or more processors for performing the method in any of the possible implementations above. In an alternative design, the chip may further include a bus. The processor is, for example, an integrated circuit chip with signal processing capabilities. For example, the processor may be a field programmable gate array (field programmable gate array, FPGA), a general purpose processor, a digital signal processor (digital signal processor, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, a system on chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

The interface circuit can be used for sending or receiving data, instructions or information, the processor can process by utilizing the data, instructions or other information received by the interface circuit, and the processing completion information can be sent out through the interface circuit.

In an alternative design, the chip may further include memory, which may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and direct memory bus RAM (DR RAM).

It should be noted that, the functions corresponding to the processor and the interface circuit may be implemented by hardware design, or may be implemented by software design, or may be implemented by a combination of software and hardware, which is not limited herein.

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

The present application also provides a computer program product comprising: computer program code which, when run on a computer, causes the computer to perform the method in any of the possible implementations performed by the first node above, or to perform the method in any of the possible implementations performed by the second node above.

The present application also provides a computer readable medium having stored program code which, when run on a computer, causes the computer to perform the method of any one of the possible implementations described above.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, 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 a computer, the processes or functions described in accordance with embodiments of the present application result, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may 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 may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

A method of authentication, comprising:

receiving, by a client, first information from a key management entity, the first information indicating a first key by information of a second key, the second key being configured to authenticate at least one function key of a first 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;

generating first verification information according to the second key and the first verification parameter, wherein the first verification information is used for representing the integrity of the first key;

and sending the first verification information to the client.
The method of claim 1, wherein the first information comprises information obtained by encryption and/or integrity protection by a derivative of the second key.
The method of claim 1 or 2, wherein the first information comprises:

second information obtained at least by concatenating 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 by a third key, and

and fourth information obtained by carrying out integrity protection on at least information cascaded by the second information and the third information through a fourth key, wherein the third key and the fourth key are derivative keys of the second key.
A method according to any one of claims 1 to 3, wherein the method further comprises:

Receiving, by the client, fifth information from the key management entity, the fifth information indicating the second key through information of a fifth key,

wherein the fifth key is used to authenticate the second key.
The method of claim 4, wherein the fifth information comprises information obtained by encryption and/or integrity protection of a derivative of the fifth key.
The method of claim 4 or 5, wherein the fifth information comprises:

sixth information obtained by concatenating at least 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 by the sixth key, and

and (c) eighth information obtained by performing integrity protection on at least information concatenated by the sixth information and the seventh information through a seventh key, wherein the sixth key and the seventh key are derivative keys of the fifth key.
The method according to any of claims 3 to 6, wherein the identity information of the first electronic control unit comprises an identity of the first electronic control unit or a group identity of the first electronic control unit, wherein:

The identity of the first electronic control unit is used for uniquely identifying the first electronic control unit;

the group identifier of the first electronic control unit comprises at least one wildcard, and the group identifier of the first electronic control unit is used for identifying the equipment group to which the first electronic control unit belongs.
A method according to any one of claims 1 to 7, wherein the first authentication information comprises information obtained by integrity protection of the first authentication parameter by the first key.
A method of authentication, comprising:

generating first information indicating a first key by information of a second key, the second key being configured to authenticate at least one functional key of a first electronic control unit, the at least one functional key corresponding to at least one service function of the first electronic control unit, and second verification information comprising information for integrity verification of the first key;

and sending the first information and the second verification information to a client.
The method of claim 9, wherein the first information comprises information obtained by encryption and/or integrity protection by a derivative of the second key.
The method of any one of claims 9 or 10, wherein the method further comprises:

transmitting fifth information to the client, the fifth information indicating the second key through information of a fifth key,

wherein the fifth key is used to authenticate the second key.
The method of claim 11, wherein the fifth information comprises information obtained by encryption and/or integrity protection of a derivative of the fifth key.
The method of any of claims 9 to 12, wherein the second authentication information comprises:

a second verification parameter, and information obtained by integrity protection of the second verification parameter by the first key,

wherein the second verification parameter is used to verify the integrity of the first key.
The method of any one of claims 9 to 13, wherein the method further comprises:

receiving second key update request information from the client, the second key update request information being for requesting updating of the second key,

wherein the second key update request information includes identity authentication information of the client.
The method of any one of claims 9 to 14, wherein the method further comprises:

receiving an update result of the second key from the client, the update result of the second key including one or more of: the integrity information of the second key, the identity of the first electronic control unit, or the integrity information of the first key,

the identity of the first electronic control unit is used for uniquely identifying the first electronic control unit.
A method of authentication, comprising:

receiving first information from a key management entity;

transmitting the first information to a first electronic control unit, the first information indicating a first key by information of a 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 at least one service function of the first electronic control unit;

transmitting a first verification parameter to the first electronic control unit, wherein the first verification parameter is used for verifying 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;

And determining the integrity of the second key according to the local verification information and the first verification information, wherein the local verification information comprises information obtained by carrying out integrity protection on the first verification parameter through the first key.
The method of claim 16, wherein the first authentication parameter is from the key management entity; or, the first verification parameter is information generated by the client.
Method according to claim 16 or 17, wherein said first information comprises information obtained by encryption and/or integrity protection by a derivative of said second key.
The method of any one of claims 16 to 18, wherein the method further comprises:

transmitting fifth information to the first electronic control unit, the fifth information indicating the 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 comprises information obtained by encryption and/or integrity protection of a derivative of the fifth key.
The method of any one of claims 16 to 20, wherein the method further comprises:

Sending second key update request information to the key management entity, the second key update request information being used to request updating of the second key,

wherein the second key update request information includes identity authentication information of the client.
A control device comprising means for performing the method of any one of claims 1 to 8, or any one of claims 9 to 15, or any one of claims 16 to 22.
A control device comprising at least one processor and a memory, the memory for storing a computer program or instructions, the at least one processor for invoking the computer program or instructions in the memory to cause the control device to perform the method of any of claims 1-8, or any of claims 9-15, or any of claims 16-22.
A vehicle characterized by comprising control means for performing the method according to any one of claims 1 to 8.
A key management entity, characterized by comprising control means for performing the method of any of claims 9 to 15.
A key swiping tool comprising control means for performing the method of any of claims 16 to 22.
A system comprising one or more of the vehicle of claim 24, the key management entity of claim 25, or the key swiping tool of claim 26.
A chip comprising one or more processors and interface circuitry for providing information input and/or output to the one or more processors, the chip for performing the method of any one of claims 1 to 8, or any one of claims 9 to 15, or any one of claims 16 to 22.
A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program or instructions, which, when executed by a processor, implements the method of any one of claims 1 to 8, or any one of claims 9 to 15, or any one of claims 16 to 22.
A computer program product, characterized in that it implements the method of any one of claims 1 to 8, or of any one of claims 9 to 15, or of any one of claims 16 to 22, when run on one or more processors.