WO2022151478A1

WO2022151478A1 - Vehicle key management method, device, and system

Info

Publication number: WO2022151478A1
Application number: PCT/CN2021/072509
Authority: WO
Inventors: 李�泳; 段立; 耿峰; 易平平
Original assignee: 华为技术有限公司
Priority date: 2021-01-18
Filing date: 2021-01-18
Publication date: 2022-07-21
Also published as: CN112840683A; CN112840683B

Abstract

Embodiments of the present application relate to a vehicle key management method, device, and system. The system comprises: a vehicle external key management device, which is used to generate a vehicle key of a vehicle, wherein the vehicle key corresponds to a plurality of vehicles; the vehicle key is sent to a vehicle key management device, the vehicle key management device being used to receive the vehicle key from the vehicle external key management device; and the vehicle key is used to generate a master key uniquely corresponding to the vehicle. By using the present application, a vehicle external key management device cooperates with a vehicle key management device to generate a master key of a vehicle, thereby reducing the pressure of the vehicle external key management device and improving the security of a vehicle key.

Description

Vehicle key management method, device and system

technical field

The present application relates to the field of Internet of Vehicles, and in particular, to a vehicle key management method, device and system thereof.

Background technique

With the rapid development of automotive electronics, information technology and networks, traditional information security problems in the Internet and other fields have gradually threatened the vehicles in the connected car network, seriously hindering the development of traditional cars in the direction of intelligent network connection. Among them, the security of the vehicle key is particularly important. The vehicle key can be used to identify each vehicle in the vehicle network, so as to perform operations such as inter-vehicle communication and saving sensitive data in the vehicle. Therefore, in the related art, it is necessary to establish a secure key management system, which can distribute vehicle keys for each vehicle.

In the related art, the key management system (KMS) of the original equipment manufacturer (OEM) is usually responsible for the vehicle keys of all the vehicles it manufactures, including sending the keys to the various production lines related to the vehicles. OEMs/equipment manufacturers distribute vehicle keys, etc., which will place a great burden on the OEM KMS, thereby reducing management efficiency and security.

SUMMARY OF THE INVENTION

The embodiments of the present application propose a vehicle key management method, device, and system, which are used to improve the management efficiency and security of vehicle keys.

In a first aspect, an embodiment of the present application provides a vehicle key management system, the system comprising: an off-vehicle key management device configured to generate a vehicle key of the vehicle, wherein the vehicle key corresponds to multiple send the vehicle key to a vehicle key management device, the vehicle key management device is used to receive the vehicle key from the off-vehicle key management device; use the vehicle key to generate and The vehicle's unique corresponding master key.

In the system, the vehicle key management device and the off-vehicle key management device jointly generate the master key of the vehicle, thereby reducing the device pressure of only using the parking space key management device. When the off-vehicle key management device generates vehicle keys for multiple vehicles, the vehicle key management device is used to generate a unique master key for the vehicle according to the vehicle key, thereby reducing the need for the off-vehicle key management device. The uniqueness of the master key is guaranteed and the security is improved under the pressure.

In a second aspect, an embodiment of the present application provides a vehicle key management method, the method includes receiving a vehicle key corresponding to the vehicle from an off-vehicle key management device; using the vehicle key to generate a vehicle key corresponding to the vehicle The vehicle's unique corresponding master key.

In the method, the master key for the vehicle is generated by the vehicle key management device, that is, the operation of generating the master key is delegated to the vehicle, so that the vehicle participates in the generation of the master key and The uniqueness of the master key is guaranteed.

In a possible design, the method further includes: using the master key to determine a first ECU key corresponding to an electronic control unit ECU in the vehicle.

The method can use the master key to realize one key for one ECU under the condition of realizing one encryption for one vehicle, thereby improving the security between each ECU.

In a possible design, the method further includes: sending the first ECU key to the ECU.

That is, the vehicle key management device is not only responsible for generating ECU keys but also responsible for distributing each ECU key.

In a possible design, the method further includes: sending a second ECU key to the ECU, where the second ECU key is a key generated after updating the first ECU key.

The method can not only realize the generation of the ECU key, but also can update the ECU key, which further improves the security.

In a possible design, before sending the second ECU key to the ECU, the method further includes: sending first verification information to the ECU, wherein the first verification information is a pair of keys using the first ECU key Information generated after the first information is encrypted.

In order to ensure security, it is possible to separately verify whether the communication between the ECU and the vehicle key management device is secure before performing the update of the ECU key. verify message.

In a possible design, the method further includes: receiving second verification information from the ECU.

In the process of verifying the security of the communication, the ECU also needs to perform a verification operation on the vehicle key management device. Therefore, the ECU sends the second verification information to the vehicle key management device.

In a possible design, the method further includes: performing a decryption operation on the second verification information by using the first ECU key to obtain the decrypted second verification information.

In the process of verifying communication security, if the vehicle key management device can successfully decrypt the second verification information by using the first ECU key, the described vehicle key management device passes the verification.

In a possible design, the method further includes: when it is determined that the decrypted second verification information includes the first information, using the first ECU key to pair the decrypted second verification information with the second ECU key The encryption key is used to perform encryption operations to generate third verification information.

After passing the above verification operation, encryption of the ECU key to be updated (second ECU key) may be performed using the existing ECU key (first ECU key) for security.

In a possible design, the method further includes: sending third verification information to the ECU.

The method can send the encrypted second ECU key to the ECU, so that the ECU can obtain the second ECU key while ensuring communication security.

In a possible design, the first ECU key is at least related to the master key and the identification information of the first ECU.

The first ECU key is related to the master key and the identification information of the first ECU, which not only ensures that the ECU key is related to the vehicle in which it is located, but also ensures the uniqueness of each ECU in the vehicle.

In a possible design, the first ECU key is related to the master key, key version information of the first ECU key, and identification information of the first ECU.

Considering that an update operation needs to be performed on the ECU key, the first ECU key can also be related to version information in addition to the master key and identification information.

In a possible design, using the master key to determine the first ECU key corresponding to an electronic control unit (ECU) in the vehicle includes: using the master key and the encryption key of the ECU key The triplet composed of the key version information and the identification information of the ECU is used as the first ECU key.

In an implementation, the first EUC key may be constructed in the form of a triplet.

In a possible design, the master key is at least related to the vehicle key and the identification information of the vehicle.

In order for the master key to uniquely correspond to a vehicle, the master key may be associated with identification information of the vehicle.

In a possible design, the master key is related to the vehicle key, key version information of the master key, and identification information of the vehicle.

In order to be able to perform an update on the master key, the master key may also be associated with key version information.

In a possible design, using the vehicle key to generate a master key uniquely corresponding to the vehicle includes: using the vehicle key, key version information of the master key, and the vehicle The triplet composed of the identification information is used as the master key of the vehicle.

In implementation, the master key may be constructed by using the vehicle key, the key version information of the master key, and the identification information of the vehicle in the form of a triplet.

In a third aspect, an embodiment of the present application provides a vehicle key management method comprising: determining a vehicle attribute node of the vehicle in a vehicle attribute structure; using the vehicle attribute node to obtain a parent key corresponding to the vehicle ; Use the parent key and the vehicle attribute information corresponding to the vehicle attribute node to generate the vehicle key of the vehicle; send the vehicle key to the vehicle, wherein the vehicle key can be encrypted by the vehicle The key management device is used to generate a master key uniquely corresponding to the vehicle.

In the method, after determining the parent key of the vehicle and the vehicle attribute information, the vehicle key of the vehicle can be generated. In this way, the generation operation of the vehicle key can be delegated to each intermediary that manufactures the vehicle. Thereby reducing the pressure on the OEM KMS.

In a possible design, the vehicle key is also related to version information of the vehicle key.

In order to enable vehicle key update, the vehicle key may be associated with version information.

In a possible design, the method further includes: generating the vehicle attribute structure according to the vehicle attributes according to the parent-child relationship, wherein the vehicle attribute structure includes a plurality of vehicle attribute nodes, which are located at the upper node of the vehicle attribute nodes Indicates a parent attribute node of the vehicle attribute node; generating a vehicle key structure that is structurally identical to the vehicle attribute structure, wherein the vehicle key structure includes a plurality of vehicle key nodes located in the vehicle key The upper key of the key node indicates the parent key of the vehicle key node.

The method can determine the vehicle key structure under the condition that the vehicle attribute structure is generated according to the vehicle attributes, so that in the process of generating the vehicle key, the final vehicle key can be generated through the layer-by-layer operation through this layered structure. Data processing volume of OEM KMS.

In a possible design, using the vehicle attribute node to obtain the parent key corresponding to the vehicle includes: determining the node position of the vehicle attribute node in the vehicle attribute structure; using the node position, Determine the vehicle key node of the vehicle in the vehicle key structure; obtain the parent key of the vehicle key node.

In implementation, the method may use the vehicle attribute node to determine the node location where the vehicle is located, and then utilize the node location to determine the parent key, thereby generating the vehicle key.

In a fourth aspect, embodiments of the present application provide a vehicle key management method, the method comprising: receiving a first ECU key from a vehicle key management device, wherein the first ECU key is the vehicle key management The device generates a master key uniquely corresponding to the vehicle using a vehicle key of the vehicle, the vehicle key being a key received from an off-vehicle management device.

The method uses the master key to generate an ECU key unique to the ECU, and implements one ECU one key.

In order to ensure that each ECU has its corresponding unique ECU key and can perform an update operation on the ECU key, the first ECU key may be related to the master key, key version information and identification information.

In a possible design, the method further includes: receiving first verification information from the vehicle key management device.

In implementation, before the key update is performed on the ECU, a verification operation needs to be performed on the ECU, so the first verification information can be sent to the ECU.

In a possible design, the method further includes: decrypting the first verification information by using the first ECU key to obtain the first information.

That is to say, after the ECU successfully decrypts the first verification information by using its existing ECU key (the first ECU key), it means that the ECU has passed the verification.

In a possible design, the method further includes: sending second verification information to the vehicle key management device, wherein the second verification information is the use of the first ECU key to perform the first information and the second information. Information generated after encryption.

That is, the ECU needs to authenticate the sender (vehicle management device) before executing the update of the ECU key, so the second authentication information can be generated using the existing ECU key (the first ECU key), and send it to the sender.

In a possible design, the method further includes: receiving third verification information from the vehicle key management device.

After passing the above verification operation, the ECU may receive the third verification information.

In a possible design, the method further includes: performing a decryption operation on the third verification information by using the first ECU key to obtain the decrypted third verification information.

In implementation, a new ECU key can be decrypted using the existing ECU key.

In a possible design, the method further includes: when it is determined that the decrypted third verification information includes the second information, updating the first ECU key to the first ECU key included in the decrypted third verification information 2. ECU key.

After passing the verification, the key update operation of the ECU can be performed.

In a fifth aspect, an embodiment of the present application provides a vehicle key management device, including: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to implement the first step when executing the instructions Any method of the second aspect to the fourth aspect.

In a sixth aspect, embodiments of the present application provide a non-volatile computer-readable storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, implement any of the second to fourth aspects. a method.

In a seventh aspect, embodiments of the present application provide a computer program product, which is characterized by comprising computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are When the code is run in the processor of the electronic device, the processor in the electronic device executes any of the methods of the second to fourth aspects.

In an eighth aspect, an embodiment of the present application provides a vehicle key management device, the vehicle key management device includes a communication module for receiving a vehicle key corresponding to the vehicle from an off-vehicle key management device; a master key A key generation module is used for generating a master key uniquely corresponding to the vehicle by using the vehicle key.

In a possible design, the device may further include: a determination module, configured to use the master key to determine the first ECU key corresponding to the electronic control unit ECU in the vehicle.

In a possible design, the communication module is further configured to send the first ECU key to the ECU.

In a possible design, the communication module is further configured to send a second ECU key to the ECU, where the second ECU key is a key generated after updating the first ECU key.

In a possible design, the communication module further sends first verification information to the ECU before sending the second ECU key to the ECU, wherein the first verification information is to use the first ECU key to verify the first verification information. Information generated by encrypting a message.

In a possible design, the communication module is further configured to receive second verification information from the ECU.

In a possible design, the device further includes: a decryption module, configured to perform a decryption operation on the second verification information by using the first ECU key to obtain the decrypted second verification information.

In a possible design, the device further includes: a third verification information generation module, configured to use the first ECU key to pair the decrypted second verification information with the first ECU key when it is determined that the decrypted second verification information includes the first information. The second verification information and the second ECU key are encrypted to generate the third verification information.

In a possible design, the communication module is further configured to send third verification information to the ECU.

In a possible design, the determining module is specifically configured to use a triplet composed of the master key, the key version information of the ECU key, and the identification information of the ECU as the first ECU key .

In a possible design, the master key generation module is specifically configured to use a triplet composed of the vehicle key, the key version information of the master key, and the identification information of the vehicle as the The vehicle's master key.

In a ninth aspect, an embodiment of the present application provides a vehicle key management device, the vehicle key management device includes a determination module for determining a vehicle attribute node of the vehicle in a vehicle attribute structure; a parent key acquisition module, is used to obtain the parent key corresponding to the vehicle by using the vehicle attribute node; a vehicle key generation module is used to generate the vehicle by using the parent key and the vehicle attribute information corresponding to the vehicle attribute node The vehicle key; a communication module for sending the vehicle key to the vehicle, wherein the vehicle key can be used by a vehicle key management device to generate a uniquely corresponding master key for the vehicle.

In a possible design, the device further includes: a vehicle attribute structure generation module, configured to generate the vehicle attribute structure according to the vehicle attributes according to the parent-child relationship, wherein the vehicle attribute structure includes a plurality of vehicle attribute nodes, located in The upper node of the vehicle attribute node indicates the parent attribute node of the vehicle attribute node; a vehicle key structure that is structurally identical to the vehicle attribute structure is generated, wherein the vehicle key structure includes a plurality of vehicle key structures. key node, the upper key located at the vehicle key node indicates the parent key of the vehicle key node.

In a possible design, the parent key acquisition module is specifically configured to use the vehicle attribute node to determine the node position of the vehicle attribute node in the vehicle attribute structure; use the node position to determine the vehicle attribute the vehicle key node in the vehicle key structure; obtain the parent key of the vehicle key node.

In a tenth aspect, an embodiment of the present application provides a vehicle key management device, the vehicle management device comprising: a communication module configured to receive a first ECU key from the vehicle key management device, wherein the first ECU key is The vehicle key management device generates a master key uniquely corresponding to the vehicle using a vehicle key of the vehicle, the vehicle key being a key received from an off-vehicle management device.

In a possible design, the communication module is further configured to receive first verification information from the vehicle key management device.

In a possible design, the device further includes: a first information acquisition module, configured to perform a decryption operation on the first verification information by using the first ECU key to acquire the first information.

In a possible design, the communication module is further configured to send second verification information to the vehicle key management device, wherein the second verification information is a pair of the first information and the second information using the first ECU key Information generated after encryption.

In a possible design, the communication module is further configured to receive third verification information from the vehicle key management device.

In a possible design, the device further includes: a third verification information obtaining module, configured to perform a decryption operation on the third verification information by using the first ECU key to obtain the decrypted third verification information.

In a possible design, the device further includes: an update module configured to update the first ECU key to the decrypted third verification information under the condition that it is determined that the decrypted third verification information includes the second information The second ECU key included in the message.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features and aspects of the application and together with the description, serve to explain the principles of the application.

FIG. 1 shows a diagram of a vehicle key management system according to an embodiment of the present application;

FIG. 2 shows an operation diagram of a vehicle key management system according to an embodiment of the present application;

FIG. 3 shows a flow chart of steps of a vehicle key management system according to an embodiment of the present application;

FIG. 4 shows a diagram of a vehicle attribute structure 400 according to an embodiment of the present application;

FIG. 5 shows a diagram of a vehicle attribute structure 500 according to an embodiment of the present application;

FIG. 6 shows a diagram of generating a vehicle key according to an embodiment of the present application;

FIG. 7 shows a diagram of generating a master key according to an embodiment of the present application;

FIG. 8 shows a diagram of generating an ECU key according to an embodiment of the present application;

FIG. 9 shows a flowchart of updating an ECU key according to an embodiment of the present application;

FIG. 10 shows a diagram of an electronic device according to an embodiment of the present application.

Detailed ways

Various exemplary embodiments, features and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numbers in the figures denote elements that have the same or similar functions. While various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

In this embodiment of the present application, "/" may indicate that the objects associated before and after are an "or" relationship, for example, A/B may indicate A or B; "and/or" may be used to describe that there are three types of associated objects A relationship, for example, A and/or B, can mean that A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In order to facilitate the description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" may be used to distinguish technical features with the same or similar functions. The words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit the difference. In the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations or illustrations, and any embodiment or design solution described as "exemplary" or "for example" should not be construed are preferred or advantageous over other embodiments or designs. The use of words such as "exemplary" or "such as" is intended to present the relevant concepts in a specific manner to facilitate understanding.

In addition, in order to better illustrate the present application, numerous specific details are given in the following detailed description. It should be understood by those skilled in the art that the present application may be practiced without certain specific details. In some instances, methods, means, components and circuits well known to those skilled in the art have not been described in detail so as not to obscure the subject matter of the present application.

In the field of Internet of Vehicles, the vehicle key is applied inside the vehicle and outside the vehicle, wherein the application inside the vehicle may include a single electronic control unit (Electronic Control Unit, ECU) applied in the vehicle and/or multiple ECUs in the vehicle. When applied to a single ECU, the vehicle key can be applied to safely start the ECU, flash the ECU (also known as data filling), protect configuration files, protect software/hardware IP, etc. time), the vehicle key can be applied to identity authentication, secure communication, etc. between multiple ECUs.

The vehicle key can also be applied outside the vehicle. The application of the vehicle key to the outside of the vehicle may include identity authentication applied to the vehicle, access control, and performing various communications with external devices (eg, other vehicles) (including but not limited to wireless communications, wired communications, API interface access, V2X communication, human-computer interaction, etc.) and remote services, such as remote control and commands, subscription fee-based services, etc.

In an implementation, an original equipment manufacturer (OEM) key management system (KMS) may be a system composed of multiple computing devices in a preset manner (eg, distributed). As an example, an OEM KMS may indicate a company that manufactures parts or even entire equipment for a branded product, and in the case of a vehicle, an OEM KMS may indicate the original equipment manufacturer of the vehicle brand. In implementation, the OEM KMS can generate and distribute vehicle keys for individual vehicles according to the existing key generation methods.

For vehicles for which the OEM KMS is responsible, the OEM KMS can generate and distribute the corresponding vehicle key for each model. In addition, the OEM KMS can generate the same or different vehicle keys for different car models, for example, the OEM KMS can assign the same vehicle key to each vehicle belonging to the same model.

In implementation, the OEM KMS can centrally manage the vehicle keys, including the generation, distribution, update and/or cancellation (obsolete) of the vehicle keys. As an example, the OEM KMS can provide the production vehicle It can be seen that OEM KMS needs to manage a large number of vehicle keys, so it needs to More complex hardware support.

In addition, the existing vehicle key management system is based on a vehicle, that is to say, a vehicle determines and uses a vehicle key, which makes each ECU in the vehicle share the same vehicle key. After the used vehicle key is cracked, the vehicle key of the entire vehicle can be obtained, and the security is relatively low, which is not conducive to the expansion of new security services.

In order to solve the above technical problems, the present application provides a new vehicle key management system. This will be described in detail below with reference to FIGS. 1 to 7 . As shown in FIG. 1, the vehicle key management system may include an off-vehicle KMS 100 and vehicle KMS 101 and KMS 102. The off-vehicle KMS 101 indicates an OEM KMS outside the vehicle, that is, in order to assist the vehicle in generating the corresponding vehicle key The external device is referred to as the off-vehicle KMS 100, and in implementation, it may also be referred to as an external KMS or the like. Any one of the off-vehicle KMS 100, the vehicle KMS 101, or the vehicle KMS 102 indicates a device that generates and manages vehicle keys, which can indicate a single hardware device, or a hardware cluster for realizing the above functions, or a chip system. In the embodiments of the present application, the chip system may be composed of chips, or may include chips and other discrete devices. Vehicle KMS is an internal device for each vehicle to generate its own vehicle key. As shown in FIG. 1 , the vehicle 110 corresponds to the vehicle KMS 101 , and the vehicle 120 corresponds to the vehicle KMS 102 .

As an example, the vehicle key management system in FIG. 1 includes only two

vehicles

110 and 120 , and each vehicle includes corresponding

vehicle KMSs

101 and 102 inside. However, in implementation, the key management system may correspond to more vehicles, that is, the OEM KMS 100 may cooperate with more vehicle KMSs to provide vehicle keys for more vehicles.

In an implementation, the off-board KMS 100 may correspond to multiple vehicle KMSs including the vehicle KMS 101 and KMS 102, that is, the off-board KMS 101 may provide vehicle keys to multiple KMSs (not limited to KMS 101 and KMS 102) .

As shown in FIG. 2 , the off-vehicle KMS may indicate the OEM KMS, and the vehicle KMS 210 and the vehicle KMS 220 may respectively correspond to different vehicles. In order to reduce the burden of the OEM KMS 200, the OEM KMS 200 can firstly stratify vehicles according to vehicle attributes, obtain the vehicle attribute structure, and then use the vehicle attribute structure to determine the vehicle key structure. When the vehicle key structure has been determined, use the parent key of the upper level to determine the child key of the current level, and then use the child key of the current level to generate the parent key of the next level, that is, by layer by layer The generation method is to generate a corresponding vehicle key for each vehicle, and the vehicle attribute structure and the vehicle key structure will be described in detail below with reference to FIG. 4 and FIG. 5 .

On this basis, in order to ensure the uniqueness of the vehicle key of each vehicle, the vehicle KMS 210 or the vehicle KMS 220 can be involved, that is, the vehicle's KMS 200 and the vehicle KMS 210 or the vehicle KMS 220 jointly generate the vehicle's KMS 200. master key. As shown in FIG. 2 , after generating the vehicle key of each vehicle, the OEM KMS 200 can send each vehicle key to the vehicle KMS of the vehicle (KMS 210 and KMS 220 in FIG. 2 ). Subsequently, the vehicle KMS 210 and/or the vehicle KMS 220 respectively generate the master key of the respective vehicle according to the obtained vehicle key, thereby realizing one key per vehicle. Further, the vehicle KMS 210 and/or the vehicle KMS 220 can use the respective master keys to generate the ECU keys of each ECU in the vehicle (for example, ECU 211, ECU 221), and send each ECU 211 or ECU 221 in the vehicle to each ECU 211 or ECU 221. Distribute and update the corresponding ECU key, thereby realizing one key.

For ease of understanding, an embodiment in which the external KMS and the vehicle KMS cooperate to generate the master key of the vehicle and use the master key to generate each ECU key will be described in detail below with reference to FIG. 3 . The description of FIG. 3 is described from the perspective of a single vehicle, that is, the embodiment of generating the vehicle key of the vehicle is described from the perspective of a single vehicle. Therefore, the off-vehicle KMS 301 shown in FIG. 3 indicates a KMS outside the vehicle. In an implementation, the off-board KMS 301 may be an OEM KMS, that is, a vehicle key management system that manages vehicle keys for all vehicles. In addition, the off-vehicle KMS 301 may also be an intermediate processing plant, for example, the off-vehicle KMS 301 may be a computing node of the processing plant responsible for generating the vehicle key.

The vehicle KMS 302 refers to the vehicle KMS inside the vehicle, which will be described below with the vehicle KMS 302 . In implementation, the off-vehicle KMS 301 may also cooperate with the vehicle KMS other than the vehicle KMS 302 to generate more vehicle keys for more vehicles, which will not be discussed here.

In step S310, the off-vehicle KMS 301 may determine the vehicle key structure by using the vehicle attribute structure, wherein the vehicle attribute structure refers to a structure diagram generated by layering the vehicle by using the vehicle attribute of the vehicle. In an implementation, the vehicle attribute structure may be a tree structure.

In the following description, the description will be made under the assumption that the vehicle attribute structure is a tree structure, but in practice, the vehicle attribute structure may also adopt other structures that can layer vehicles. The vehicle attribute structure 400 shown in FIG. 4 is an abstract structure with hierarchical data, and each element in the vehicle attribute structure 400 may be referred to as a vehicle attribute node, for example, a vehicle attribute node 411, a vehicle attribute node 421, a vehicle attribute Node 431 etc. For ease of description, these nodes may be named individually according to their location information, for example, the vehicle attribute node 411 is located at the top of the vehicle attribute structure 400 and may be referred to as the root vehicle attribute node, and the vehicle attribute node 431 is located at the bottom of the vehicle attribute structure 400 , can be called a leaf vehicle attribute node, the vehicle attribute node 411 is located in the upper layer of the vehicle attribute node 421, and can be called the parent attribute node of the vehicle attribute node 421, meanwhile, the vehicle attribute node 421 can be called the vehicle attribute node 411 The child property node of . The positions of these nodes depend on the attribution relationship of vehicle attributes. In addition, in the vehicle attribute structure 400, any two nodes are connected by only one path, for example, the vehicle attribute node 411 to the vehicle attribute node 431 has and only There is a path, that is, the path from the vehicle attribute node 411 to the vehicle attribute node 431 through the vehicle attribute node 421 .

As shown in FIG. 4 , there are multiple nodes with parent-child relationship in the vehicle attribute structure, and these nodes are the parent-child relationship determined by using the vehicle attribute. Therefore, the vehicle attribute determined as the parent attribute node can be called As the parent attribute, and the vehicle attribute determined as the child attribute node is called the child attribute. For example, a 1.4-liter vehicle is a child of a small vehicle, and a small car is a parent of a 1.4-liter vehicle. In short, the vehicle attribute structure includes parent attributes as parent attribute nodes and child attributes as child attribute nodes.

The root node 411 may indicate an OEM KMS, which may be a key management system used by a vehicle manufacturer of a certain vehicle brand. In implementation, the OEM KMS can divide the vehicles it manages into the vehicle attribute structure shown in FIG. 4 according to the vehicle attributes. For example, if the OEM KMS is a vehicle The vehicle attributes are divided into the vehicle attribute structure shown in FIG. 4 . The vehicle attributes may include vehicle model, vehicle family, powertrain, color, and/or vehicle configuration. In an implementation, a combination of one or more of the vehicle attributes may be used to generate a vehicle attribute structure as shown in FIG. 4 .

As another example, vehicles may be classified into miniature cars, small cars, compact cars, mid-sized cars, medium-sized cars, and large-sized cars according to their vehicle types. These vehicle models may correspond to the parent attribute node 421, the parent attribute node 422, and the parent attribute node 42m in FIG. 4, respectively. Finally, each vehicle corresponds to each sub-level attribute node 431 to sub-level attribute node 43n according to the vehicle type to which each vehicle belongs. For example, a certain vehicle may correspond to child attribute node 431 .

As shown in FIG. 5, corresponding to the vehicle attribute structure 400, a vehicle key structure 500 may be generated. Each element in the vehicle key structure 500 may be referred to as a vehicle key node, eg, vehicle key node 511, vehicle key node 521, vehicle key node 531, and the like. Vehicle keys in the vehicle key structure 500 at the same position as the vehicle attribute structure 400 correspond to vehicle attributes. For example, the vehicle on the vehicle attribute node 431 has the vehicle key on the vehicle key node 531 .

In the vehicle key structure 500, each vehicle key node is associated with the parent key of the parent node, that is, the next level of vehicle key nodes can be generated using the parent key. As an example, as shown in FIG. 5 , a parent key 521 may be generated from the root key 511 , and a child key 531 may be generated from the parent key 521 . It should be noted that each vehicle attribute node may correspond to vehicle attributes of one or more vehicles, therefore, each vehicle key node may also correspond to vehicle keys of one or more vehicles, which is not limited in this application.

In the case that the off-vehicle KMS 301 corresponds to the OEM KMS, step S310 can be executed to determine the vehicle attribute structure. Then, a corresponding vehicle key structure is determined using the vehicle attribute structure. When the off-board KMS 301 does not correspond to the OEM KMS, for example, when the off-board KMS 301 corresponds to an intermediate manufacturer's KMS, the off-board KMS 301 may perform step S320, that is, the off-board KMS 301 uses the The vehicle attribute node obtains the parent key corresponding to the vehicle.

In an implementation, the off-board KMS 301 may obtain the parent key from the KMS of its parent attribute node. In an implementation, the off-vehicle KMS 301 may determine the node position of the vehicle attribute node in the vehicle attribute structure. Then, using the node location, the vehicle key node of the vehicle in the vehicle key structure is determined; the parent key of the vehicle key node is obtained.

As an example, the off-vehicle KMS 301 may determine the node position of the vehicle attribute node 431 in the vehicle attribute structure. Then, according to the node position, the vehicle key node 531 of the vehicle in the vehicle attribute structure 500 is determined. At this time, in order to obtain the vehicle key corresponding to the vehicle key node 531, the parent key 521 of the vehicle key node 531 needs to be obtained.

In step S330, the off-vehicle KMS 301 uses the parent key and the vehicle attribute information corresponding to the vehicle attribute node to generate the vehicle key of the vehicle. In implementation, in order to reflect the uniqueness of the vehicle at the attribute level, the off-vehicle KMS 301 may use the parent key and the vehicle attribute of the vehicle at the current level (ie, the vehicle attribute corresponding to the The vehicle key for the vehicle.

A diagram of generating a vehicle key according to an embodiment of the present application will be specifically described below with reference to FIG. 6 . As shown in FIG. 6 , the vehicle key can be generated using the acquired parent key and the vehicle attributes of the vehicle at the current level. As an example, a two-tuple may be generated using vehicle attributes and a parent key, for example, (vehicle attribute, parent key) or (parent key, vehicle attribute). In the process of generating the two-tuple, the method may pre- Sets the position of each element in this 2-tuple.

Then, encryption is performed on the two-tuple using a key generation algorithm to generate a vehicle key. In implementation, the key length of the output vehicle key and the output key format can be preset, for example, the key format can be determined as "Sub Root Key:", and the output vehicle key can be determined. The key is a 32-bit string. In addition, the key generation algorithm may be a common key generation algorithm in the related art, for example, the key generation algorithm may be a Data Encryption Standard (Data Encryption Standard, DES) algorithm, an RSA algorithm, and the like.

As an example, for the subsequent update operation, as shown in FIG. 6, the key version information may be involved in generating the vehicle key. That is, a corresponding triplet (key version information, vehicle attribute, parent key) can be generated using the key version information, the vehicle attribute, and the parent key. It should be noted that the order of each element within the triplet may be in a predetermined order. Finally, the triplet is encrypted using the key generation algorithm to generate a vehicle key.

In implementation, if the node corresponding to the off-vehicle KMS 301 also has a child attribute node, the vehicle key generated by the off-vehicle KMS 301 is used as the parent key, and the vehicle attribute of the child attribute node and the parent key are used according to In the manner shown in FIG. 6 , the vehicle key for the child-level attribute node is generated until the node corresponding to the KMS 301 outside the vehicle is the leaf-level attribute node.

In step S340, the vehicle key is sent to the vehicle KMS 302.

After receiving the vehicle key, the vehicle KMS 302 uses the vehicle key to generate a master key uniquely corresponding to the vehicle in step S350. The process of generating the master key will be exemplarily explained below with reference to FIG. 7 .

In order to generate the master key corresponding to the vehicle, after the vehicle key is obtained, the master key of the vehicle may be jointly generated in combination with the identification information of the vehicle. That is, the master key is at least related to the identification information of the vehicle. The identification information refers to information that can uniquely identify the vehicle. In implementation, the identification information may be a unique identification assigned to the vehicle by the manufacturer during the manufacture of the vehicle. As an example, the identification information may also include but is not limited to a vehicle identification number (Vehicle Identification Number, VIN), Equivalent to the "identity card" of the vehicle in question.

As shown in FIG. 7 , the master key can be generated using the acquired vehicle key and identification information of the vehicle. As an example, the identification information and the vehicle key may be used to generate a two-tuple, for example, (identification information, vehicle key) or (vehicle key, identification information), and in the process of generating the two-tuple, the method may pre- Sets the position of each element in this 2-tuple.

Then, encryption is performed on the two-tuple using a key generation algorithm to generate a master key. In implementation, the key length of the output master key and the output key format can be preset, for example, the key format can be determined to be "MasterKey:", and the key of the output master key can be determined is a 32-bit string. In addition, the key generation algorithm may be a common key generation algorithm in the related art, for example, the key generation algorithm may be a Data Encryption Standard (Data Encryption Standard, DES) algorithm, an RSA algorithm, and the like.

As an example, for the subsequent update operation, as shown in FIG. 7 , the key version information may be involved in generating the master key. That is to say, a corresponding triple (key version information, identification information, vehicle key) can be generated by using the key version information, the identification information and the vehicle key. It should be noted that each element in the triple The order can follow the preset order. Finally, the triplet is encrypted using the key generation algorithm to generate a master key.

To sum up, the vehicle KMS 302 and the off-vehicle KMS 301 jointly generate the master key of the vehicle, thereby reducing the device pressure of using only the parking key management device. Further, in the case of using the off-vehicle KMS 301 and the vehicle KMS 302 to generate vehicle keys for multiple vehicles, the vehicle KMS 302 uses the vehicle key management device to generate a unique master key for the vehicle according to the vehicle key. This ensures the uniqueness of the master key and improves security while reducing the pressure on off-vehicle key management devices.

In the case that the master key of the vehicle has been generated, the vehicle KMS 302 may also perform step S360, and use the master key to determine the ECU key of the ECU. The process of generating the ECU key of the ECU will be exemplarily explained below with reference to FIG. 8 .

Multiple ECUs are included inside the vehicle, for example, the vehicle interior includes telematics box, keyless entry and start (passive entry passive start, PEPS), etc. In order to improve security, different ECUs can be assigned different ECU key.

As shown in FIG. 8 , for a single ECU, the vehicle KMS 302 can use the master key and the identification information of the ECU to generate the ECU key, wherein the identification information of the ECU is the unique identification information set for the ECU before leaving the factory .

As an example, the identification information of the ECU and the master key can be used to generate a two-tuple, for example, (the identification information of the ECU, the master key) or (the master key, the identification information of the ECU), in the process of generating the two-tuple , the method can preset the position of each element in the binary.

Then, encryption is performed on the two-tuple using a key generation algorithm to generate a master key. In implementation, the key length of the output ECU key and the output key format can be preset, for example, the key format can be determined to be "ECUKey:", and the key of the output ECU key can be determined is a 32-bit string. In addition, the key generation algorithm may be a common key generation algorithm in the related art, for example, the key generation algorithm may be a Data Encryption Standard (Data Encryption Standard, DES) algorithm, an RSA algorithm, and the like.

As an example, for the subsequent update operation, as shown in FIG. 8 , the key version information can be involved in generating the ECU key. That is to say, the corresponding triplet (key version information, ECU identification information, master key) can be generated by using the key version information, the identification information and the vehicle key. It should be noted that each The order of the elements can be in a preset order. Finally, the triplet is encrypted using the key generation algorithm to generate an ECU key.

Finally, in step S370, the vehicle KMS 302 may distribute the corresponding ECU key to each ECU inside the vehicle.

According to the above description, the key generation algorithm is used in the process of generating the vehicle key, the master key and the ECU key, but the key generation algorithm used in the above process may be the same or different. There is no restriction on the application.

To sum up, the method can realize one key per ECU by using the master key in the vehicle KMS 302 under the condition of realizing one key for one vehicle, thereby improving the security between each ECU. As an example, when the vehicle needs to add and/or replace a new ECU, the vehicle KMS 302 can generate the ECU key of the new ECU according to the master key and the identification information of the new ECU.

The vehicle key management method of the exemplary embodiment of the present application also involves updating each ECU key inside the vehicle, and the process of updating the ECU key will be described below with reference to FIG. 9 . For ease of description, the ECU key generated for the ECU in FIG. 3 is referred to as the first ECU key, and the key obtained after updating the first ECU key is referred to as the second ECU key. As an example, the second ECU key may be generated by updating the version information in the above-mentioned triplet. In addition, the vehicle KMS 901 can generate and manage ECU keys for multiple ECUs, which will be described below for a single ECU.

In the process of updating the first ECU key of the ECU 902 to the second ECU key, the vehicle KMS 901 and the ECU 902 need to be verified respectively. Only after passing the verification, the existing ECU key of the ECU 902 can be updated to The new ECU key, in the process, as long as the verification fails, the operation is terminated, as follows:

In step S9010, the vehicle KMS 901 may generate first verification information, wherein the first verification information is information generated after encrypting the first information with the first ECU key, wherein the first information may be randomly generated The random number may also be specific information set according to user requirements, which is not limited in this application.

In step S9020, the vehicle KMS 901 sends the first verification information to the ECU 902.

After receiving the first verification information, the ECU 902 performs the verification operation. Specifically, in step S9030, the ECU 902 decrypts the first verification information, and if the decryption is successful, the verification is passed. In implementation, the first verification information can be decrypted only when the ECU key stored in the ECU 902 is the first ECU key. In step S9030, the ECU 902 decrypts the first verification information using the first ECU key to obtain the first information.

After acquiring the first information, the ECU 902 can perform step S9040 to generate the second verification information. Specifically, the ECU 902 can generate the second information, wherein the second information can be a random number generated randomly, or it can be a random number generated according to the user The specific information required to be set is not limited in this application. Subsequently, the ECU 902 may encrypt the first information and the second information using the first ECU key to generate the second verification information.

In step S9050, the ECU 902 may transmit the second verification information to the vehicle KMS 901.

In step S9060, after receiving the second verification information, the vehicle KMS 901 can use the first ECU key to decrypt the second verification information, and determine that the decrypted second verification information includes the first information. If there is no information, it is determined that the verification is successful.

If the verification is successful, in step S9070, the vehicle KMS 901 encrypts the first information, the second information and the second ECU key by using the first ECU key to generate third verification information.

In step S9080, the vehicle KMS 901 sends the third verification information to the ECU 902.

In step S9090, the ECU 902 decrypts the third verification information by using the first ECU key. If the decryption is successful, it proves that the verification is passed, and after the decryption is successful, the first information, the second information and the second ECU key are obtained. .

In step S9100, the ECU 902 may update the first ECU key to the second ECU key.

To sum up, before each ECU according to the exemplary embodiment of the present application performs the update of the ECU key, the ECU may first verify the vehicle KMS that initiates the data update process, and after the verification is passed, the vehicle KMS may The ECUs that update the data are verified, and after the verifications are passed, the updated ECU keys are transmitted to the ECUs in a mutually verifiable manner, thereby ensuring the authenticity of the data and the security of communication.

In addition, the electronic device of the exemplary embodiment of the present application may have a structure as shown in FIG. 10 , wherein the vehicle key management device may perform the functions performed by the off-vehicle KMS 301 in FIG. The functions performed by the vehicle KMS 301 and the vehicle KMS 901 in FIG. 9 , or the functions performed by the ECU 902 in FIG. 9 .

As shown in FIG. 10 , the electronic device may include a processing module 1010 and a communication module 1020 .

As an example, when the electronic device is used to implement the function performed by the off-vehicle KMS 301, the processing module 1010 may determine the vehicle attribute node of the vehicle in the vehicle attribute structure; using the vehicle attribute node, Obtain the parent key corresponding to the vehicle; and generate the vehicle key of the vehicle by using the parent key and the vehicle attribute information corresponding to the vehicle attribute node.

The communication module 1020 may be configured to send the vehicle key to the vehicle, wherein the vehicle key can be used by a vehicle key management device to generate a master key uniquely corresponding to the vehicle.

As an example, in the case where the electronic device is used to implement the function performed by the vehicle KMS 301, the communication module 1020 may be configured to receive a vehicle key corresponding to the vehicle from an off-vehicle key management device. The processing module 1010 may be configured to use the vehicle key to generate a master key uniquely corresponding to the vehicle.

As an example, where the electronic device is used to implement the functions performed by the ECU 902 in FIG. 9 , the communication module 1010 may receive a first ECU key from a vehicle key management device, wherein the first ECU key is the master key uniquely corresponding to the vehicle generated by the vehicle key management device using the vehicle key of the vehicle, the vehicle key being the key received from the outside vehicle management device.

Embodiments of the present application provide a vehicle key management device, comprising: a processor and a memory for storing instructions executable by the processor; wherein the processor is configured to implement the above method when executing the instructions.

Embodiments of the present application provide a non-volatile computer-readable storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, implement the above method.

Embodiments of the present application provide a computer program product, including computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are stored in a processor of an electronic device When running in the electronic device, the processor in the electronic device executes the above method.

A computer-readable storage medium may be a tangible device that can hold and store instructions for use by the instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (Electrically Programmable Read-Only-Memory, EPROM or flash memory), static random access memory (Static Random-Access Memory, SRAM), portable compact disk read-only memory (Compact Disc Read-Only Memory, CD - ROM), Digital Video Disc (DVD), memory sticks, floppy disks, mechanically encoded devices, such as punch cards or raised structures in grooves on which instructions are stored, and any suitable combination of the foregoing .

Computer readable program instructions or code described herein may be downloaded to various computing/processing devices from a computer readable storage medium, or to an external computer or external storage device over a network such as the Internet, a local area network, a wide area network and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from a network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing/processing device .

The computer program instructions used to perform the operations of the present application may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or in one or more source or object code written in any combination of programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server implement. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or, may be connected to an external computer (eg, use an internet service provider to connect via the internet). In some embodiments, electronic circuits, such as programmable logic circuits, Field-Programmable Gate Arrays (FPGA), or Programmable Logic Arrays (Programmable Logic Arrays), are personalized by utilizing state information of computer-readable program instructions. Logic Array, PLA), the electronic circuit can execute computer readable program instructions to implement various aspects of the present application.

Aspects of the present application are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present application. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer or other programmable data processing apparatus to produce a machine that causes the instructions when executed by the processor of the computer or other programmable data processing apparatus , resulting in means for implementing the functions/acts specified in one or more blocks of the flowchart and/or block diagrams. These computer readable program instructions can also be stored in a computer readable storage medium, these instructions cause a computer, programmable data processing apparatus and/or other equipment to operate in a specific manner, so that the computer readable medium on which the instructions are stored includes An article of manufacture comprising instructions for implementing various aspects of the functions/acts specified in one or more blocks of the flowchart and/or block diagrams.

Computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other equipment to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other equipment to produce a computer-implemented process , thereby causing instructions executing on a computer, other programmable data processing apparatus, or other device to implement the functions/acts specified in one or more blocks of the flowcharts and/or block diagrams.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more functions for implementing the specified logical function(s) executable instructions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

It is also noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented in hardware (eg, circuits or ASICs (Application) that perform the corresponding functions or actions. Specific Integrated Circuit, application-specific integrated circuit)), or can be implemented by a combination of hardware and software, such as firmware.

While the invention has been described herein in connection with various embodiments, those skilled in the art will understand and understand from a review of the drawings, the disclosure, and the appended claims in practicing the claimed invention. Other variations of the disclosed embodiments are implemented. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that these measures cannot be combined to advantage.

Various embodiments of the present application have been described above, and the foregoing descriptions are exemplary, not exhaustive, and not limiting of the disclosed embodiments. Numerous modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the various embodiments, the practical application or improvement over the technology in the marketplace, or to enable others of ordinary skill in the art to understand the various embodiments disclosed herein.

Claims

A vehicle key management system, comprising:

an off-vehicle key management device for generating a vehicle key of the vehicle, wherein the vehicle key corresponds to a plurality of vehicles; sending the vehicle key to the vehicle key management device,

The vehicle key management device is used for receiving the vehicle key from the off-vehicle key management device; and using the vehicle key, a master key uniquely corresponding to the vehicle is generated.
A vehicle key management method, comprising:

receiving a vehicle key corresponding to the vehicle from an off-vehicle key management device;

Using the vehicle key, a master key uniquely corresponding to the vehicle is generated.
The method of claim 2, further comprising:

Using the master key, the first ECU key corresponding to the electronic control unit ECU in the vehicle is determined.
The method of claim 3, further comprising:

A first ECU key is sent to the ECU.
The method of claim 4, further comprising:

A second ECU key is sent to the ECU, wherein the second ECU key is a key generated after updating the first ECU key.
The method of claim 5, before sending the second ECU key to the ECU, further comprising:

Sending first verification information to the ECU, where the first verification information is information generated after encrypting the first information with a first ECU key.
The method of claim 6, further comprising:

Second verification information is received from the ECU.
The method of claim 7, further comprising:

The second verification information is decrypted by using the first ECU key to obtain the decrypted second verification information.
The method of claim 8, further comprising:

When it is determined that the decrypted second verification information includes the first information, an encryption operation is performed on the decrypted second verification information and the second ECU key using the first ECU key to generate third verification information.
The method of claim 9, further comprising:

Send third verification information to the ECU.
The method of claim 3, wherein the first ECU key is at least related to the master key and identification information of the first ECU.
The method of claim 11, wherein the first ECU key is related to the master key, key version information of the first ECU key, and identification information of the first ECU.
The method of claim 12, wherein using the master key to determine the first ECU key corresponding to an electronic control unit (ECU) in the vehicle comprises:

A triplet composed of the master key, the key version information of the ECU key, and the identification information of the ECU is used as the first ECU key.
The method of claim 2, wherein the master key is at least related to the identification information of the vehicle in the vehicle key.
15. The method of claim 14, wherein the master key is associated with the vehicle key, key version information of the master key, and identification information of the vehicle.
The method of claim 15, wherein using the vehicle key to generate a master key uniquely corresponding to the vehicle, comprising:

A triplet composed of the vehicle key, the key version information of the master key, and the identification information of the vehicle is used as the master key of the vehicle.
A vehicle key management method, comprising:

determining the vehicle attribute node of the vehicle in the vehicle attribute structure;

Using the vehicle attribute node, obtain the parent key corresponding to the vehicle;

generating the vehicle key of the vehicle by using the parent key and the vehicle attribute information corresponding to the vehicle attribute node;

The vehicle key is sent to the vehicle, wherein the vehicle key can be used by a vehicle key management device to generate a uniquely corresponding master key for the vehicle.
The method of claim 17, wherein the vehicle key is further related to version information of the vehicle key.
The method of claim 17, further comprising:

The vehicle attribute structure is generated according to the parent-child relationship, wherein the vehicle attribute structure includes a plurality of vehicle attribute nodes, and the upper node located in the vehicle attribute node indicates the parent attribute node of the vehicle attribute node;

generating a vehicle key structure that is structurally identical to the vehicle attribute structure, wherein the vehicle key structure includes a plurality of vehicle key nodes, an upper key located at the vehicle key node indicating the vehicle key The node's parent key.
The method of claim 19, wherein obtaining the parent key corresponding to the vehicle by using the vehicle attribute node comprises:

determining the node position of the vehicle attribute node in the vehicle attribute structure;

using the node location, determining a vehicle key node of the vehicle in the vehicle key structure;

Get the parent key of the vehicle key node.
A vehicle key management method, comprising:

A first ECU key is received from a vehicle key management device, wherein the first ECU key is a master key uniquely corresponding to the vehicle generated by the vehicle key management device using the vehicle key of the vehicle, so The vehicle key is a key received from an off-vehicle management device.
21. The method of claim 21, wherein the first ECU key is related to a master key, key version information of the first ECU key, and identification information of the first ECU.
The method of claim 22, further comprising:

First verification information is received from the vehicle key management device.
The method of claim 23, further comprising:

The first verification information is decrypted by using the first ECU key to obtain the first information.
The method of claim 24, further comprising:

Sending second verification information to the vehicle key management device, wherein the second verification information is information generated by encrypting the first information and the second information with the first ECU key.
The method of claim 25, further comprising:

Third verification information is received from the vehicle key management device.
The method of claim 26, further comprising:

The third verification information is decrypted by using the first ECU key to obtain the decrypted third verification information.
The method of claim 27, further comprising:

When it is determined that the decrypted third verification information includes the second information, the first ECU key is updated to the second ECU key included in the decrypted third verification information.
A key generation device for a vehicle, comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor is configured to implement the method of any one of claims 2-11, the method of any one of claims 17-20, or the method of any one of claims 21-28 when executing the instructions. method described.
A non-volatile computer-readable storage medium on which computer program instructions are stored, characterized in that, when the computer program instructions are executed by a processor, the method and claims described in any one of claims 2-11 are implemented The method of any one of 17-20 or the method of any one of claims 21-28.
A computer program product, characterized by comprising computer-readable codes, or a non-volatile computer-readable storage medium carrying computer-readable codes, when the computer-readable codes are executed in a processor of an electronic device , the processor in the electronic device executes the method described in any one of claims 2-11, the method described in any one of claims 17-20, or the method described in any one of claims 21-28.