WO2022241799A1

WO2022241799A1 - Key generation method and apparatus

Info

Publication number: WO2022241799A1
Application number: PCT/CN2021/095348
Authority: WO
Inventors: 盛德; 耿峰; 殷新星
Original assignee: 华为技术有限公司
Priority date: 2021-05-21
Filing date: 2021-05-21
Publication date: 2022-11-24
Also published as: CN117378169A

Abstract

The present application discloses a key generation method and apparatus, which are applied to a vehicle, the method comprising: a first vehicle-mounted device obtains a first message, the first message being used to instruct the first vehicle-mounted device to construct a first key; and generates a first request message according to the first message, the first request message being used by a first security hardware extension unit corresponding to the first vehicle-mounted device to generate a first response message, wherein the first response message comprises: first key information, the first key information being generated after the first key is encrypted.

Description

A method and device for generating a key

technical field

The present application relates to the technical field of intelligent networked vehicles, in particular to a key generation method and device.

Background technique

At present, in the field of vehicles, the management of the basic key for communication between in-vehicle devices all depends on the key manager system in vehicle (KMS) outside the vehicle in the cloud to manage the keys of each device in the vehicle. For example, on the production line, the key is filled (that is, preset) into the secure storage area of each component through tools. All the keys needed between the various components in the car are managed in the car factory's cloud KMS.

With the evolution of vehicle intelligence, new services are gradually increasing, which will gradually require information security isolation of different communication services in the vehicle. At this time, the number of keys will gradually increase, which means that the car factory has to manage more and more key. The difficulty of management increases. In addition, from a security point of view, if the key of the business communication key between the in-vehicle devices managed by the cloud is leaked, it may immediately affect the driving safety of the vehicle.

Contents of the invention

The present application provides a key generation method and device, which are used to improve the management performance of the vehicle key and provide the security of the vehicle key.

In the first aspect, the present application provides a method for generating a key, which is applied to a vehicle, including:

The first vehicle-mounted device obtains the first message; the first message is used to instruct the first vehicle-mounted device to construct the first key; according to the first message, a first request message is generated; the first request message is used for the first key corresponding to the first vehicle-mounted device The secure hardware expansion unit generates a first response message; the first response message includes: first key information; the first key information is generated after encrypting the first key.

Through the above method, it is realized that the first on-board device of the vehicle builds a first Key, and the first key information generated after encryption by the first security hardware expansion unit is returned to the first vehicle-mounted device, so that the first vehicle-mounted device can safely generate the first key inside the vehicle without generating the first key through the cloud. The key also participates in the management of the first key throughout the whole process, which reduces the difficulty and complexity of cloud management of vehicle keys, and at the same time reduces the possibility of leaking vehicle keys through the cloud, improving the security of the first key inside the vehicle.

In a possible implementation manner, a first response message sent from the first security hardware expansion unit is received.

Through the above method, the first vehicle-mounted device can obtain the first key information through the first response message, that is, obtain the encrypted first key through the first response message, so as to ensure the security of the first key. When filling the first key, it can be verified by sending the first key information through the first vehicle-mounted equipment, and then fill the first key, so that the first key can be shared between the vehicle-mounted equipment, for example , between the first vehicle-mounted device and the second vehicle-mounted device, the security of transmission and the security of filling are performed. Thus, the security of the first key from generation to filling is ensured.

A possible implementation manner is to receive the first parameter of the first key sent by the first security hardware expansion unit; the first vehicle-mounted device generates a first key loading message according to the first parameter of the first key; the first The vehicle-mounted device sends a first key loading message to the second vehicle-mounted device; the first key loading message is used for filling the first key after the second vehicle-mounted device successfully verifies the first key loading message.

Through the above method, the first security hardware expansion unit generates the first parameter of the first key, and the first parameter may be a parameter for the second on-vehicle device to perform security verification on the first key, for example, the first key The first parameter of the key can be a parameter for integrity verification, and can also be a first parameter encrypted based on the vehicle's security verification key. Therefore, after receiving the first key loading message, the second vehicle-mounted device can upload the first key. Integrity verification is performed on the parameters of the integrity verification of the first key information. After the integrity verification is successful, the second vehicle-mounted device can decrypt the parameters encrypted based on the security verification key in the first key information to obtain the first key information. key. Thus, the security of the first key filling is ensured.

In a possible implementation, after the first vehicle-mounted device obtains the first message, the first vehicle-mounted device sends a status update message to the first security hardware expansion unit; the status update message includes: the construction status of the key in the vehicle; the status update message uses After the first security hardware extension unit successfully verifies the status update message, it updates the construction status of its own in-vehicle key.

Through the above method, the first vehicle-mounted device can determine that the in-vehicle key is in the construction state based on the first message, so it can send a status update message to the first security hardware expansion unit, so that the first security hardware expansion unit updates its own in-vehicle key. The build status of the key. For example, the build status of the in-vehicle key includes: build complete, not build, build, build failure, etc. A status update message may be used to update the build status of the in-vehicle key to being built. At this time, after receiving the status update message, the first security hardware expansion unit may update the construction status of the in-vehicle key to being under construction. Therefore, when the first security hardware expansion unit receives the first request message, it can verify the first request message based on the construction state of the in-vehicle key of the first security hardware expansion unit itself.

In a possible implementation manner, the construction state of the in-vehicle key is used by the first security hardware expansion unit to verify the first request message. For example, when the construction state of the in-vehicle key of the first security hardware expansion unit itself is under construction, if the first request message is received, the first request message may verify the integrity and integrity of the first request message in other ways. After security, generate the first key. And when the construction state of the key in the vehicle of the first safety hardware expansion unit itself is not in construction, if the first request message is received, the first safety hardware expansion unit can refuse to execute the first request message to ensure that the vehicle builds the first request message. One-key security.

A possible implementation is to send a first query request to the first security hardware extension unit after it is determined that the first vehicle-mounted device is restarted; the first query request is used to query the second parameter of the first key; and receive the first security hardware extension unit The first query response message sent by the unit; the first query response message is returned after the first security hardware expansion unit verifies the first query request; the first query response message includes: the second parameter of the first key; The second parameter of a key and the first message generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before the restart of the first vehicle-mounted device.

Through the above method, after the first vehicle-mounted device is restarted, the first vehicle-mounted device can query the first security hardware expansion unit for the current state of the first key generated by the first security hardware expansion unit, for example, whether the first key has been generated Success, the number of updates of the first key, etc. Wherein, in order to ensure the security of the first query message, the first vehicle-mounted device can encrypt and integrity protect the first query message, so that after the first security hardware extension unit receives the first query message, it can A query message is verified, for example, including decrypting and integrity verification of the first query message, and after the verification is successful, the second parameter of the first key queried by the first query request is returned to the second query message through the first query response message. A vehicle-mounted device. The first in-vehicle device may verify the first query response message, and obtain the second parameter of the first key after the verification is successful. Through the above method, it is possible to obtain the second parameter of the first key after the restart of the first vehicle-mounted device, so as to continue to execute the construction process of the first key and reduce the impact of the restart of the first vehicle-mounted device on the first key generation and loading process Impact. Wherein, in the process of verifying the first query message, the first security hardware expansion unit can also verify the first query message by querying the construction state of the vehicle key of the first security hardware expansion unit itself, so as to ensure that the first security hardware expansion unit The legal source of a query message is in the process of building the key in the vehicle, so as to ensure the security of the first query message.

A possible implementation manner is to receive a temporary key sent from the first secure hardware expansion unit; the temporary key is used to encrypt the first request message.

Through the above method, the first secure hardware expansion unit can configure a temporary key for the safe transmission of messages between the first vehicle-mounted device and the first secure hardware The first request message, considering that the temporary key is limited to the safe transmission of messages between the first vehicle-mounted device and the first security hardware expansion unit, can simplify the setting method of the temporary key, reduce the cost of the first vehicle-mounted device and the first Messages are transmitted between the safety hardware expansion units, which reduces the overhead and complexity of the first vehicle-mounted device and the first safety hardware expansion unit while improving safety.

A possible implementation manner is to receive a second message sent by the second vehicle-mounted device; the second message is used for at least one of the following: querying the second parameter of the first key, requesting the first vehicle-mounted device to generate the first key or indicating The second in-vehicle device restarts.

Through the above method, after the second vehicle-mounted device is restarted, the second vehicle-mounted device can send a second message to the first vehicle-mounted device, so that the second vehicle-mounted device can query the second parameter of the first key, and can also request the first vehicle-mounted device Generating the first key can also notify the first vehicle-mounted device to restart the second vehicle-mounted device, so that the first vehicle-mounted device can perform corresponding operations for the restart of the second vehicle-mounted device, so as to reduce the impact of the restart of the second vehicle-mounted device on the first key. For example, before the first vehicle-mounted device determines that the second vehicle-mounted device restarts, the first vehicle-mounted device has sent a loading message of the first key. At this time, the first vehicle-mounted device can , it is determined that the second vehicle-mounted device has not been successfully filled with the first key, therefore, the first vehicle-mounted device may send the loading message of the first key again, so as to fill the second vehicle-mounted device with the first key. The possibility of failure to fill the first key in the second vehicle-mounted device due to the restart of the second vehicle-mounted device is reduced, and the success rate of filling the first key in the second vehicle-mounted device is improved.

In a possible implementation manner, after the second message is verified, a third message is sent to the second vehicle-mounted device; the third message includes at least one of the following: a second parameter of the first key, and information about the first key.

Through the above method, the first vehicle-mounted device can send the third message to the second vehicle-mounted device after performing security verification on the second message, for example, after performing integrity verification on the second message based on the security verification key of the second message, The second vehicle-mounted device can obtain at least one of the second parameter of the first key or the first key information, so that after the second vehicle-mounted device is restarted, it returns to the construction state of the in-vehicle key and the first key before the restart. A key's filling status.

A possible implementation, the first message is obtained according to any of the following:

Receive the first message sent by the in-vehicle device or the out-of-vehicle device;

After receiving the initialization or update information of the configuration file, obtain the first message;

Obtain the first message after receiving the initialization or update information of the fixed key of the vehicle;

After receiving the initialization or update information of the shared key between the on-board devices of the vehicle, the first message is obtained.

Through the above method, the generation of the first key can be flexibly triggered, so that the first on-board device of the vehicle can generate the first key in various scenarios, and the applicability of key generation in the vehicle can be improved.

In a second aspect, the present application provides a method for generating a key, which is applied to a vehicle, including: the first security hardware expansion unit receives the first request message sent by the first vehicle-mounted device corresponding to the first security hardware expansion unit; the first request message For the first vehicle-mounted device to request the first security hardware expansion unit to construct the first key generation; after the first request message is successfully verified, the first key information is generated; the first key information is encrypted by the first key Generated.

Through the above method, based on the first safety hardware expansion unit of the first vehicle-mounted device, the first key is constructed for the communication of the vehicle-mounted device in the vehicle, and the first key information generated after being encrypted by the first safety hardware expansion unit is returned to the first key information A vehicle-mounted device, so that the first vehicle-mounted device can safely generate the first key inside the vehicle, without the need to generate the first key through the cloud and participate in the management of the first key throughout the process, reducing the difficulty and complexity of cloud-based vehicle key management At the same time, it avoids the possibility of leaking the vehicle key through the cloud, and improves the security of the first key inside the vehicle.

In a possible implementation manner, a first response message is sent to the first vehicle-mounted device; the first response message includes: first key information.

In a possible implementation, after the first request message is verified successfully, the first parameter of the first key is generated; the first parameter of the first key is sent to the first vehicle-mounted device; the first parameter of the first key It is used to fill the first key in the second vehicle-mounted device.

A possible implementation is to receive a status update message sent by the first vehicle-mounted device; the status update message includes: the build status of the in-vehicle key; after the status update message is successfully verified, update the build status of its own in-vehicle key.

In a possible implementation, after the first vehicle-mounted device is restarted, the first query request sent by the first vehicle-mounted device is received; the first query request is used to query the second parameter of the first key; and the first query request is verified After that, send the first query response message to the first vehicle-mounted device; the first query response message includes: the second parameter of the first key; the second parameter of the first key is used for the first vehicle-mounted device to generate the first request message; The first key is a key to be generated by the first security hardware expansion unit before restarting.

In a possible implementation manner, after the verification of the first request message is successful, a temporary key is generated; the temporary key is sent to the first vehicle-mounted device; and the temporary key is used to encrypt the first request message.

A possible implementation manner is to receive a verification message of a second message from the first vehicle-mounted device; the second message is sent by the first vehicle-mounted device to receive the second message; the second message is used for at least one of the following: querying the first The second parameter of the key requests the first vehicle-mounted device to generate the first key or instructs the second vehicle-mounted device to restart.

A possible implementation manner, after verifying the second message, send a verification response message of the second message to the first vehicle-mounted device; the response message of the second message is used for the first vehicle-mounted device to send the third message to the second vehicle-mounted device ; The third message includes at least one of the following items: the second parameter of the first key, and the first key information.

For the possible implementation manners above, reference may be made to the description of beneficial effects in the first aspect, which will not be repeated here.

In a third aspect, the present application provides a method for acquiring a key, which is applied to a vehicle, including: the first vehicle-mounted device receives a first message sent by an off-vehicle device; the first message is used to request the first vehicle-mounted device to obtain a first key; According to the verification information of the first message and the first vehicle-mounted device, an identity verification request message is generated, and the identity verification request message is used for the server to verify the authority of the first vehicle-mounted device to obtain the first key and the verification information of the first vehicle-mounted device; The server sends the identity verification request message; receives the identity verification response message sent by the server; the identity verification response message includes: the verification result of the identity verification request message.

Through the above method, the off-vehicle device can trigger the first on-vehicle device to securely obtain the first key, wherein, after the off-vehicle device sends the first message, the first on-vehicle device can based on the first message and the verification information of the first on-vehicle device For example, the first in-vehicle device obtains the authority of the first key, and the corresponding user of the first in-vehicle device obtains the authority of the first key, etc., and generates an identity verification request message sent to the server, thereby, through the server, the identity verification request The message is verified, and the first vehicle-mounted device can obtain the first key only after the verification is successful, which improves the security of the first vehicle-mounted device obtaining the first key. Wherein, the first message may be a personal identification number (personal identification number, PIN) code sent by the off-vehicle device, and the first on-vehicle device may encrypt the PIN code sent for the device according to the plan, and carry it in the identity verification request message, so that The server verifies the encrypted PIN to improve the security of verification. In addition, the first in-vehicle device can also obtain the certificate of the out-of-vehicle device through the out-of-vehicle device, or the certificate generated by the first in-vehicle device itself. The certificate can be used to verify the identity of the first in-vehicle device. Afterwards, the server may determine whether the first vehicle-mounted device has the right to obtain the first key based on the verification result of the certificate.

In a possible implementation manner, the first vehicle-mounted device receives a first message sent by the server; the first message is used to instruct the first vehicle-mounted device to generate a first key; the first vehicle-mounted device generates a first request message according to the first message; The first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: first key information; the first key information is generated after encrypting the first key of.

Through the above method, when the first key can be generated by the first vehicle-mounted device itself, the server can send the first message to the first vehicle-mounted device, at this time, the first vehicle-mounted device can generate a first request message based on the first message, It is used to instruct the first security hardware expansion unit to generate the first key. In this way, through the first vehicle-mounted device and the first security hardware expansion unit, the safe generation of the first key in the vehicle is realized, and the process of generating the first key by the first vehicle-mounted device is verified by the server Execution improves the security of generating the first key. It should be noted that, in this manner, for the specific manner of the first key generated by the first vehicle-mounted device, reference may be made to the implementation manner of the key generation method in the first aspect, which will not be repeated here. The first key may be loaded in the first vehicle-mounted device, or may be loaded in the second vehicle-mounted device. For details, refer to the detailed description in the embodiments of this application.

In a possible implementation manner, the first vehicle-mounted device receives the first key sent by the server.

Through the above method, the first vehicle-mounted device can securely obtain the first key stored in the server. Improves the security of obtaining the first key maintained by the server.

In a possible implementation manner, the first on-vehicle device sends the first key to the off-vehicle device when the verification result of the identity verification request message is that the verification is successful.

Through the above method, after the first on-vehicle device stores the first key, it can also send the first key to the off-vehicle device based on the verification result of the identity verification request message. For example, when the off-vehicle device is a vehicle diagnostic device, in order to ensure the security of vehicle data, when the vehicle diagnostic device collects and diagnoses vehicle data, it can be encrypted with the first key, and therefore, can be encrypted based on the second key. The server verification method in the aspect verifies that the first vehicle-mounted device obtains the first key legally, and at the same time, it can also verify the legitimacy of the off-vehicle device obtaining the first key through the first vehicle-mounted device. Security of the first key. Optionally, the first key may be generated by the first on-vehicle device for the off-vehicle device based on the first request message, or may be a key stored by the first on-vehicle device for communication with the off-vehicle device , which is not limited in this application. Optionally, after the off-vehicle device finishes using the first key, for example, the vehicle diagnostic device may notify the first on-board device to delete the first key, and the vehicle may also delete the first key for the device. During the next diagnosis, the first key can be regenerated to be used in the current diagnosis process. Improve vehicle data security.

In a fourth aspect, the present application provides a method for obtaining a key, which is applied to a server, including:

The server receives the identity verification request message sent by the first vehicle-mounted device; the identity verification request message is generated by the first vehicle-mounted device according to the first message sent by the off-vehicle device and the verification information of the first vehicle-mounted device; according to the identity verification request message, the server The first in-vehicle device obtains the authority of the first key and the verification information of the first in-vehicle device for verification, and generates an identity verification response message; the identity verification response message includes: a verification result of the identity verification request message. The server sends an identity verification response message to the first in-vehicle device.

Through the above method, the identity verification request message is verified by the server. After the verification is successful, the first vehicle-mounted device can obtain the first key, and the first vehicle-mounted device is triggered by the external device to securely obtain the first key. When verifying the first vehicle-mounted device, the server can verify the first message from the off-vehicle device and the verification information of the first vehicle-mounted device. For example, the first vehicle-mounted device obtains the authority of the first key, and the first The in-vehicle device verifies the user's authority to obtain the first key, etc., thereby improving the security of the first in-vehicle device in obtaining the first key.

In a possible implementation manner, the server sends a first message to the first vehicle-mounted device; the first message is used to instruct the first vehicle-mounted device to generate the first key.

In a possible implementation manner, the server sends the first key to the first vehicle-mounted device.

In a possible implementation manner, the identity verification request message is used to instruct the first in-vehicle device to send the first key to the out-of-vehicle device.

For the possible implementation manners above, reference may be made to the description of beneficial effects in the third aspect, which will not be repeated here.

In a fifth aspect, the present application provides a key generation device, the device is an on-board device or KMS in a vehicle, and the device includes:

An obtaining unit, configured to obtain a first message; the first message is used to instruct the first vehicle-mounted device to construct a first key;

The processing unit is configured to generate a first request message according to the first message; the first request message is used for the first security hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: a first key information; the first key information is generated after encrypting the first key.

In a possible implementation manner, the receiving unit is configured to receive the first response message sent from the first security hardware expansion unit.

A possible implementation manner, the receiving unit is configured to receive the first parameter of the first key sent from the first secure hardware expansion unit;

a processing unit, configured to generate a first key loading message according to a first parameter of the first key;

The sending unit is configured to send a first key loading message to the second vehicle-mounted device; the first key loading message is used for filling the first key after the second vehicle-mounted device successfully verifies the first key loading message.

In a possible implementation manner, after the obtaining unit obtains the first message, the sending unit is further configured to send a status update message to the first security hardware extension unit; the status update message includes: the construction status of the key in the vehicle; the status update message uses After the first security hardware extension unit successfully verifies the status update message, it updates the construction status of its own in-vehicle key.

In a possible implementation manner, the construction state of the in-vehicle key is used by the first security hardware expansion unit to verify the first request message.

In a possible implementation manner, after the processing unit determines that the first vehicle-mounted device is restarted, the sending unit sends a first query request to the first security hardware expansion unit; the first query request is used to query the second parameter of the first key; The receiving unit receives the first query response message sent by the first security hardware expansion unit; the first query response message is returned after the first security hardware expansion unit verifies the first query request; the first query response message includes: the first password The second parameter of the key; according to the second parameter of the first key and the first message, generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before the restart of the first vehicle-mounted device.

In a possible implementation manner, the receiving unit is configured to receive the temporary key sent from the first secure hardware extension unit; the temporary key is used to encrypt the first request message.

In a possible implementation manner, the receiving unit is configured to receive a second message sent by the second vehicle-mounted device; the second message is used for at least one of the following: querying the second parameter of the first key, requesting the first vehicle-mounted device to generate a second A key or instructs the second in-vehicle device to restart.

In a possible implementation, after the processing unit verifies the second message, the sending unit sends the third message to the second vehicle-mounted device; the third message includes at least one of the following items: the second parameter of the first key, the first key information.

receiving the first message sent by the in-vehicle device or the out-of-vehicle device through the receiving unit;

Obtain the first message after receiving the initialization or update information of the configuration file through the receiving unit;

After receiving the initialization or update information of the fixed key of the vehicle through the receiving unit, the first message is obtained;

The first message is obtained after the receiving unit receives the initialization or update information of the shared key between the on-vehicle devices of the vehicle.

In a sixth aspect, the present application provides a key generation device, which is a security hardware expansion unit in a vehicle, and the device includes:

The receiving unit is configured to receive a first request message sent by the first vehicle-mounted device corresponding to the first security hardware expansion unit; the first request message is generated by the first vehicle-mounted device requesting the first security hardware expansion unit to construct a first key;

The processing unit is configured to generate first key information after successfully verifying the first request message; the first key information is generated after encrypting the first key.

In a possible implementation manner, the key generation device includes a sending unit, configured to send a first response message to the first vehicle-mounted device; the first response message includes: first key information.

A possible implementation manner, after the processing unit successfully verifies the first request message, generates the first parameter of the first key; sends the first parameter of the first key to the first vehicle-mounted device through the sending unit; the first key The first parameter of the key is used to fill the first key in the second vehicle-mounted device.

In a possible implementation, the receiving unit is also used to receive the status update message sent by the first vehicle-mounted device; the status update message includes: the construction status of the in-vehicle key; the processing unit is also used to verify the status update message successfully. , to update the build status of its own in-vehicle key.

In a possible implementation manner, the receiving unit is further configured to receive a first query request sent by the first vehicle-mounted device after the first vehicle-mounted device restarts; the first query request is used to query the second parameter of the first key;

The processing unit is configured to send a first query response message to the first vehicle-mounted device through the sending unit after verifying the first query request; the first query response message includes: the second parameter of the first key; The second parameter is used for the first vehicle device to generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before restarting.

A possible implementation manner, the processing unit is configured to generate a temporary key after the first request message is verified successfully; send the temporary key to the first vehicle-mounted device through the sending unit; the temporary key is used to encrypt the first request message .

In a possible implementation, the receiving unit is configured to receive a verification message of a second message from the first vehicle-mounted device; the second message is received by the first vehicle-mounted device and sent by the second vehicle-mounted device; the second message is used for at least one of the following: Item: query the second parameter of the first key, request the first vehicle-mounted device to generate the first key, or instruct the second vehicle-mounted device to restart.

In a possible implementation manner, the processing unit is configured to, after verifying the second message, send a verification response message of the second message to the first vehicle-mounted device through the sending unit; the response message of the second message is used for the first vehicle-mounted device to send The second in-vehicle device sends a third message; the third message includes at least one of the following items: the second parameter of the first key, and information about the first key.

In the seventh aspect, the present application provides a key generation device, the device is an on-board device or KMS in a vehicle, the device may include a processor, the processor is connected to the memory, the memory is used to store computer programs, and the processor is used to execute the memory A computer program stored in the device, so that the device executes the method according to any one of the above-mentioned first aspects.

In an eighth aspect, the present application provides a key generation device, which is a secure hardware expansion unit in a vehicle. The device may include a processor, the processor is connected to a memory, the memory is used to store computer programs, and the processor is used to execute the memory. A computer program stored in the device, so that the device executes the method according to any one of the above-mentioned second aspects.

In a ninth aspect, the present application provides a vehicle, including the key generation device according to any one of the fifth aspect above and the key generation device according to any one of the sixth aspect.

In a tenth aspect, the present application provides a key acquisition device, the device is an on-board device or KMS in a vehicle, and the device includes:

The receiving unit is configured to receive the first message sent by the off-vehicle device; the first message is used to request the first on-vehicle device to obtain the first key; receive the response message of identity verification sent by the server; the response message of identity verification includes: identity verification Validation result of the request message.

The processing unit is configured to generate an identity verification request message according to the first message and the verification information of the first vehicle-mounted device, and the identity verification request message is used for the server to verify the authority of the first vehicle-mounted device to obtain the first key and the first vehicle-mounted device The information is verified.

The sending unit is configured to send an identity verification request message to the server.

In a possible implementation manner, the receiving unit is further configured to receive a first message sent by the server; the first message is configured to instruct the first vehicle-mounted device to generate a first key; and the processing unit is further configured to generate a second key according to the first message. A request message; the first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: first key information; Generated after key encryption.

In a possible implementation manner, the receiving unit is further configured to receive the first key sent by the server.

In a possible implementation manner, the processing unit is further configured to send the first key to the off-vehicle device through the sending unit when the verification result of the identity verification request message is that the verification is successful.

In an eleventh aspect, the present application provides a key acquisition device, the device is a server, and the device includes:

The receiving unit is configured to receive an identity verification request message sent by the first vehicle-mounted device; the identity verification request message is generated by the first vehicle-mounted device according to the first message sent by the off-vehicle device and the verification information of the first vehicle-mounted device;

The processing unit is configured to verify the authority of the first vehicle-mounted device to obtain the first key and the verification information of the first vehicle-mounted device according to the identity verification request message, and generate an identity verification response message; the identity verification response message includes: identity verification Validation result of the request message.

A sending unit, configured to send a response message of identity verification to the first vehicle-mounted device.

In a possible implementation manner, the sending unit is further configured to send a first message to the first vehicle-mounted device; the first message is used to instruct the first vehicle-mounted device to generate a first key.

In a possible implementation manner, the sending unit is further configured to send the first key to the first vehicle-mounted device.

In a twelfth aspect, the present application provides a key acquisition device, the device is a server, and the device includes: the device may include a processor, the processor is connected to a memory, the memory is used to store computer programs, and the processor is used to execute the A computer program stored to cause the device to execute the method according to any one of the third aspect above.

In a thirteenth aspect, the present application provides a key acquisition device, the device is a server, and the device includes: the device may include a processor, the processor is connected to a memory, the memory is used to store computer programs, and the processor is used to execute the A computer program stored to cause the device to execute the method according to any one of the fourth aspect above.

In a fourteenth aspect, the present application provides a vehicle, including the key acquisition device according to any of the above tenth or twelfth aspects.

In a fifteenth aspect, the present application provides a key generation system, including the key generation device according to any one of the fifth aspect and the key generation device according to any one of the sixth aspect. Optionally, off-vehicle equipment may also be included.

In the sixteenth aspect, the present application provides a key acquisition system, including any key acquisition device in the tenth or twelfth aspect and any key acquisition device in the eleventh or thirteenth aspect, which can Optionally, off-vehicle equipment may also be included.

In a seventeenth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is run, the method according to any one of the above-mentioned first aspects, or the above-mentioned second aspect is implemented. The method of any one of the above aspects, or the method of realizing any one of the third aspect above, or the method of realizing any one of the fourth aspect of the above claim.

In an eighteenth aspect, the present application provides a computer program product. The computer program product includes a computer program or an instruction. When the computer program or instruction is executed by a communication device, the method according to any one of the above-mentioned first aspects, or the above-mentioned first aspect is implemented. The method of any one of the two aspects, or the method for realizing any one of the third aspect above, or the method for realizing any one of the fourth aspect of the above claim.

In a nineteenth aspect, the embodiment of the present application provides a chip, the chip includes a data interface and a processor, wherein the processor is used to execute the method in the first aspect or any possible implementation of the first aspect, or the above-mentioned The method of any one of the second aspect, or the method of realizing any one of the third aspect above, or the method of realizing any one of the fourth aspect of the above claim. For example, the chip is any chip on which software or firmware is installed on the vehicle.

In a twentieth aspect, the present application provides a chip system, the chip system includes at least one processor, configured to support the implementation of the functions involved in the above-mentioned first aspect or any possible implementation of the first aspect, the above-mentioned first aspect Any one of the methods, or the function involved in any one of the above-mentioned second aspects, or realize the functions involved in any one of the above-mentioned third aspects, or realize the fourth aspect of the above-mentioned claims The functions involved in any of the. For example, such as receiving or processing data and/or information involved in the methods described above.

In a possible design, the chip system further includes a memory, the memory is used to store program instructions and data, and the memory is located inside or outside the processor. The system-on-a-chip may consist of chips, or may include chips and other discrete devices.

For the beneficial effects of the fifth aspect to the twentieth aspect above, please refer to the technical effects that can be achieved by the corresponding designs in the first aspect to the fourth aspect above, and will not be repeated here.

Description of drawings

FIG. 1 is a schematic diagram of a possible system architecture applicable to an embodiment of the present application;

Fig. 2 exemplarily shows a life cycle diagram of a long-term key in a vehicle provided by an embodiment of the present application;

Figure 3-Figure 7 exemplarily shows the schematic flow chart corresponding to the key generation method provided by the embodiment of the present application;

FIG. 8 is a schematic diagram of a possible system architecture applicable to the embodiment of the present application;

FIG. 9 exemplarily shows a schematic flow chart corresponding to a method for obtaining a key provided in an embodiment of the present application;

FIG. 10 exemplarily shows a schematic structural diagram corresponding to a key generation device provided in the embodiment of the present application;

FIG. 11 exemplarily shows a schematic structural diagram corresponding to a key generation device provided in the embodiment of the present application;

FIG. 12 exemplarily shows a schematic structural diagram corresponding to a key acquisition device provided in the embodiment of the present application;

FIG. 13 exemplarily shows a schematic structural diagram of a key acquisition device provided in the embodiment of the present application.

Detailed ways

It should be noted that the solutions in the embodiments of the present application can be applied to the Internet of Vehicles, such as vehicle to everything (V2X), long term evolution-vehicle (LTE-V), vehicle-to-vehicle (vehicle to vehicle, V2V) and so on. For example, it can be applied to vehicles with key generation and key authentication functions, or other devices in vehicles with key generation and key authentication functions. The other devices include but are not limited to: vehicle-mounted terminals, vehicle-mounted controllers, vehicle-mounted modules, vehicle-mounted modules, vehicle-mounted components, vehicle-mounted chips, vehicle-mounted units, vehicle-mounted radars, or vehicle-mounted cameras. , a vehicle-mounted module, a vehicle-mounted module, a vehicle-mounted component, a vehicle-mounted chip, a vehicle-mounted unit, a vehicle-mounted radar, or a vehicle-mounted camera, implement the key generation method provided by this application. Of course, the key generation method in the embodiment of the present application can also be used in other intelligent terminals with key generation functions other than vehicles, or set in other servers with key generation functions other than vehicles, or Set in the components of the smart terminal or server. The smart terminal may be a smart transportation device, a smart home device, a robot, and the like. For example, it includes but is not limited to smart terminals or controllers, chips, radars or cameras and other sensors in the smart terminals, and other components.

The server involved in the embodiment of this application can be a local server or a cloud server, and the server can be deployed in various ways. For example, the server can be a separate physical machine, and for another example, the server can also be a physical A certain virtual machine (virtual machine, VM) loaded on the server, for another example, the server can also be a certain container (docker) loaded on a certain physical server, etc. The following embodiments take the server as a cloud server for exemplary description, and the cloud server may also be referred to as the cloud for short.

In the embodiment of the present application, as shown in FIG. 1, the vehicle can adopt an electrical/electronic (E/E) architecture, which includes three levels, which are gateway electronic control unit (electronic control unit, ECU), Domain controller ECU and intra-domain ECU. Among them, according to different functions, it can be divided into different domains, and each domain has a domain controller ECU. The domain controller ECU is used to manage the intra-domain ECUs in the corresponding domain. The gateway ECU is used to manage the domain controller ECU. For example, as shown in Figure 1, according to different functions, it can be divided into four domains, namely, vehicle control system domain, entertainment system domain, diagnostic system domain and intelligent driving domain. Each domain corresponds to a domain controller ECU. The above 4 domains correspond to 4 domain controller ECUs in total. The gateway ECU is used to manage the 4 domain controller ECUs.

For example, in the embodiment of the present application, still can refer to Fig. 1, in the whole E/E structure, comprise 4 controller area network (controller area network, CAN) buses, are respectively CAN bus 1, CAN bus 2, CAN bus 3 and CAN bus 4. Optionally, the four CAN buses in FIG. 2 may correspond to the four fields in FIG. 1 . For example, CAN bus 1 in Figure 1 may correspond to the vehicle control system domain, CAN bus 2 may correspond to the entertainment system domain, CAN bus 3 may correspond to the diagnostic system domain, CAN bus 4 may correspond to the intelligent driving domain, etc.

It can be understood that the architecture shown in FIG. 1 is only for schematic illustration, and is not intended to limit the embodiment of the present application. For example, the method provided in the embodiment of the present application can be applied to other two-layer or one-layer architectures in addition to the three-layer architecture shown in FIG. 1 above, without limitation.

Based on the system architecture shown in FIG. 1 , some terms involved in this application will be introduced first.

(1) Electronic control unit (ECU).

In the embodiment of the present application, multiple ECUs can be configured inside the vehicle, such as ECU 1, ECU 2, ..., ECU N shown in Figure 1, where N is a positive integer. Among them, each ECU can have its own specific functions, and also supports simple sensor data processing and complex logic calculation. Currently common ECUs include but are not limited to: vehicle sensors, vehicle cameras, multi-domain controllers (multi domain controllers, MDCs), automated-driving control units (automated-driving control units, ADCUs), pre-installed intelligent gateways (telematics boxes, T-Box), can also be called vehicle information box, smart cockpit domain controller (cockpit domain controller, CDC), vehicle gateway, vehicle control unit (vehicle control unit, VCU), battery management system (battery management system, BMS) , thermal management system (thermal management system, TMS), power distribution unit (power distribution unit, PDU), etc.

(2) Gateway (gateway)

The gateway is the core part of the vehicle architecture. As the data exchange hub of the vehicle network, the gateway can transfer CAN, local interconnection network (local interconnection network, LIN), multimedia transmission system (media oriented systems transport, MOST), FlexRay and other network data Routing in different networks. The gateway can manage domain control devices and devices in the domain. In the embodiment of the present application, the gateway may include a gateway ECU, and the gateway and the gateway ECU are not distinguished from each other.

(3) Domain control device

According to the different functions of each part of vehicle electronics, vehicle electronics can be divided into several domains. For example, the power transmission domain, the body electronics domain, and the assisted driving domain. There is a domain control device in each domain, which is used to manage the devices in the domain. A domain control device may also be referred to as a domain controller. In the embodiment of the present application, the domain control device includes a domain control ECU, and the domain control device and the domain control device ECU are not distinguished from each other.

(4) Devices in the domain

According to the different functions of each part of vehicle electronics, vehicle electronics can be divided into several domains. For example, the power transmission domain, the body electronics domain, and the assisted driving domain. Each domain may include a domain controller and multiple controlled devices, and the devices in the domain may specifically refer to the controlled devices in each domain. In the embodiment of the present application, the in-domain equipment may include an in-domain ECU, and the in-domain equipment and the in-domain ECU are not distinguished from each other.

Wherein, in the architecture shown in FIG. 1 , in the embodiment of the present application, each ECU in the vehicle can exchange messages depending on the communication technology set when the vehicle leaves the factory. These communication technologies may be, for example, LIN technology or CAN technology, and may also be other communication technologies that realize message interaction. When relying on CAN technology to exchange messages, CAN messages can be sent between different ECUs. Each ECU can be connected to the same CAN bus, and any ECU can freely read and send CAN message frames on the CAN bus. Each CAN message frame on the CAN bus generally only has a message identifier, and does not carry a source address or a destination address. Each ECU connected to the CAN bus can select which message frame to receive through the message identifier. Although the message interaction method based on CAN technology has strong real-time and reliability, there is no built-in security function in CAN technology. In this case, once the attacker deciphers the CAN bus, every CAN message frame injected by the attacker may be read by the ECU in the vehicle and considered as a legitimate CAN message frame, so that the attacker can fully control Functions of the vehicle, such as braking or accelerating, which are very unsafe for the user to use the vehicle.

Therefore, each ECU in the vehicle can be configured with its own corresponding long-term key. When an ECU obtains a CAN message frame from the CAN bus according to the message identifier, the ECU can also use a pre-configured long-term key to parse the CAN message frame. If the parsing is unsuccessful, it means that the CAN message frame is likely to belong to an illegal control command injected on the CAN bus by an illegal person, so the ECU may not perform the corresponding control operation to prevent the illegal person from controlling the vehicle. If the parsing is successful, it means that the CAN message frame belongs to a legal control command injected on the CAN bus by a legal person (such as a car owner), so the ECU can perform corresponding control operations. In this way, by presetting the long-term key in each ECU to complete the authentication operation of the CAN message frame, it is helpful to authenticate the control command before actually executing the control, so as to improve the driving safety of the vehicle owner.

(5) KMS.

In the embodiment of the present application, a KMS may also be configured inside the vehicle. The KMS in the vehicle is mainly responsible for functions such as generating keys, managing keys, and clearing keys. , APP) and other off-vehicle devices to obtain the key. Based on the functions or permissions of KMS, it can be divided into KMS server (Server), KMS agent (Agent) and KMS client (Client).

The KMS server can be deployed on the domain controller in the vehicle (such as VDC, CDC, MDC, etc.), or it can be deployed on the gateway, T-BOX, or an independent device. The service end of KMS can include the SHE that supports the key generation method of the present application, and can also include other secure hardware mechanisms such as a hardware security module (hardware security module, HSM) that supports the key verification function corresponding to key generation. The KMS client can be various sensors, ECU components and other devices except the KMS server. The KMS client can include SHE, which can support the key generation process in this application, and can also be used to support the secure storage function of the key. The KMS client may also include other secure hardware mechanisms such as HSM to support secure key storage. Wherein, the agent (Agent) end of the KMS may be a device for connecting domain controllers, gateways, T-BOXs, sensor devices, and ECU components. The KMS agent can be used as a KMS sub-server (Sub Server) to manage the key generation process of the KMS client connected to the agent. The agent can form an agent domain with at least one KMS client connected to the agent.

The KMS server and KMS client can be pre-filled with keys for secure communication with each other. For example, each device can be filled with a fixed key (for example, GLOBAL_FIX_KEY) in advance. It can also be filled with a fixed key used between the KMS server and some KMS clients. This fixed key can be used as a key for secure communication between the KMS server and some KMS clients. , is not limited here.

These keys include the long-term keys described above. Unlike traditional information and communications technology (ICT), most ECUs in the Internet of Vehicles follow the automotive, cyber security (EVITA) standard and secure hardware extension (SHE) standard. Exemplarily, considering the performance and cost of key setting under the EVITA standard and the SHE standard, the long-term key in the KMS can be set as a symmetric key.

Fig. 2 exemplarily shows a life cycle diagram of a long-term key in a vehicle provided by an embodiment of the present application. As shown in Fig. 2, the entire life cycle of a long-term key in a car involves the , OEM) side, supplier side and vehicle point-of-sale side three communication interaction. Wherein, the OEM side may specifically include an OEM research and development line and an OEM production line. The supplier side may specifically include chip suppliers and component suppliers. For ease of understanding, whether it is chips provided by chip suppliers or ECUs or vehicle components assembled by component suppliers using these chips, they are collectively referred to as ECUs here. The supplier side can specifically include supplier R&D lines and supplier production lines. As shown in Figure 2, the entire life cycle of the long-term key in the car can include the following stages:

In stage 201, the OEM R&D line designs a key hierarchy according to business requirements and management requirements, and generates a symmetric key 1 required by the business requirements. Wherein, the symmetric key 1 may include one or more symmetric keys, and the one or more symmetric keys are used as initial keys for key hierarchy design, and are used to derive other symmetric keys.

Stage 202, the OEM R&D line sends the key hierarchy and Symmetric Key 1 to the Supplier R&D line. Among them, the sending operation needs to be carried out in a safe and confidential environment. For example, a special person can be arranged to send it secretly, or it can be transmitted through an encrypted peer-to-peer (P2P) method, or it can be sent through other secure communication methods, without limitation.

In stage 203, the supplier R&D line derives the symmetric key 2 provided by the supplier side based on the symmetric key 1 and the key hierarchy. Among them, the symmetric key 2 may include a root key of a chip required for assembling an ECU, a root key of an ECU required for assembling a vehicle part or a vehicle, and a root key of a vehicle part assembled from an ECU. The symmetric key 2 can also be configured to be updatable, that is, the symmetric key 2 can be changed according to different production environments.

In stage 204, the supplier's production line applies for a key from the supplier's R&D line when assembling ECUs or vehicle components.

In stage 205, the supplier's R&D line returns the symmetric key 1 and symmetric key 2 to the supplier's production line.

In stage 206, the supplier's production line calls the HSM or SHE standard, and encapsulates the symmetric key 1 and the symmetric key 2 in their corresponding ECU or vehicle components.

In stage 207, the supplier production line notifies the OEM production line to assemble the vehicle.

In stage 208, the OEM production line assembles the vehicle based on the ECU or vehicle parts packaged with the symmetric key 1 and the symmetric key 2, and applies for the key to the OEM R&D line during the assembly process.

In stage 209, the OEM R&D line returns the symmetric key 3 to the OEM production line. Wherein, the symmetric key 3 may include a root key and a work key preset by the OEM side. The symmetric key 3 is suitable for the after-sales stage of the vehicle, such as replacing ECU or vehicle components, or updating software configuration, etc.

In stage 210, the OEM production line encapsulates the symmetric key 3 in the vehicle, and then provides the vehicle to the vehicle sales point for sale. At this time, the symmetric key 1, the symmetric key 2 and the symmetric key 3 are packaged in the vehicle at the same time.

Stage 211, after the vehicle is sold, if the ECU or vehicle components in the vehicle are damaged, or the software configuration of the vehicle needs to be updated, the owner can also place the vehicle at the vehicle sales point, and the vehicle sales point will be based on the symmetric key 3-way The OEM side applies for after-sales. In addition, after the vehicle is sold, the owner can also preset some owner keys in the vehicle according to the prompt. At this time, the vehicle is packaged with symmetric key 1, symmetric key 2, symmetric key 3 and the owner key.

It should be understood that all the operations on the OEM R&D line side in the above stages can be completed through the administrator set on the OEM side and the key management system on the OEM side, and all operations on the supplier’s R&D line side can be done through the key management system set on the supplier side. Administrators and suppliers develop key management systems on the line side to complete this, which is not specifically described in this application.

According to the content shown in Figure 2, in the entire life cycle of the long-term key in the car, the long-term keys that the KMS in the car needs to manage include but are not limited to: Symmetric keys preset by the OEM R&D line according to business needs 1, The supplier's R&D line derives the symmetric key 2 based on the symmetric key 1, the symmetric key 3 preset on the OEM side, and the owner's key. These long-term keys can be applied to different scenarios respectively. For example, Table 1 exemplarily shows an application scenario of each long-term key managed by the KMS.

Table 1

As shown in Table 1, the process of a car from the completion of production and assembly to delivery to customers and on-road vehicles may involve multiple communicating data managers or users. For example, the data manager in the vehicle control domain (functional safety) is the car factory, and the intermediate vehicle operating company also needs to manage the data of the vehicle. For example, when diagnosing the vehicle, it also needs to control the vehicle to obtain the corresponding Vehicle diagnostic data. In addition, the managers of the infotainment domain of the vehicle may belong to different drivers or users of the vehicle. For these data managers or users in the vehicle, in order to realize the safe isolation of information between different services, when data communication is performed through the ECUs of different services of the vehicle, different keys need to be used to protect the information of the respective services between different devices. communication. In addition, with the evolution of vehicle intelligence, new services are gradually increasing. For the information security between different services, corresponding keys are set accordingly, which may lead to a gradual increase in keys. According to the above scheme, the car factory needs to provide Generate and manage more and more keys, management is difficult.

In addition, from a security point of view, the long-term keys managed by the KMS in the car will not only be applied to the interactive authentication between the ECUs in the car, but also the interactive authentication between the ECU in the car and the equipment outside the car. . Therefore, the long-term key plays a vital role in the vehicle. If the key for the business communication between the in-vehicle devices managed by the cloud is leaked, it may also lead to the leak of the user's key, which may immediately affect the security of all vehicles. Driving safety (functional safety, information security) may also lead to the leakage of users' private data.

The key generation method in this application will be introduced below with specific embodiments. Only a small number of fixed keys are maintained on the car factory cloud and on the user side, and the business communication keys between in-vehicle devices are independently constructed in the car, thereby reducing the number of cloud management keys; for different users and different business communication needs Building an independent business communication key can realize the security isolation of communication between different businesses. All parties or attackers will not be able to illegally monitor the business communication content of other users through the key of one party. It is only possible through formal authorization services access; in the end, even if the cloud key is leaked, it may be difficult to affect the driving safety of the vehicle.

It should be noted that the terms "system" and "network" in the embodiments of the present application may be used interchangeably. "At least one" means one or more, and "plurality" means two or more. "And/or" describes the association relationship of associated objects, indicating that there may be three types of relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A, B can be singular or plural. The character "/" generally indicates that the contextual objects are an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one item (piece) of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

And, unless otherwise specified, ordinal numerals such as "first" and "second" mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the priority or importance of multiple objects. For example, the first in-vehicle device and the second in-vehicle device are only for distinguishing different in-vehicle devices, and do not represent the difference in priority or importance of the two in-vehicle devices.

The following will describe the technical solutions in the embodiments of the application with reference to the drawings in the embodiments of the application. Apparently, the described embodiments are only some of the embodiments of the application, not all of them.

The embodiment of the present application provides a method for generating a key, which is applied to a vehicle, as shown in Figure 3, including:

Step 301: the first vehicle-mounted device obtains the first message.

Wherein, the first message is used to instruct the first vehicle-mounted device to construct the first key;

In some embodiments, the first in-vehicle device may be a KMS server or a KMS agent. For example, when the first vehicle-mounted device is a server, the first vehicle-mounted device may receive the first message through a non-KMS device. When the first vehicle-mounted device is an agent, the first vehicle-mounted device may receive the first message sent by the non-KMS device through the server. For specific implementation manners, reference may be made to the description of Scenario 1 to Scenario 4 below.

Step 302: The first vehicle-mounted device generates a first request message according to the first message.

The first request message is used for the first SHE corresponding to the first vehicle-mounted device to generate the first response message.

Wherein, the first SHE can be set in the same ECU as the first vehicle-mounted device, or can be set separately, which is not limited here. The first in-vehicle device may be a KMS for managing keys in the ECU.

Step 303: the first vehicle-mounted device sends a first request message to the first SHE.

Step 304: the first SHE generates a first response message according to the first request message.

Wherein, the first response message includes: first key information; the first key information is generated after encrypting the first key.

In some embodiments, the first key information may be an encrypted first key. Certainly, the first key information may also include other information of the first key, for details, refer to the introduction of the first response message below.

Step 305: the first SHE sends a first response message to the first vehicle-mounted device.

In the embodiment of the present application, the key data storage area of a vehicle-mounted device may include the following contents: key name (key name), key address (address or storage slot memory slot), storage area (memory area), for example, as Table 2 shows.

Table 2

Among them, the key name can identify the type of key stored in the storage area, for example, GLOBAL_FIX_KEY, which can be used to store the fixed key PSKFix_Global of one vehicle and one secret, and can be used for the ECU to update GLOBAL_FIX_KEY or update other keys of the ECU . This key can also be the same key as the master key of this ECU (for example, MASTER_ECU_KEY in the SHE protocol) or a different key. It can also be used for the ECU to generate a fixed key dedicated to the long-term key in the vehicle, which is not limited in this application. KMS_CFG_MAC can be used to store the security check code of the ECU configuration file update, which is used for security check when initializing or updating the KMS configuration file.

MAC_FIX_KEY can be a fixed key used to verify the integrity of the relevant software generated by the key of KMS when the SHE is securely started. The security verification code BOOT_MAC may be a verification code for verifying the integrity of the relevant software generated by the key of the KMS when the SHE is securely started. Wherein, MAC_FIX_KEY can also be a fixed key used to verify the integrity of other KMS software of the vehicle, for example, the fixed key BOOT_MAC_KEY in the SHE protocol.

KEY_1～KEY_20: can be used to store the symmetric key (encryption key, or integrity key) for communication between in-vehicle devices.

When the one-vehicle-one-secret fixed key is an asymmetric key, KEY_1 can be used to store the key pair (Pair) of the one-vehicle-one-secret fixed key PSKFix_Global. For example, when online update is supported, that is, when the one-vehicle-one-secret fixed key is updated through the cloud server, security verification can be performed according to the key pair of the one-vehicle-one-secret fixed key PSKFix_Global. KEY_2 can be used to store the security verification key PSKGlobal of the fixed key of the ECU, that is, it can be a key for security verification of the fixed key on the ECU, so as to enhance the security of the fixed key. When the security verification key PSKGlobal is an asymmetric key, KEY_3 can be used to store the key pair (Pair) of the security verification key PSKGlobal of the ECU's fixed key, which is used for pairing with the security verification key. When the security verification key PSKGlobal performs encryption or integrity verification, security verification can be performed based on this key. Other locations may be used to store long-term keys or fixed keys used by the KMS planned for the vehicle equipment. For example, when the first key is a long-term key, the first key may be a long-term key dedicated to the first vehicle-mounted device, the first key may be a long-term key dedicated to the second vehicle-mounted device, and the first key may be a long-term key dedicated to the second vehicle-mounted device. The key may be a long-term key used between the first vehicle-mounted device and the second vehicle-mounted device. The first key may be the corresponding long-term key when user 1 uses the first vehicle-mounted device. A long-term key corresponding to a vehicle-mounted device and a second vehicle-mounted device. In some embodiments, the long-term keys of the vehicle equipment generated in this application may be stored in keys KEY_1-KEY_20. The corresponding key address can be used to indicate the identity of the key and the storage location of the key. For example, the value of memory slot and KEY_ID below can be the value of the key address. Other locations of KEY_1 to KEY_20 can also be used to store other keys that are not managed by KMS, such as encryption keys used for encrypted storage of local files.

Optionally, the key data storage area of the ECU can also include other parameters, which can include: KMS role information, wherein the KMS role information can include: key validity period (KMS_CFG_KeyLifetime), KMS configuration file version number (KMS_CFG_Version), The role of KMS (KMS_CFG_Role). The key validity period can support reading and writing outside the storage area. For example, the validity period of all long-term keys can be set to be the same, and the unit of the key validity period can be minutes. The version number of the KMS configuration file may be a version number set for the key. For example, the version number after the key in the key system of KMS generated for the first time is 1.0. Of course, the length of the version number can also be increased. For example, the version number of the configuration file is the version number combined with the software version number of the KMS. The roles of KMS can include: no role information (the value of role information can be 0), KMS server (the value of role information can be 1), KMS agent (the value of role information can be 2), KMS client (the value of role information can be 2), The value of information can be 3), other values are invalid values.

The key data storage area of the ECU can also include: the construction status (KMS_KH_BuildStatus) of the key system, the counter (KMS_KH_BuildCounter) of the key construction success in the KMS key system, the time (KMS_KH_BuildDate) of the KMS key system construction successful completion, KMS The integrity check code (KMS_KH_BuildMac) stored in the construction parameters of the key system and the temporary key KMS_KH_BuildKTemp used in the construction of the KMS key system. The construction of the key system in this application may be expressed as at least one long-term key (first key) constructed by the KMS. The construction status of the key system can include: not constructed, under construction, successful construction, and construction failure. For example, the value of the construction status of the key system may be 0 to 3, wherein 0 indicates that it is not constructed, 1 indicates that it is under construction, 2 indicates that the construction is successful, and 3 indicates that the construction fails. The key construction success counter in the KMS key system can be used to indicate the number of keys that are currently successfully constructed. The time when the construction of the KMS key system is successfully completed. When there is a process of constructing the KMS key system, the time when the construction of the KMS key system is successfully completed may indicate the date and time when the construction of the KMS key system was successfully completed last time. The accuracy is stored at the minute level. For example, the successful time of this build is 2020-9-29 10:20:25. Calculate the time from 0:00 in 0000, how many minutes have actually passed, and pay attention to leap year and other processing. Of course, other methods can also be used. It should be noted that the construction status of the key system (KMS_KH_BuildStatus), the counter of the key construction success in the KMS key system (KMS_KH_BuildCounter), and the time when the KMS key system construction was successfully completed (KMS_KH_BuildDate) are used for the ECU in the KMS The relevant information of the ECU's key construction is determined during the construction of the key system. Therefore, these parameters can only be written by the ECU, and external devices do not have permission to write.

It should be noted that during the construction process of the key system, when data such as the generated construction status and key generation status are solidified and stored, they can be verified by the integrity check code used to store the construction parameters of the KMS key system . The integrity check code can be stored separately, or stored in a free KEY_<n>.

The temporary key KMS_KH_BuildKTemp used in the construction of the KMS key system can also be stored separately or in an idle KEY_<n>. After the key construction in the key construction system is completed, the temporary key can be deleted . In this example, n is less than or equal to 20. The specific value can be determined according to actual needs.

The non-volatile storage area (non-volatile) is used to store fixed keys, long-term keys, or security verification codes for secure boot. Volatile storage area (Volatile), which can be used for temporary storage of keys when SHE performs security verification on filled keys when filling keys, and can also be used for temporary storage of non-key data, or temporary data. For example, the ECU can send the CMD_LOAD_KEY command to the SHE in cipher text, and the SHE will perform an integrity check on the input parameters of the command, and then decrypt it to obtain the key carried by the command, and store the key in this location.

When each key is stored, in addition to the key, it can also contain some other information, such as write-protection (write-protection) flag, secure boot failure (secure boot failure) flag, debugger activation (debugger activation) identification bit, wildcard unique identification item (wildcard UID), key usage identification bit (key-usage), plaintext key identification bit, key update count (counter) identification bit, key construction status An identification bit (buildstatus), a key index (KeyID), etc., a possible implementation manner, may be shown in Table 3.

table 3

Wherein, X in Table 3 indicates that when storing the row key or security check code, the content of the column must be included. X/- indicates that when storing the row key or security check code, this content can be included according to the needs of the product or KMS business. A blank means that the content of this column may not be included when storing the row key or security check code.

In the write-protection identification bit, if the value of the write-protection identification bit is 1, the key is not allowed to be updated again. If the value of the write-protect flag is 0, it means that the key allows updates. The secure boot failure (secure boot failure) flag and the debugger activation (debugger activation) flag indicate the state of the key after the SHE is securely booted. Wherein, the secure boot failure flag may also be a boot-protection flag, and the debugger activation flag may be a debugger-protection flag. The wildcard UID (wildcard UID) identification bit is used to indicate, the key usage identification bit (key-usage) is used to identify, and the plaintext key identification bit is used to identify whether the key is stored in plain text. The key update count identification bit is used to identify the number of key update times, and the update can be determined by the value of the key update counter at this time. The maximum length of the number of bits that may be occupied by each key can be shown in the overall data (Overall data) indicator in Table 2, and the block size of each memory slot is constrained not to be less than the maximum value.

The UID of the ECU can be the UID corresponding to the ECU, or the default identifier (wildcard UID). For example, when the UID value is 0, the UID can be used as a default identifier. Wherein, the default identifier is used to determine whether any UID is allowed to be used to fill (overwrite update) keys into the corresponding storage area. For example, when the wildcard UID is 1, it is allowed to use any UID to fill the key of the ECU. If the wildcard UID is 0, it is not allowed to use any UID to fill the key of the ECU. The memory slot is used to indicate the key address stored in the ECU storage area to the first key. UID can be 120 bits or 128 bits.

The key build status (BuildStatus) refers to the build status of a key, and the key build status can occupy 1 bit. The value of the key construction status can be 0 to 3, where 0 means not being built, 1 means building in progress, 2 means building successfully, and 3 means building failed. It should be noted that the status information of the key indicates that the key is successfully built in the ECU, and does not involve whether the key is successfully filled on other devices. A possible implementation manner may determine whether all related devices involved in the key hold the key according to the construction status of the key system of the KMS. For example, when the construction status of the key system of the KMS is successfully constructed, it is determined that all relevant devices involved in the key hold the key.

The key index (KeyID) may be a key index assigned by the KMS and not related to the key address of the secure storage hardware, or may be a value associated with the key address. For example, can occupy 32 bits, installed with the key.

In this application, the key system of the vehicle may include: a configuration file, a fixed key, a long-term key, and the like. Wherein, the fixed key may include a one-vehicle-one-secret fixed key, and may also include a fixed key related to at least one vehicle-mounted device. The fixed key related to the at least one vehicle-mounted device may be limited to be used in relation to the at least one vehicle-mounted device. The long-term key may also include a one-vehicle-one-secret long-term key, and may also include a long-term key involving at least one vehicle-mounted device. The fixed key related to the at least one vehicle-mounted device may be limited to be used in relation to the at least one vehicle-mounted device. In this application, the fixed key may be a key obtained from outside the vehicle, and the long-term key may be a key generated by the vehicle itself. In the process of building the key system of the vehicle, in order to ensure the security and credibility of the vehicle-mounted equipment on the construction and management of the key system, the vehicle-mounted equipment and the corresponding SHE are building the key transmission and key system Related messages need to be encrypted or integrity protected with a security verification key.

The following introduces various scenarios for triggering the construction of the key system of the vehicle, that is, there may be various scenarios for triggering the first vehicle-mounted device to obtain the first message. Taking the first vehicle-mounted device as the server as an example, the first SHE can be used to generate first key. In some embodiments, the server and SHE can be set on an ECU, and are used to manage the key of the ECU. When the ECU includes the server and the SHE, the operation between the server and the SHE can be performed through the fixed key of the off-vehicle device (for example, the cloud or a terminal that manages the fixed key (for example, an APP that manages the fixed key)) The security verification key, or the fixed key or temporary key provided by the server in the vehicle itself is used as the security verification key. The following uses scenarios 1 to 4 as examples.

Scenario 1: A configuration file update message (for example, the first message) is initiated to the KMS server of the vehicle through a non-KMS device. At this time, the configuration file update message can be encrypted and integrity-protected through the fixed key of the non-KMS device. safety verification. The configuration file update message may include at least one of the following: an updated configuration file, a security verification code of the configuration file, KMS role information, and the like.

In some embodiments, the non-KMS device can be a cloud server or a terminal that manages the vehicle key. At this time, the cloud server or the terminal that manages the vehicle key can encrypt and complete the first message according to the fixed key of the cloud server. Security verification for sex protection. In some other embodiments, the non-KMS device can be the CDC or the central control panel of the vehicle. The CDC or the central control panel responds to the confirmation operation of the user's configuration file update. The SHE corresponding to the CDC or the central control panel can be based on a vehicle's One secret fixed key generates the first message, that is, the CDC or the central control panel can perform encryption and integrity protection security verification on the first message according to the one car one secret fixed key.

Optionally, after the KMS server of the vehicle receives the configuration file initialization message or update message, it can initialize or update the relevant information of the configuration file in the SHE corresponding to the server after successful verification. In addition, the server can also send a configuration file initialization message or an update message to the agent or client, so that the agent or client can verify the configuration file initialization message or update message successfully, and the agent or client corresponding SHE The relevant information of the configuration file is initialized or updated. Optionally, the server may not forward the message to the client. After the agent successfully verifies the configuration file initialization message or update message, it may also send the configuration file initialization message or update message to the client, so that the client After the configuration file initialization message or update message is verified successfully, the related information of the configuration file in the SHE corresponding to the client is initialized or updated.

Considering that the server, agent, and client in KMS perform different functions on the respective SHEs. For example, the SHE on the server side generates the encrypted first key and the security verification key, and cooperates with the KMS server side to manage the construction of the key system in the vehicle. The agent's SHE is used to cooperate with the KMS server to complete the generation and filling of the first key of each client in the agent's domain. Therefore, in this application, different KMS roles can be configured for different vehicle-mounted devices in the KMS, so that the server or agent can better manage the keys of each vehicle-mounted device.

In some embodiments, the KMS server of the vehicle may determine the initialization or update of the KMS role information and the security verification code of the initialization or update configuration file according to the initialized or updated configuration file. And configure the KMS role information and the security verification code of the corresponding configuration file for each vehicle-mounted device. The following describes the process of generating a configuration message for KMS role information when a configuration file is initialized or updated with a specific scenario example.

Scenario 1.1, when the initialized KMS configuration file is delivered, the KMS can generate a KMS role information configuration message for each vehicle-mounted device (for example, the KMS server of the vehicle, the agent and the client of the vehicle). The KMS role information may include at least one of the following: KMS role (KMS_CFG_Role), configuration file version number (KMS_CFG_Version), validity period of a long-term key constructed by KMS (KMS_CFG_KeyLifetime), and the like.

Scenario 1.2, when the KMS configuration file is updated, especially when the definition of the communication security domain changes, it is necessary to re-update the KMS role information of the vehicle, or send a configuration message of the KMS role information to each vehicle-mounted device to update the vehicle internal The KMS role information of each vehicle-mounted device.

When the KMS server of the vehicle receives the configuration message of the KMS role information, the KMS server of the vehicle forwards the message to the corresponding SHE of the server, and the SHE of the server can verify the KMS role information based on the security verification key outside the vehicle. The configuration message is verified. After the verification is successful, the corresponding KMS role information is stored in the corresponding position in the SHE. Optionally, when the configuration message of the KMS role information carries the initialization or updated security verification code of the configuration file, the SHE can also store the updated security verification code of the configuration file in the position of KMS_CFG_MAC in the SHE after the verification is successful .

After the vehicle's KMS server receives the KMS role information configuration message, the vehicle's KMS server can also forward the message to the agent or client.

Therefore, after the KMS agent of the vehicle receives the configuration message of the KMS role information, the agent forwards the message to the SHE corresponding to the agent, and the SHE of the agent can verify the KMS role information based on the security verification key outside the vehicle. The configuration message is verified. After the verification is successful, the corresponding KMS role information can be stored in the corresponding position in the SHE. Optionally, when the configuration message of the KMS role information carries the initialization or updated security verification code of the configuration file, the SHE can also store the updated security verification code of the configuration file in the position of KMS_CFG_MAC in the SHE after the verification is successful .

Correspondingly, after the KMS agent of the vehicle receives the configuration message of the KMS role information, the agent can also forward the message to each client managed by the agent.

Correspondingly, the KMS client of the vehicle can receive the configuration message of the KMS role information through the server or agent. At this time, the client forwards the message to the corresponding SHE of the client. The security verification key is used to verify the configuration message of the KMS role information. After the verification is successful, the corresponding KMS role information can be stored in the corresponding position in the SHE. Optionally, when the configuration message of the KMS role information carries the initialization or updated security verification code of the configuration file, the SHE can also store the updated security verification code of the configuration file in the position of KMS_CFG_MAC in the SHE after the verification is successful .

Specifically, for different scenarios, there may be multiple configuration message modes for the SHE to verify the KMS role information, and modes 1.3 to 1.4 are used as examples below.

Mode 1.3, when the key system construction starts, the key system construction start message (CMD_KMS_KH_BUILD_START) can be used to instruct the SHE to start the construction of the key in the key system, and the SHE can verify the key system construction start message. After the verification is successful, change the key system construction status (KMS_KH_BuildStatus) to under construction. When the key system construction status is unconstructed, the key system construction startup message that can be passed carries the information in the configuration message of the KMS role information. At this time, the SHE can verify the key system construction startup message, and the verification succeeds. After that, verify the information in the configuration message of the KMS role information. For the specific verification method, please refer to the verification of the CMD_KMS_SET_CFG_INFO command below.

Mode 1.4, during the key system construction process, if any parameter of KMS in SHE is changed, SHE can determine whether any parameter of KMS meets the update requirements according to whether the key system construction status (KMS_KH_BuildStatus) is "constructing". When the key system construction status is "constructed successfully", verify the information in the KMS role information configuration message. For the specific verification method, refer to the verification of the CMD_KMS_SET_CFG_INFO command below. When the construction status of the key system is not "under construction", the verification of the configuration message for determining the KMS role information fails.

In addition, when the key system construction status is not "construction successful", each key affected by the key system construction status (for example, at least one first key involved in the key system construction) will not be available. For example, when the on-board device requests to use the first key, SHE verifies the construction status of the key system involved in the first key according to the request. After the verification fails, SHE can return "the key status is wrong, and the KMS needs to be rebuilt." key system" status code, for example, ERC_KMS_KH_NEED_TO_REBUILD.

For example, when the KMS sends an encrypted filling message of the first key to the vehicle-mounted device, the KMS may send KMS role information to each vehicle-mounted device in the vehicle. After each vehicle-mounted device in the vehicle receives the configuration message of the KMS role information corresponding to each vehicle-mounted device, it can perform security verification on the configuration message of the KMS role information according to the SHE corresponding to the vehicle-mounted device. After the verification is successful, the KMS role information The information is written into SHE, and the corresponding security verification code is written.

For example, the configuration message of KMS role information may be a CMD_KMS_SET_CFG_INFO command. The input parameters of the command may be as shown in Table 4. The input parameter can be understood as the incoming parameter, and the input parameter can be used to carry the input parameter when the command is sent to the first SHE through the first vehicle-mounted device to request the first SHE to verify, such as CMD_KMS_SET_CFG_INFO and other commands.

Table 4

Among them, the input parameter M1 satisfies:

M1＝KEY_ID|KMS Role|KMS_CFG_Version|KMS_CFG_KeyLifetime

Among them, "|" can be understood as splicing. For example, M1 can splice the corresponding bytes of KEY_ID, KMS Role, KMS_CFG_Version, and KMS_CFG_KeyLifetime together. For example, in the process of transmitting M1, bytes such as KEY_ID, KMS Role, KMS_CFG_Version, and KMS_CFG_KeyLifetime can be transmitted in sequence.

In a possible scenario, when the initial configuration file is issued, the KEY_ID may be a fixed key of the vehicle. In another possible scenario, when the KMS server configures the KMS role information and the corresponding long-term key for itself according to the KMS configuration file during the generation of the long-term key of the vehicle, it is considered that the first vehicle-mounted device has obtained the corresponding The temporary key generated by SHE, therefore, KEY_ID can be the key address corresponding to the temporary key.

The input parameter M2 satisfies: M2=CMAC(Key,M1)

That is, M1 is encrypted and integrity protected by entering parameter M2, and the key used to encrypt M1 may be the key corresponding to KEY_ID. Therefore, when the first vehicle-mounted device sends the command to the first SHE corresponding to the first vehicle-mounted device, the SHE can perform security verification on the command according to the KEY_ID. That is, SHE can perform CMAC operation on M1 according to the key corresponding to KEY_ID stored in SHE to obtain M2', and when M2' is determined to be equal to M2, it is determined that the command verification is successful.

Optionally, after the configuration file is updated, the KMS server of the vehicle can determine whether the fixed key of the vehicle needs to be updated, that is, when the KMS server of the vehicle determines that the fixed key of the vehicle needs to be updated according to the updated configuration file, A reminder message can be sent to a non-KMS device to remind the non-KMS device to generate a fixed key and initiate a fixed key filling message.

Optionally, after the KMS configuration file is initialized or updated, according to the updated or initialized KMS role information, the KMS can also determine the long-term key to be generated in the key system of the in-vehicle KMS, thereby triggering the to-be-generated The long-term key generation process.

Scenario 2: A non-KMS device initiates a fixed key filling message to the KMS server of the vehicle. At this time, the updated fixed key can be encrypted and integrity-protected for security verification using the fixed key of the non-KMS device. When the KMS server of the vehicle receives the message of filling the fixed key, it can send the message of filling the fixed key to the SHE corresponding to the server. The key filling message is verified, and after the verification is successful, the updated fixed key is stored. For example, when the fixed key is GLOBAL_FIX_KEY, the server stores the fixed key in the position of GLOBAL_FIX_KEY corresponding to the SHE, and when the fixed key is MAC_FIX_KEY, the SHE stores the fixed key in the position of MAC_FIX_KEY. In some embodiments, the input parameter of CMD_LOAD_KEY can be generated by the equipment outside the vehicle, which is used for filling the first key in the vehicle. In this application, this method is mainly used in a scenario where the first key is a fixed key, and may also be used in a scenario where the first key is a long-term key, which is not limited here.

In a possible implementation, the external device sends the first key loading message to the first vehicle-mounted device (for example, the server), and the first vehicle-mounted device can load the first key parameter) sent to the corresponding SHE verification of the first vehicle-mounted device. After the verification is successful, the first key is stored, and according to the first key loading message, a response message for the first key loading is generated (for example, a message that can carry CMD_LOAD_KEY output parameter), the response message of the first key loading is fed back to the off-vehicle device, and the off-vehicle device can verify according to the response message of the first key loading to determine whether the first key loading of the first on-vehicle device is successful.

In another possible implementation, the external device sends the first key loading message to the first vehicle-mounted device (for example, the server), and the server forwards the first key-loading message to each second vehicle-mounted device in the vehicle, Wherein, the second vehicle-mounted device may be an agent or a client. Wherein, a possible implementation manner is that the server sends the message to the proxy or the client, or the server forwards the first key loading message through the key management tool. The outgoing parameter can be understood as the parameter sent out when the SHE that receives the command successfully verifies the command, and the outgoing parameter can be used to pass the outgoing parameter to the command.

The second vehicle-mounted device (agent or client of KMS) forwards the first key loading message (for example, may carry the input parameter in CMD_LOAD_KEY) to the second SHE (the SHE corresponding to the second vehicle-mounted device, wherein the second SHE It can be the SHE corresponding to the second vehicle-mounted device. This SHE can be arranged in the ECU corresponding to the second vehicle-mounted device, or it can be set separately by the second vehicle-mounted device, which is not limited here) verification, after the verification is successful, in The first key is stored in the second SHE, and according to the first key loading message, a response message for loading the first key (for example, may carry an output parameter of CMD_LOAD_KEY), and the response message for loading the first key Feedback to the agent or server, and then forwarded to the server, the server will be able to return the response message loaded with the first key to the off-vehicle device, and the off-vehicle device can proceed according to the response message loaded with the first key Verification is to determine whether the first key loading of the second in-vehicle device (each agent or client) is successful.

After the second SHE stores the first key (for example, a new fixed key), the second SHE can set the key construction state corresponding to the first key. For example, setting the key build status BuildStatus to "1" indicates that the first key is successfully built.

The following specifically introduces the CMD_LOAD_KEY command, which can safely store the first key to the storage area specified by the key address (for example, memory slot) in the SHE. As shown in Table 5.

table 5

参数ParameterParameterParameter	参数方向DirectionParameter direction Direction	宽度Width(bit)Width(bit)
M1M1	入参(IN)Input (IN)	128128
M2M2	入参(IN)Input (IN)	256256
M3M3	入参(IN)Input (IN)	128128
M4M4	出参(OUT)OUT parameter (OUT)	256256
M5M5	出参(OUT)OUT parameter (OUT)	128128

When the off-vehicle device wants to fill the first key into the first vehicle-mounted device or the second SHE, it can derive the existing key according to the existing key in advance, for example, the current value of GLOBAL_FIX_KEY in the SHE or the original key at this position. The encryption key K1 and the integrity key K2 are used to protect the input parameters of CMD_LOAD_KEY, that is, the input parameters of the constructed CMD_LOAD_KEY command are based on protection. Or, when the off-vehicle device wants to fill a new key into the KEY_<n> position, the off-vehicle device must know the key stored in the current GLOBAL_FIX_KEY position or the key stored in the KEY_<n> position in advance. For example, KEY_<n> represents KEY_1 to KEY_10. When filling a key to a location, the original key stored at that location, or the GLOBAL_FIX_KEY, must be known in advance. For example, the specific key to be filled corresponds to the encryption key that protects the input parameter of CMD_LOAD_KEY, as shown in Table 6.

Table 6

In Table 6, "X" indicates that at least one key on the corresponding column is used as the security verification key for security verification when filling the corresponding key on the row. For example, when the first key is GLOBAL_FIX_KEY, the GLOBAL_FIX_KEY stored in the SHE should be used as the input parameter of the security verification key construction CMD_LOAD_KEY to realize the security verification of the first key GLOBAL_FIX_KEY filling. When the first key is KEY<n>, the GLOBAL_FIX_KEY or KEY<n> stored in SHE can be used as the input parameter of the security verification key to construct CMD_LOAD_KEY to realize the security verification of the first key KEY<n> filling . When the first key is RAM_KEY, KEY<n> or SRCERET_KEY or plaintext (plaintext) stored in SHE can be used as the input parameter of the security verification key construction CMD_LOAD_KEY to realize the security verification of the first key RAM_KEY filling.

In an optional implementation manner, a message authentication code (message authentication code, MAC) generator may also be provided in the SHE, and the message authentication code generator is used to process input information according to a preset generation algorithm to obtain a message authentication code and output. When the preset generation algorithm is CMAC, the ECU of the first key generates the message authentication code M3 of the command according to the key for encrypting the command. In a possible implementation, the message authentication code M3 of the command satisfies the following formula:

M3=CMAC(K2,M1|M2)

Wherein, K2 is the key for integrity verification derived from the security verification key corresponding to KEY_ID. The security verification key corresponding to the KEY_ID may be the identifier of the security verification key used corresponding to the first key in Table 3. The security verification key can also be used to derive an encryption key K1 for encrypting the first key.

The parameter M1 satisfies: M1=UID|memory slot|KEY_ID

Wherein, the UID is a unique identification item (unique identification item) of the first vehicle-mounted device, which may be a UID corresponding to the first vehicle-mounted device, or may be a default identification (wildcard UID). For example, when the UID value is 0, the UID can be used as a default identifier. Wherein, the default identifier is used to determine whether any UID is allowed to be used to fill (overwrite update) keys into the corresponding storage area. For example, when the wildcard UID is 1, it is allowed to use any UID to fill the key of the ECU. If the wildcard UID is 0, it is not allowed to use any UID to fill the key of the ECU. The memory slot is used to indicate the key address stored in the ECU storage area to the first key.

The input parameter M2 satisfies: M2＝ENC _{CBC, K1, IV＝0} (Counter|Flags|“0…0” ₉₅ |Key _{memory slot} )

Wherein, the encryption function ENC _CBC,K1,IV=0 means that the CBC mode of AES is used for encryption, the initialization vector (initialization vector, IV) value is 0, and K1 is used as the encryption key.

Counter indicates the key update count corresponding to the first key. After the first key is updated every time, that is, after the first key is loaded successfully, the Counter can be increased by 1, which is used for SHE to verify whether there is a replay attack on the command. When using AES_CBC_128 encryption, the block length is 128 bits, and M2 can be filled with "0...0" ₉₅ , for example, 95 bits of 0 are filled.

Flags can be determined according to the information stored in the SHE by the first key, for example, Flags satisfies:

Flags=write-protection|boot-protection|debugger-protection|key-usage|wildcard.

For the parameters in Flags, see the values in Table 3 for details.

The Key _{memory slot} indicates the first key stored in the memory slot.

Taking the second vehicle-mounted device as an example, after the second SHE receives the CMD_LOAD_KEY command, the command may include three parameters as input parameters. The second SHE can input the 3 input parameters in the CMD_LOAD_KEY command to the message authentication code parser, and then the message authentication code parser uses the M1 and M2 of the input parameters in the command, and the information corresponding to the CMD_LOAD_KEY command stored by the SHE itself. The security verification key, for example, the security verification key corresponding to the first key, generates K1 and K2, and correspondingly generates a message authentication code M3'. When it is determined that the message authentication code M3' is the same as M3, it is determined that the verification is successful. And store the first key carried in the command to the location corresponding to the memory slot.

Correspondingly, the second SHE can also obtain the output parameter of the command according to the 3 input parameters in the CMD_LOAD_KEY command, that is, M4 and the message authentication code M5 of the integrity check, and the message authentication code M5 satisfies: M5=CMAC(K4, M4).

Among them, K4 is the key used for integrity verification derived from the first key stored in the memory slot. The parameter M4 satisfies the following formula: M4=M1|EncyptedValue.

Among them, EncyptedValue=ENC _{CBC, K3, IV=0} (Counter|“1” ₁ |“0…0” ₉₉ ), “1” ₁ means the value “1” occupies 1 bit, “0…0” ₉₉ means the value “0” " occupies 99 bits. Counter is the value of the update counter set by the SHE corresponding to the first key, which may be 28 bits, and is used to verify the replay attack on the received CMD_LOAD_KEY command. When using AES_CBC_128 encryption, the block length is 128 bits. K3 is an encryption key derived from the first key stored in the memory slot (that is, the Key _{memory slot} ).

Optionally, after the filling of the fixed key is completed, the KMS server of the vehicle may also determine whether to update the corresponding long-term key according to the scope of use of the fixed key. For example, the fixed key is a vehicle-one-key fixed key, and at this time, the KMS server of the vehicle may determine to update the long-term key generated based on the fixed key. The KMS server of the vehicle can send a long-term key update request to the non-KMS device. After the non-KMS device receives the long-term key update request, the non-KMS device can verify the long-term key update request. After the verification is successful, a second key update request is generated. a message. For the manner in which the non-KMS device generates the first message, refer to scenario 3.

Scenario 3, when the first key is a long-term key, the first key can be generated by the SHE of the vehicle. During the process of generating the first key, in order to ensure the security of the message between the vehicle equipment and the SHE, and The message security between the device and the vehicle-mounted device can be verified for the security of the corresponding message. For example, as shown in Table 7, the security verification keys used for the messages that may be involved in the key system construction process of this application may be used. Examples of specific messages are described below.

Table 7

X: Indicates that the key can be used as a security verification key. For example, the premise of using the temporary key as the security verification key is to use the temporary key as the security verification key when the temporary key can be obtained when constructing the message. For example, the first vehicle-mounted device generates a corresponding message according to the temporary key, and verifies it through the first SHE. The second on-vehicle device generates a corresponding message according to the temporary key, and verifies it through the second SHE. Y: Indicates that the key is preferentially used as the security verification key. For example, when the long-term key is used as the security verification key, it may be a security verification key used in messages between the first vehicle-mounted device and the second vehicle-mounted device, and the verification is performed by respective corresponding SHEs. Z: indicates that the key can be used as the security verification key for sending the message to the SHE only after the corresponding message is generated by the non-KMS device and sent to the corresponding first or second vehicle-mounted device.

It should be noted that the security verification key KEY_ID in each message refers to the key address (memory slot) of the key used in the calculation of the integrity check code MAC of the command parameter.

The security verification key KEY_ID in each message refers to the key address (memory slot) of the key used in the calculation of the integrity check code MAC of the command parameter.

Among the input or output parameters corresponding to each message, when CMAC calculation is involved, the part of the parameter that is not an integer multiple of 128 bits can be filled according to RFC4493. For example, Mx is the bit stream to be calculated by CMAC after the combination of M1 and M2 (Mx=M1|M2). If the bit length of Mx is not an integer multiple of 128 bits, it needs to be filled according to the definition of RFC4493. The filling method is Mx| "1"|"0...0"m, that is, Mx followed by 1 bit of 1, and then filled with 0 of the least bit, reaching an integer multiple of 128 bits. For example, if Mx is 64bits, 63bits of 0 need to be filled, so that Mx|"1"|"0...0"m can reach an integer multiple of 128bits. This kind of filling is either outside the SHE or inside the SHE. In this application, filling in the SHE is taken as an example for illustration.

The following uses scenarios 3.1 to 3.2 to illustrate how the first key is generated by the SHE of the vehicle when the first key is a long-term key.

In scenario 3.1, a first message is sent to the vehicle's KMS server through a non-KMS device.

In some embodiments, the non-KMS device may be a cloud server, a key management tool, or a terminal for managing keys, etc. The cloud server may perform encryption and integrity-protected security verification on the first message according to the fixed key of the cloud server as a security verification key. In some other embodiments, the non-KMS device may be the CDC or the central control panel of the vehicle. Through the CDC or the central control panel, the user's confirmation operation is received, and the CDC or the central control panel responds to the user's confirmation operation. The CDC or the central control panel The SHE corresponding to the screen can generate the first message according to the fixed key of the vehicle, that is, the CDC or the central control screen can encrypt and integrity protect the first message according to the fixed key of the vehicle. verify.

Initiate the first message to the KMS server of the vehicle through a non-KMS device. For example, when starting the construction of the key system, and the construction status of the current key system is unconstructed or completed, it can be sent by an external device or a non-KMS device. The KMS device generates the first message, and sends the first message to the KMS server of the vehicle. For example, the first message may be encrypted and integrity-protected security verified by the fixed key of the vehicle. Wherein, the first message may indicate which keys are the first keys generated by the KMS server of the vehicle. For example, KEY_13 is used to store a long-term key corresponding to a global navigation satellite system (global navigation satellite system, GNSS) module.

For example, in order to prevent the CDC or the central control panel from being attacked, the CDC or the central control panel can receive the user's response operation and confirm "agree/deny: execute the update of the first key". Scenario 2 After determining the first key to be generated, the first key generation request message can be sent to the CDC or the central control panel. After the user confirms through the CDC or the central control panel, in response to the confirmation operation with the user, the CDC or the central control panel The security verification key is used to return the response message to the long-term key update request of the server. The response message can be encrypted and integrity protected with a fixed key of one vehicle and one secret, and the server sends the response message to the SHE of the server. authenticating. Optionally, the SHE at the server can also determine whether to actively send a first key generation request message to the CDC or the central control panel according to whether the validity period of the first key has expired. When receiving the response message of the first key generation request sent to the CDC or the central control panel as yes, the SHE executes the process of generating the first key.

After the KMS server of the vehicle receives the first message sent by the non-KMS device, it can generate a first request message, and the first request message sends the first request message to the SHE corresponding to the server, wherein the first request message can include the first request message. An identifier of a key, the first request message may be encrypted and integrity-protected based on the security verification key corresponding to the first request message.

The SHE verifies the first request message based on the security verification key corresponding to the first request message, and triggers the generation of an encrypted first key after the verification succeeds. Wherein, the encrypted first key may be encrypted based on a fixed key for one vehicle and one secret stored by the SHE, or may be encrypted by a fixed key stored by the KMS server, and the SHE determines the first When the key is a key used by the KMS server, the first key may be stored. When the SHE determines that the first key is used by the KMS server, it may not store the first key. For example, when the KEYID corresponding to the first key is KEY_13, the SHE stores the first key in the position of KEY_13.

The SHE corresponding to the server verifies the first request message according to the security verification key corresponding to the first request message stored by itself, and generates an encrypted first key after the verification succeeds. Wherein, the encrypted first key may be encrypted based on a fixed key for one vehicle and one secret stored by the SHE, or may be encrypted by a fixed key stored by the KMS server, and the SHE determines the first When the key is a key used by the KMS server, the first key may be stored. When the SHE determines that the first key is used by the KMS server, it may not store the first key. For example, when the first key is KEY_1, the SHE stores the first key in the position of KEY_1.

The following uses a specific example to introduce the first request message. The parameters involved in the first request message CMD_BUILD_KEY may be as shown in Table 8.

Table 8

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	256256
M2M2	ININ	128128
M3M3	OUTout	144144
M4M4	OUTout	256256
M5M5	OUTout	128128
M6M6	OUTout	272272
M7M7	OUTout	128128

Taking the first vehicle-mounted device sending a first request message to the first SHE as an example, the first request message may carry the following input parameters.

Among them, the input parameter M1 satisfies:

Among them, the value of UID can have many kinds, for example, in the first request message, it is used to generate the filling message of the first key sent to the second vehicle-mounted device (carrying the input parameter corresponding to the filling of the first key) , the UID can be the UID of the first vehicle-mounted device or the second SHE, or 0 (ie wildcard UID). When the first request message is used to generate an input parameter of the first key filled in the first vehicle-mounted device, the UID may be the UID of the first vehicle-mounted device or the second SHE.

Flag can occupy 1 byte, and Flag satisfies:

Flag="0...0" ₆ |Hold

Among them, Hold can occupy 1 bit, indicating whether the first SHE holds the first key, that is, whether to store the generated first key in the first SHE. For example, when Hold is 0, it means no storage, and when Hold is 1, it means storage. If yes, after the SHE generates the first key, it first stores it in the memory slot of the SHE, and sets the relevant content of the key, see Table 3 for details. Wherein, the key construction status of the first key may be set as "1-construction successful". If it is not stored, the first key cannot be stored in this SHE.

The memory slot is used to indicate the key address of the SHE first key.

KEY_ID is used to indicate the security verification key of the first request message. For example, in conjunction with scenario 3.1, the input parameter of the first request message generated by the non-KMS device (that is, carried in the first message) may use a fixed key as the security verification key. In combination with scenario 3.2, in the first request message generated after the first vehicle-mounted device obtains the temporary key, the temporary key may be used as the security verification key of the first request message. The value of Counter is the same as the KMS_KH_BuildCounter value of this SHE, which is used for SHE verification replay attacks.

Key index KeyID: can be 4 bytes, used to indicate the key index of the newly generated first key this time. Among them, "[]" means optional. For example, the key indexes corresponding to the on-vehicle devices involved in the secure storage mechanisms of different hardware may be allocated based on services, for example, the corresponding key indexes may be allocated based on KMS. "0...0" m: Indicates that the value "0" occupies m bits, so as to meet the integer multiple of 128 bits for M1 as a whole. If the key index KeyID is not included, fill 76 bits with 0. If it contains the key index KeyID, fill 44 bits with 0.

The input parameter M2 satisfies: M2=CMAC(Key,M1)

Among them, Key is the security verification key corresponding to KEY_ID.

After the first SHE successfully verifies the input parameters of the first request message, it can correspondingly generate the following output parameters and return a first response message to the first vehicle-mounted device. The first response message can include the first Parameters, for example, can carry the following outgoing parameters M3-M7.

The output parameter M3 satisfies: M3=UID|memory slot|KEY_ID

The UID is the same as the UID in the input parameter M1, and the memory slot and KEY_ID are the same as the corresponding values in the input parameter M1. Counter is the KMS_KH_BuildCounter value stored by SHE.

Flags=write-protection|boot-protection|debugger-protection|key-usage|wildcard, the information of Flags can also be carried in the input parameter Flag. Alternatively, the SHE determines the carried content according to the classification of the first key.

The output parameter M4 satisfies:

M4＝ENC _{CBC, K1,IV＝0} (Counter|KeyFlags[|KeyID]|“0…0”m|Key _{memory slot} )

The KeyID is the same as the KeyID in the input parameter. If the input parameter carries the KeyID, the output parameter also carries the KeyID.

Key _{memory slot} is the key value of the first key generated by the first SHE for the memory slot. Since the first key is to be encrypted and distributed by the first vehicle-mounted device to the second SHE, the second vehicle-mounted device does not need to know the value of the key. How the first key is generated. Therefore, when the first SHE generates the first key, there can be various schemes. For example, there are two specific schemes as follows: Scheme 1: Use the random number function in the SHE to generate a random number R1 (128 bits) , and then use a SHE to hold the available secure Key1 to perform CMAC calculation to obtain the Key _{memory slot} . For example, Key _memory _slot = CMAC(Key1, R1). Among them, Key1 can use a fixed key, such as GLOBAL_FIX_KEY, MAC_FIX_KEY and any other key except the temporary key in the first SHE, so as to ensure that it cannot be read by the outside. Alternatively, key1 may be the key corresponding to the key address memory slot1 added in the input parameter of the first request message, and the key may be specified by the user. Solution 2: If the random number is secure enough, the generated random number can also be directly used to generate the first key.

The output parameter M5 satisfies:

M5＝CMAC(K2,M3|M4)

The output parameter M6 satisfies:

M6＝UID|memory slot|KEY_ID|EncyptedValue

The output parameter M7 satisfies:

M7=CMAC(K4,M6)

Wherein, the output parameters M3, M4, and M5 carried in the first response message are respectively the input parameters M1, M2, and M3 of the filling message of the first key. The output parameters M6 and M7 carried in the first response message are respectively the same as the output parameters M4 and M5 in the filling message of the first key. That is, through the first request message, the SHE can obtain the input parameters required to fill the first key and verify the output parameters loaded by the first key. For details, please refer to the input parameters carried in the filling message of the first key and the output parameters after SHE executes the filling message of the first key below.

It should be noted that the outgoing parameter M6 and outgoing parameter M7 can be sent in the first response message, or can be stored in the non-volatile storage area of the SHE, for example, pre-set in the non-volatile storage area of the SHE Reserved for the construction process of the KMS key system, the temporary storage server or agent is the storage location of the shared key between the second vehicle-mounted devices, and the first vehicle-mounted device (for example, the server or agent) receives the first When the filling response message of the first key is returned by the second vehicle-mounted device, the first vehicle-mounted device can obtain M6 and M7 stored in the SHE by verifying the key message.

Scenario 3.2, during the construction of the in-vehicle key system, for example, when the first vehicle-mounted device determines that the current key system construction status is under construction, for example, the first vehicle-mounted device determines the first key to be generated in the key system After multiple keys are included, a first request message may be generated correspondingly according to each first key to be generated. For example, the first key may be a long-term key dedicated to the first vehicle-mounted device, the first key may be a long-term key dedicated to the second vehicle-mounted device, and the first key may be a key between the first vehicle-mounted device and the second vehicle-mounted device. A long-term key used between devices. The first key may be the long-term key corresponding to user 1 using the first vehicle-mounted device, and the first key may be the corresponding long-term key when user 2 uses the first vehicle-mounted device and the second vehicle-mounted device. long term key. When generating the corresponding long-term key, the first request message for the long-term key may be correspondingly generated.

In addition to generating the first message through the non-KMS device to carry the security verification key of the first request message, the first vehicle-mounted device (for example, the server) can also share a temporary key between the first vehicle-mounted device and the first SHE key, as the security verification key of the first request message.

The temporary key can be used for the security verification key between the server and the SHE corresponding to the server during the construction process. Alternatively, a temporary key K _Temp may be shared between the agent and the SHE corresponding to the agent, and the temporary key K _Temp may be used as a security verification key between the agent and the SHE corresponding to the agent during the construction process. Alternatively, a temporary key may be shared between the client and the SHE corresponding to the client, and the temporary key may be used for a security verification key between the client and the SHE corresponding to the client during the construction process.

The temporary key can be based on the first message received by the first vehicle-mounted device from the non-KMS device (the first message is encrypted by a trusted security verification key between the non-KMS device and the server), and the SHE Generated after the first message is validated.

In a possible implementation, the non-KMS device initiates a long-term key generation message (for example, the first message) to the KMS server of the vehicle, and the non-KMS device can use the fixed key of the non-KMS device to generate a long-term key for the first message. Security authentication with encryption and integrity protection. Wherein, the first message may instruct the KMS server of the vehicle to start a long-term key generation process. The KMS server of the vehicle can send a first request message to the SHE of the server according to the first message, and the first request message can be used to request to obtain the temporary key. After the SHE generates the temporary key, it may send a response message to the first message to the first vehicle device, and the response message may carry the temporary key. Here, the temporary key can use the key shared by the server and the SHE corresponding to the server for integrity verification. For example, a message verification code is generated for the temporary key by means of a fixed key for one vehicle, one secret, or the fixed key of the first vehicle device. Therefore, the first vehicle-mounted device can obtain the temporary key after successfully verifying the response message of the first message. The temporary key is used by the server to verify the first response message sent by SHE. At the same time, the first request message generated by the vehicle server may also include requesting the SHE to generate an encrypted first key.

Considering that during the construction of the key system, it is likely that the server needs to generate the first key multiple times, or verify other messages through the server or agent, which may involve the use of temporary keys. At this time, The temporary key should be generated before the corresponding SHE of the vehicle-mounted device (server or agent or client) executes operations such as generating the first key, and the vehicle-mounted device is made to obtain the temporary key. If the temporary key is generated or sent to the vehicle device every time, the security of the temporary key will be affected (API interface monitoring, etc.). In addition, the start message for key system construction should be received before the corresponding SHE of the on-vehicle device performs operations such as generating the first key, so that the SHE can update the key system construction status.

A possible implementation manner of generating a temporary key is specifically introduced below, that is, the first SHE is triggered to generate a temporary key through a key system construction start message. The server receives the key system construction start message generated by the non-KMS device, and distributes the parameters of the key system construction start message to the agent or the vehicle-mounted device of the client. After the vehicle-mounted device receives the key system construction start message, it forwards it to the SHE of the vehicle-mounted device. The SHE can start the construction of the key system according to the key system construction start message. For example, the KMS_KH_BuildCounter value of each vehicle-mounted device is synchronized to prevent encryption The replay attack of the key system construction start message updates the key system construction status message, and makes the SHE of the on-board equipment generate a temporary key accordingly, providing a security verification key for subsequent messages such as the generation of the first key.

The following methods 1 to 2 are used as examples to introduce the possible methods in the startup message of the key system construction.

Mode 1, after the off-vehicle device responds to the user's operation of "confirming and agreeing to perform the first key update", the off-vehicle device constructs a start message for key system construction.

Method 2: After the CDC or the central control panel in the car responds to the user's operation of "confirming and agreeing to perform the first key update", the CDC or the central control panel constructs a key system construction start message. At this time, in order to ensure the safe construction of the startup message of the key system construction, it can be realized in the following ways:

Method 2.1, on the CDC or the central control screen, through other security environments (security environments that do not rely on SHE), such as deploying a trusted execution environment (Trusted execution environment, TEE), or HSM, etc., using a long-term key or a fixed key, to generate the message. It should be noted that, in this secure environment, the long-term key is also stored, for example, a long-term key for one secret per vehicle or a fixed key for one secret per vehicle, etc. are stored.

Mode 2.2, the CDC or the SHE of the central control panel responds to the request message to start the construction of the key system sent by the server or the agent, and returns the response message to the request to start the construction of the key system, such as CMD_KMS_KH_PREPARE_START, so that the CDC or the central The SHE of the control screen generates and returns the start message of building the key system to the server, and the server obtains the start message of building the key system, thereby starting and managing the update of the first key. It should be noted that the response message (CMD_KMS_KH_PREPARE_START) to the request to start the construction of the key system cannot provide a key as the security verification key of the message. Therefore, it is necessary to strictly control the use of this message, such as through identity and access management (IAM), security enhanced Linux (SELinux), process or container security isolation, and mandatory checks when the vehicle stops, etc. only allowed to use.

The following example illustrates a possible implementation of the start message constructed by the key system, for example, as shown in Table 9, the parameters that may be involved in the start message constructed for the key system. Among them, m and n are positive integers.

Table 9

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	mm
M2M2	ININ	128128
M3M3	OUTout	nno
M4M4	OUTout	128128
M5M5	OUTout	128128

Taking the first vehicle-mounted device sending a key system construction start message to the first SHE as an example, the key system construction start message may carry the following parameters.

Among them, the input parameters meet:

M1=KEY_ID|KMS_KH_BuildCounter

M2＝CMAC(Key,M1)

Among them, for the construction of the key system initiated outside the car, it must be the KEY_ID corresponding to the fixed key. For the long-term key update triggered after confirmation by the CDC or the central control screen in the car, it can be the KEY_ID corresponding to the long-term key, such as a KEY_ID of the long-term key of Che Yi Mi. Key is the Key corresponding to KEY_ID. KMS_KH_BuildCounter is the value of the key system construction counter. When the SHE of each vehicle-mounted device executes the start message of the key system construction, this value must be greater than or equal to the value of KMS_KH_BuildCounter in the SHE of the vehicle-mounted device to prevent the key system The build's startup message is used by the replay. If the value of KMS_KH_BuildCounter is less than the value in SHE of this device, ignore this command and return ERC_INVALID_PARAMETER.

After successfully verifying the startup message of the key system construction, the SHE can generate an output parameter of the startup message of the key system construction, and return a response message of the startup message of the key system construction to the first vehicle-mounted device, in the response message Carry out ginseng. Among them, the output parameters meet:

M3=KEY_ID|KMS_KH_BuildCounter1

M4＝CMAC(Key,M3)

M5 = KMS_KH_BuildKTemp

Among them: KMS_KH_BuildCounter1 is the latest value of KMS_KH_BuildCounter in SHE after executing this command. Actually it should be KMS_KH_BuildCounter1=KMS_KH_BuildCounter+1. After this command is executed, SHE will set KMS_KH_BuildStatus to "Building".

KMS_KH_BuildKTemp is a temporary key KTemp generated by SHE after the command is executed successfully, which is used for the security verification key when the on-board equipment directly operates SHE.

In order to simplify the complexity of message sending, the key system construction start message can be designed as a two-layer command. The message can also carry the parameters of other messages, so that after SHE receives the key system construction start message, according to the encryption The key system construction start message is verified, the instruction information for starting the key system construction is obtained, and the key system construction status is updated. Optionally, after receiving the message, the SHE at the server or agent can generate a temporary key accordingly. Further, after constructing the parameters of other messages carried in the startup message according to the key system, the message is verified according to the parameters of other messages and then corresponding operations are performed.

For example, the other message is the first request message, and at this time, the first vehicle-mounted device carries the first request message through the key system construction start message. The first SHE may determine that the key system construction status is under construction after verifying the key system construction start message, and generate a temporary key accordingly. Afterwards, according to the first request message carried in the startup message of the key system construction, the first request message is verified, and after the verification is successful, the encrypted first key is generated, and the encrypted first key is returned to the first vehicle-mounted device and temporary key.

The following example illustrates a possible implementation of the start message for key system construction, as shown in Table 10, for example. Among them, m and n are positive integers.

Table 10

Taking the first on-vehicle device sending the start message of the key system construction to the first SHE as an example, the start message of the key system construction can carry the following parameters and nest parameters corresponding to other messages.

The input parameters meet:

M1=KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_IN_Parameters

M2＝CMAC(Key,M1)

Wherein, KEY_ID is a security verification key used for security verification of the message. For the startup message of the key system construction initiated by the device outside the vehicle, the security verification key must be the KEY_ID corresponding to the fixed key; for the long-term key update triggered after confirmation by the CDC or the central control screen in the vehicle, it can be a long-term key The corresponding KEY_ID is, for example, the KEY_ID of the long-term key of one car one secret. Key is the security verification key corresponding to KEY_ID.

When the KMS_KH_BuildCounter value is smaller than the KMS_KH_BuildCounter value in the first SHE, it is determined that the verification of the start message of the key system construction fails, and the start message of the key system construction is ignored, and the error message ERC_INVALID_PARAMETER is returned.

When the KMS_KH_BuildCounter value is greater than the KMS_KH_BuildCounter value in the first SHE, it means that the replay attack verification is successful, and at this time, M2 can be verified.

CMD_TYPE indicates the message type of the message. When CMD_KMS_KH_BUILD_START and CMD_KMS_KH_BUILD_CONTINUE do not carry other messages, CMD_TYPE can be filled with 0. For example, other messages that can be carried in the startup message constructed by the key system of this application can be shown in Table 11.

Table 11

It should be noted that other messages contained in the key system construction startup message may only be sent to a specific on-board device or some on-board devices in the vehicle, and other on-board devices will not process it. At this time, specific range sharing, Or a fixed key held by a specific on-vehicle device performs security verification on the message containing the business function. When constructing the message of the business function, the key system building start message can be sent to the server and the agent through the KMS business message, and the key system building start message can also be sent to the server and the agent whether it needs to be distributed, Information such as which clients are distributed to, whether the server and the agent need to be processed.

In some embodiments, when the message received by the first SHE contains a message that cannot be processed, the message is directly ignored, and an error message ENC_CANNOT_PROCESS_INNER_CMD is returned.

In some embodiments, the security verification key KEY_ID of the startup message constructed by the key system may be the same as or different from the security verification key KEY_ID' used in other messages carried in the message. Wherein, the security verification key KEY_ID' used in other messages carried in the message can be selected according to the requirements of the message or actual needs.

CMD_TYPE can occupy 1 byte, indicating whether the start message of the key system construction carries other messages. CMD_TYPE_IN_Parameters: CMD_TYPE corresponds to all input parameters of other messages. At this time, the CMD_TYPE value is not 0.

After successfully verifying the startup message of the key system construction, the SHE can generate an output parameter of the startup message of the key system construction, and return a response message of the startup message of the key system construction to the first vehicle-mounted device, in the response message Carry out ginseng. Among them, the output parameters M3~M5 can meet:

M3=KEY_ID|KMS_KH_BuildCounter1|CMD_TYPE|CMD_TYPE_OUT_Parameters

M4＝CMAC(Key,M3)

M5 = KMS_KH_BuildKTemp

Among them, KMS_KH_BuildCounter1 is the updated value of KMS_KH_BuildCounter in SHE after verifying the startup message of key system construction. For example, KMS_KH_BuildCounter1 satisfies: KMS_KH_BuildCounter1=KMS_KH_BuildCounter+1.

CMD_TYPE_OUT_Parameters are all output parameters of the message corresponding to CMD_TYPE.

KMS_KH_BuildKTemp is a temporary key KTemp generated by SHE after the startup message verification of key system construction is successful. The security authentication key for the keyload message. At the same time, SHE can set KMS_KH_BuildStatus to "Building" after successfully verifying the message. SHE sets Counter to the latest value of KMS_KH_BuildCounter.

In the scenario where the startup message constructed by the key system carries the first request message, consider some embodiments where the first vehicle-mounted device generates the first request message, that is, the parameters of the first request message can send the first query request to the SHE through the server To obtain, for example, the first query message CMD_KMS_KH_GET_BUILD_STATUS can be used to query status data such as input parameters of KMS_KH_BuildCounter and CMD_BUILD_KEY. The security verification of the first query message can be performed through the temporary key. A possible implementation of the first query message (CMD_KMS_KH_GET_BUILD_STATUS) is described below as an example. The relevant parameters of the first query message may be shown in Table 12.

Table 12

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	88
M2M2	ININ	128128
M3M3	OUTout	208208
M4M4	OUTout	128128

The first query message may be initiated by a device outside the vehicle, or may be initiated by a vehicle-mounted device such as a first vehicle-mounted device or a second vehicle-mounted device in the vehicle.

In some embodiments, the first vehicle-mounted device may check the construction status of the key system when starting, so that the first vehicle-mounted device can determine the next operation according to the current construction status of the key system, for example, the current construction status If part of the first key has been constructed, the first vehicle-mounted device may initiate a first request message for other first keys to be generated to the SHE. In the current construction state, a part of the first key has been constructed, including the successful construction of the first key 1 and the failed construction of the first key 2, then the first on-board device can initiate the generation of the first key 2 to the SHE The first request message for .

In some embodiments, when the first vehicle-mounted device determines that the first key is a key to be updated, it may send a first query message to the first SHE for querying information such as KMS_KH_BuildCounter and corresponding message input parameters, Used to generate corresponding messages. For example, the first vehicle-mounted device can send a first query message to the first SHE, and read the current key system construction status, construction count, date of the last successful construction, and the verification code MAC of the construction status data from the SHE. .

Taking the first query message sent by the first vehicle-mounted device to the first SHE as an example, the first query message may carry the following parameters M1 and M2.

The input parameter M1 satisfies: M1=KEY_ID

Wherein, KEY_ID is the security verification key used for the first query message. Therefore, for the first query message initiated by the device outside the vehicle, the KEY_ID is a fixed key; when a non-KMS device in the vehicle, such as a CDC or a central control panel, triggers a long-term key update, for example, when sending the first The query initiated before the message can be a long-term key or a fixed key. In some other embodiments, the first query message initiated by the first vehicle-mounted device or the second vehicle-mounted device may use a temporary key generated by the corresponding SHE as the security verification key. It should be noted that KEY_ID can be 0. If it is 0, it means that there is no key query. At this time, M1 in the input parameter does not contain MAC (that is, does not contain M2). Correspondingly, M4 is not included in the output parameters.

The input parameter M2 satisfies: M2=CMAC(Key,M1)

That is, enter the parameter M2 as the security verification code, and Key is the security verification key corresponding to KEY_ID.

After the SHE successfully verifies the input parameters in the first query message, it can generate corresponding output parameters and return the first query response message. For example, taking the first SHE as an example, the first vehicle-mounted device sends a first query message to the first SHE, and after the first SHE successfully verifies the input parameters in the first query message, it can generate corresponding output parameters M3 and M4, And return the first query response message to the first vehicle-mounted device.

Among them, the output parameter M3 satisfies:

M3=KEY_ID|KMS_KH_BuildStatus|KMS_KH_BuildCounter|KMS_KH_BuildDate|KMS_KH_BuildMac

The output parameter M4 satisfies:

M4＝CMAC(Key,M3)

After receiving the first query response message, the first vehicle-mounted device may verify the output parameters in the first query response message, and obtain the query content in the output parameters after the verification is successful, for example, KMS_KH_BuildStatus, KMS_KH_BuildCounter, KMS_KH_BuildDate, KMS_KH_BuildMac.

After step 304, after receiving the first response message from the first SHE, the first vehicle-mounted device may correspond to the filled vehicle-mounted device according to the first key, for example, may be the second vehicle-mounted device. Wherein, the second vehicle-mounted device may be the first vehicle-mounted device, or other vehicle-mounted devices in the vehicle. The second in-vehicle device may be a server, an agent, or a client, which is not limited here.

The following takes the second vehicle-mounted device as another vehicle-mounted device other than the first vehicle-mounted device as an example for description. As shown in Figure 4, the following steps are included:

Step 401: the first vehicle-mounted device receives the first parameter of the first key sent from the first SHE.

Wherein, the first vehicle-mounted device obtains the first parameter of the first key according to the received first response message. For specific first parameters, reference may be made to M3-M5 in the above-mentioned first response message, which will not be repeated here.

Step 402: The first vehicle-mounted device generates a first key loading message according to the first parameter of the first key.

Wherein, the first key loading message is used for filling the first key after the second in-vehicle device successfully verifies the first key loading message.

Step 403: the first vehicle-mounted device sends a first key loading message to the second vehicle-mounted device.

For example, the first vehicle-mounted device may be a KMS server or a KMS agent. The second in-vehicle device may be a KMS client or a KMS agent. For example, when the first vehicle-mounted device is a server and the second vehicle-mounted device is a client, the first vehicle-mounted device may send a first key loading message to the second vehicle-mounted device, or the first vehicle-mounted device may send a first key loading message to the agent. The key loading message, and the agent forwards the first key loading message to the second vehicle-mounted device.

For another example, when the first vehicle-mounted device is a server and the second vehicle-mounted device is an agent, the first vehicle-mounted device may send a first key loading message to the second vehicle-mounted device. Optionally, the second vehicle-mounted device may also deliver the first key loading message to the client managed by the second vehicle-mounted device.

For another example, when the first vehicle-mounted device is an agent, the first vehicle-mounted device can receive the first key loading message forwarded by the server, and can also send the first key to the second vehicle-mounted device managed by the first vehicle-mounted device Load the message. For another example, when the first vehicle-mounted device is an agent, the first vehicle-mounted device may generate a first key loading message, and send the first key loading message to a second vehicle-mounted device that may be managed by the first vehicle-mounted device.

Step 404: The second vehicle-mounted device sends the first key loading message to the second SHE according to the received first key loading message.

Step 405: After successfully verifying the first key loading message, the second SHE generates a first key loading response message.

Step 406: The second SHE sends a response message of loading the first key to the second vehicle-mounted device, and the second vehicle-mounted device forwards the response message of loading the first key to the first vehicle-mounted device.

Step 407: The first vehicle-mounted device generates a filling verification message of the first key according to the response message loaded with the first key.

Step 408: the first vehicle-mounted device sends a filling verification message of the first key to the first SHE.

Step 409: After successfully verifying the first key loading verification message, the first SHE feeds back the verification result to the first vehicle-mounted device.

Step 4010: The first vehicle-mounted device updates the state information of the first key according to the verification result fed back by the first SHE, and generates a verification code of the state data accordingly.

Step 4011: the first vehicle-mounted device sends a status update message to the first security hardware expansion unit.

Wherein, the state update message includes: the construction state of the in-vehicle key; the state update message is used for the first security hardware expansion unit to update the construction state of its own in-vehicle key after the verification of the state update message is successful.

It should be noted that the construction state of the in-vehicle key may be the construction state of the key system or the construction state of the first key, which is not limited here.

Step 4012: The first SHE verifies the status update message, and updates the security verification code of the status data after the verification is successful.

The messages involved in each step are described in detail below.

In step 401, the first response message received by the first vehicle-mounted device may carry the input parameters and output parameters of the first key loading message, that is, the output parameters carried in the first response message include M1-M7. Wherein, the output parameters M3-M5 are the first parameters of the first key, that is, the input parameters M1-M3 corresponding to the first key loading message.

Among them, the input parameters corresponding to the first key loading message satisfy:

M1＝UID|memory slot|KEY_ID

M2＝ENC _{CBC, K1, IV＝0} (Counter|Flags[|KeyID]|“0…0”m|Key _{memory slot} )

M3=CMAC(K2,M1|M2)

Among them, when the UID is 8 bits in the Memory Slot, the UID can be 128 bits. When the first key loading message is used to store the exclusive key of the first vehicle-mounted device in the SHE of the first vehicle-mounted device, such as GLOBAL_FIX_KEY, when other vehicle-mounted devices do not obtain the key, the UID may not be 0, and the UID It is the special identifier of the first vehicle-mounted device. When the first key loading message is stored in the first SHE, and the first key should also be filled into the second vehicle-mounted device, the UID should be 0 (ie wildcard UID).

Key _{memory slot} is the first key. The memory slot is used to indicate the key address of the first key storage. KEY_ID is used to indicate the security verification key of the first key loading message, and is used to derive the key identifier of the key of K1 and K2. K1 and K2 are the encryption key and integrity calculation key derived from the key corresponding to KEY_ID. The derivation method refers to the existing SHE specification and will not be repeated here. The selection of the security verification key can be determined based on Table 7. For example, the input parameters M1-M3 of the first key loading message (that is, the output parameters M3-M5 of the first response message) are generated by the first SHE, then the security verification The key can be a fixed key for one vehicle, one secret, a long-term key for one vehicle, or the first key before updating, etc. Counter is a key update count value corresponding to the first key, which may be 28 bits. During SHE processing, it may first be checked whether this value is greater than the Counter value of the first key to be updated in the storage area corresponding to the memory slot. If the KMS key system is currently being built, that is, the KMS_KH_BuildStatus value is "1-under construction", it is also necessary to check whether this value is the same as the KMS_KH_BuildCounter value in SHE.

Optionally, KeyID can also be included, which is used to indicate the key index of the key corresponding to the memory slot (not the Memory Slot). If this field is included, it cannot be 0. "0...0"m: Fill the field with 0, used for block encryption alignment. Since the block length is 128 bits during AES_CBC_128 encryption, if the KeyID is not included, "0...0"m needs to be filled with 94 bits of 0. If KeyID is included, "0...0"m needs to be filled with 62 bits of 0.

In step 405, after the second SHE successfully verifies the input parameters carried in the first key loading message, it can correspondingly generate a first key loading response message, and the first key loading response message can carry the first The output parameters of the key loading message, where the output parameters M4 and M5 satisfy:

M4＝UID|memory slot|KEY_ID|EncyptedValue

M5=CMAC(K4,M4)

Among them, the UID in M4 is the same as the description of the input parameter, and the value of M4 is also the same as the input parameter. Correspondingly, the memory slot and KEY_ID are also the same as the values in the input parameters. It should be noted that the key corresponding to the KEY_ID is not used for encryption and/or integrity calculation of the output parameters of the response message loaded with the first key. The output parameters may be encrypted and/or integrity calculated according to the updated first key, see the description below.

EncyptedValue = ENC _{CBC, K3, IV = 0} (Counter|"1" ₁ [|KeyID]|"0...0"n).

Wherein, K3 is an encryption key derived from the first key. Counter is the same as the Counter value of the input parameter. "1" ₁ indicates that the value "1" occupies 1 bit, "0...0" n: indicates that the value "0" occupies n bits. KeyID is optional and is used to indicate the key index of the first key. If this field is included in the input parameter, it must be included here. 32 bits. For AES_CBC_128 encryption, the block length is 128 bits. For example, if KeyID is not included, 99 bits of 0 are filled. When KeyID is included, 67 bits of 0 are filled. K4 is the integrity calculation key derived from the first key. For the derivation method, refer to the description of the existing SHE specification. After the first key loading message is successfully verified, the second SHE sets the build status BuildStatus of the first key to "1—build successfully".

In step 406, the parameters of the filling verification message of the first key may be as shown in Table 13.

Table 13

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	272272
M2M2	ININ	128128

Wherein, the filling verification message of the first key may carry an output parameter of the filling response message of the first key. That is, the input parameters satisfy:

M1＝UID|memory slot|KEY_ID|EncyptedValue

M2=CMAC(K4,M1)

The first vehicle-mounted device passes the M4 and M5 of the output parameters of the filling response message of the first key from the second vehicle-mounted device to the SHE for verification through the filling verification message of the first key, and confirms the identity of the second vehicle-mounted device. Whether the filling of the first key is successfully completed, and return the verification result to the first vehicle-mounted device.

Wherein, the security verification key of the filling response message of the first key may be a temporary key between the first vehicle-mounted device and the first SHE.

In step 409, the first vehicle-mounted device updates the state information of the first key according to the verification result fed back by the first SHE, and generates an integrity verification code MAC of the state data accordingly.

During the generation process of the first key, the first vehicle-mounted device or the second vehicle-mounted device needs to continuously update the state data in the process of building the current key system, for example, the state data of the first key or the state data of the key system , safely stored in non-volatile memory. The stored status data of the first key may include: the construction status of the key, the construction type, the communication security domain to which the first key is currently constructed, the in-vehicle device corresponding to the constructed first key, and the like. For example, stored state data may include:

The flag KMSBuildStatusFlag of the build status is used to mark the build status of the key system, such as unbuilt, under construction, and completed.

The build type flag KMSBuildTypeFlag is used to mark the current initial key system construction, long-term key update, or key system reconstruction for vehicle equipment replacement. This flag is only useful if KMSBuildStatusFlag is building.

The mark KMSBuildStageFlag of the construction stage is used to mark the current one-vehicle-one-key fixed key filling, one-vehicle-one-key long-term construction or update, the construction stage or update stage of each communication security domain, etc.;

Of course, some information can also be added, such as which vehicle-mounted device is currently built into which communication security domain, etc.

In this application, in order to ensure the security of the state data, the integrity protection of the state data can be protected, and the encryption protection is optional. In the following, the state data without encryption protection, the integrity key and the integrity MAC can be stored in a secure Store scene.

When the KMS is running, the integrity check code MAC that can be generated for the above updated state data can be stored in the SHE after being verified by the temporary key.

In a possible implementation, a temporary key KTemp can be generated by the SHE through the startup message constructed by the key system, and returned to the on-vehicle device. During the process of constructing the key system of the vehicle equipment, the temporary key K _Temp is jointly held by the KMS and the SHE. A possible implementation manner, the temporary key KTemp may use a symmetric key. It can avoid KMS (ordinary operating environment, if it is a trusted operating environment, it is better, such as isolated operation) key during the operation process that SHE may not trust, and improve the security of state data storage. Alternatively, an asymmetric signature algorithm can be used to temporarily generate a pair of public and private keys, and the temporary public key is returned to KMS. Considering that the key may be obtained by other attacker software, the asymmetric algorithm will not enhance security, but will reduce the calculation performance of MAC.

Integrity protection through the temporary key can enable the SHE to perform integrity protection through the temporary key when updating the relevant information of the first key (for example, integrity MAC, status data, etc.), and improve tamper-resistant performance.

The temporary key KTemp can also be stored in the non-volatile storage area of the SHE. For example, during the key construction process, if the device restarts abnormally, when the vehicle device restarts to continue the key system construction, it needs to complete the verification with SHE again. At this time, SHE can return the originally allocated KTemp to KMS. It is of course also possible to assign a new temporary key. That is, during a key system construction process, KTemp can remain unchanged or can be changed as needed. If it changes, it is necessary to ensure the smooth switching of the old and new temporary keys (KTemp_New, KTemp_Old)—for each content encrypted and integrity-protected using the old temporary key KTemp_Old, it needs to be replaced with the new temporary key KTemp_New before The old temporary key KTemp_Old can be deleted.

The storage of the state data during the construction of the key system can be encrypted and stored in a common storage area. For example, the KMS server or agent agent in the car uses the KTemp derives the encryption key and integrity key, encrypts the state data, and stores it in the common storage area. Generate a new MAC based on the encrypted data, and then use CMD_KMS_KH_UPDATE_BUILDSTATUS to store it in KMS_KH_BuildMac of SHE. The key state data in the KMS key construction process can also be directly and securely stored inside the SHE. For example, it is enough to expand and reserve the storage area for storing the process state data of KMS in SHE, for example, reserve 100 Bytes. SHE may not perceive the specific meaning of the state data.

In step 409, the first vehicle-mounted device may send a status update message to the first SHE.

The following example illustrates the parameters that can be involved in the status update message CMD_KMS_KH_UPDATE_BUILDSTATUS. As shown in Table 14.

Table 14

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	168168
M2M2	ININ	128128

Take this message as an example to store the security check code MAC of the build status information in KMS_KH_BuildMac of SHE. The input parameters of this message meet the following requirements:

M2＝CMAC(Key,M1)

Key is a security verification key whose KEY_ID is a status update message, such as a temporary key.

Among them, the input parameters meet:

M1=KEY_ID|KMS_KH_BuildCounter|MAC

Among them, KEY_ID may be the key address of the temporary key. MAC is a security check code generated based on the current key system construction status data using a temporary key. For example, if the status data is KMSBuildStatusData={KMSBuildStatusFlag|KMSBuildTypeFlag|KMSBuildStageFlag|…}, then the security check code satisfies:

MAC = CMAC(Key, KMSBuildStatusData). KMS_KH_BuildCounter is the KMS_KH_BuildCounter value in SHE to prevent replay attacks of this command. For example, if the KMS_KH_BuildCounter value is not equal to the value in the first SHE, ignore the status update message and return ERC_INVALID_PARAMETER. If the current saved value of KMS_KH_BuildMac in MAC and SHE is the same, it indicates that the state data does not need to be updated. At this time, ignore the state update message and return ENC_REPEAT_STORE_SAME_DATA.

Scenario 4: During the construction of the key system, the first vehicle-mounted device or the second vehicle-mounted device may restart abnormally. After the first vehicle-mounted device or the second vehicle-mounted device restarts, the first vehicle-mounted device or the second vehicle-mounted device can Re-verified by SHE to obtain a temporary key, which can be a temporary key generated before restarting, or a temporary key regenerated for the on-board device. After the first vehicle-mounted device or the second vehicle-mounted device and the corresponding SHE obtain the temporary key, the integrity of the stored state data can be verified, and then the construction of the key system can be continued to avoid the failure of the first or second vehicle-mounted device. Restarting causes the construction of the key system to be restarted, improving the robustness of the key system construction.

In a possible implementation, after the first vehicle-mounted device or the second vehicle-mounted device restarts abnormally, the first query message may also be sent to the first SHE through the first vehicle-mounted device (for example, the server or agent) to notify the SHE to verify the restart The MAC that previously stored the key state data, after the verification is successful, securely reads the progress of the key system construction before the restart from the SHE, that is, returns the state data of the key system construction. After the first vehicle-mounted device or the second vehicle-mounted device obtains the temporary key, the temporary key generated by the SHE for this build can be used for security verification. If the verification fails, when the first vehicle-mounted device is the agent, the first query request can be sent to the server to obtain the construction status of the key system; when the first vehicle-mounted device is the server, then confirm the construction of the key system If it fails, you can restart the construction of the key system. The parameters of the first query message can be referred to in Table 12, and will not be repeated here.

As shown in FIG. 5 , it is a schematic flowchart of a method for generating a key in a restart scenario provided by the present application. Taking the restart of the first vehicle-mounted device as an example, the following steps are included:

Step 501: After the first vehicle-mounted device determines to restart, it sends a first query request to the first SHE; the first query request is used to query the second parameter of the first key.

For example, the first vehicle-mounted device may be a KMS server or a KMS agent. For example, when the first vehicle-mounted device is a server, the first vehicle-mounted device may send a first query request to the first SHE. At this time, the first SHE is the SHE corresponding to the first vehicle-mounted device.

For another example, when the first vehicle-mounted device is an agent, the first vehicle-mounted device can send a first query request to the SHE corresponding to the first vehicle-mounted device, and after verifying the first query request through the SHE corresponding to the first vehicle-mounted device, return First query response. Alternatively, the first vehicle-mounted device may send the first query request to the server, and return the first query response after verifying the first query request through the SHE of the server. At this time, the first SHE is the SHE corresponding to the server.

Step 502: The first SHE generates a first query response message according to the first query request; the first query response message is returned after the first security hardware extension unit verifies the first query request; the first query response message includes: The second parameter of a key.

Step 503: the first SHE sends a first query response message to the first vehicle-mounted device.

Scenario 4.1, the first query message of the first vehicle-mounted device can also be used to obtain a temporary key, that is, the first security hardware expansion unit sends the temporary key to the first vehicle-mounted device; where the temporary key is used to encrypt the first request message .

When verifying the message, the first SHE can judge whether the current key system construction status KMS_KH_BuildStatus is "under construction". Reject if not. After verifying the restart message and the first query message, the first SHE may return a restart response message constructed by the key system, and the restart response message constructed by the key system carries the first query response message. Wherein, the first query response message may carry a temporary key.

In Scenario 4.2, the first vehicle-mounted device determines, according to the first query response, that the operation of generating the first key is currently being performed.

In some embodiments, the first vehicle-mounted device generates the first request message according to the second parameter of the first key and the first message; the first key is the key to be generated by the first security hardware expansion unit before restarting. The first secure hardware expansion unit generates an encrypted first key according to the first request message.

In a possible implementation, after it is determined that the first vehicle-mounted device is restarted, the first vehicle-mounted device may notify the first SHE of the restart status of the first vehicle-mounted device, and notify the first SHE to continue building the key system before restarting, At this time, a restart message of key system construction may be sent to the first SHE. It is used for the first in-vehicle device to reacquire the security verification key and the state of the key system construction. For example, for the server, the restart message can use a fixed key as the security verification key, which can be found in the startup message of the key system construction, and will not be repeated here. For the agent, the restart message can use a fixed key or a temporary key used in the current period as the security verification key, and the security verification key can come from the key sent from the server to the agent. For the agent, the restart message can use a fixed key or a temporary key used in the current period as the security verification key, and the security verification key can come from the key sent to the client by the server or the agent.

It should be noted that the first query request may be sent in a manner referring to the first query request above, or may be sent in a manner in which a restart message constructed through a key system carries the first query request.

In a possible implementation manner, the first on-vehicle device may send a restart message of key system construction to the first SHE, carrying the first query message. The first SHE may send the ephemeral key in the first query response. In a possible implementation manner, the first vehicle-mounted device may send a restart message of key system construction to the first SHE, carrying the first request message.

The following describes in detail the possible implementation of the restart message of the key system construction. The restart message of key system construction must be executed after the start message of key system construction and before the end message of key system construction. Specifically, it can be verified through the parameters of the key system construction. As shown in Table 15, the restart message for key system construction may involve the following parameters.

Table 15

Taking the first vehicle-mounted device as an example, the first vehicle-mounted device can trigger a restart message constructed by the key system through an external device. For example, the restart message generated by the server, APP, CDC or the central control screen can The parameters are required and passed to the server. The server generates the restart message of the key system construction from the message and sends it to the first SHE. The first SHE verifies the restart message of the key system construction. After verification, the key system is generated. The output parameters corresponding to the restart message of the construction, and correspondingly generate the restart response message of the key system construction, and the response message carries the output parameters corresponding to the restart message of the key system construction.

In some embodiments, the restart message may or may not carry other messages. For details, please refer to

For other carried messages, reference may be made to Table 11, which will not be repeated here. The parameters carried in the restart message of key system construction may include M1 and M2.

The input parameter M1 satisfies:

M1=KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_IN_Parameters

The input parameter M2 satisfies:

M2＝CMAC(Key,M1)

Among them, Key is the security verification key, that is, the key corresponding to KEY_ID. For the start message of the key system construction initiated by the device outside the vehicle, and correspondingly, the restart message of the key system construction initiated by the device outside the vehicle, the KEY_ID is the KEY_ID corresponding to the fixed key. For the CDC or central control screen confirmation in the car The long-term key update triggered later may be the KEY_ID corresponding to the long-term key, for example, the KEY_ID of the long-term key for one car one encryption.

CMD_TYPE indicates whether the restart message of the key system construction carries other messages. For details, refer to Table 11, which is an example of the startup message of the key system construction carrying other messages. CMD_TYPE_IN_Parameters: CMD_TYPE corresponds to all input parameters of other messages. At this time, the value of CMD_TYPE cannot be 0.

KMS_KH_BuildCounter is the value of the key system build count. When the first SHE corresponding to the first vehicle-mounted device executes the restart message of the key system construction, the value of KMS_KH_BuildCounter in the restart message of the key system construction must be equal to the value of KMS_KH_BuildCounter in the first SHE, and the KMS_KH_BuildStatus in the SHE must be "Building", it is determined that the first SHE corresponding to the first vehicle device successfully verifies the restart message of the key system construction; otherwise, the first SHE corresponding to the first vehicle device fails to verify the restart message of the key system construction. For example, if the KMS_KH_BuildCounter value in the key system construction restart message is not equal to the KMS_KH_BuildCounter value in the first SHE, ignore the key system construction restart message and return ERC_INVALID_PARAMETER. For details, please refer to the verification method of the startup message of the key system construction, which will not be repeated here.

After the first SHE corresponding to the first vehicle-mounted device successfully verifies the restart message of the key system construction, the first SHE corresponding to the first vehicle-mounted device can generate a response message for the restart of the key system construction, and the response message can carry the following information: Refer to M3~M5.

Among them, the output parameter M3 satisfies:

M3=KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_OUT_Parameters

The output parameter M4 satisfies: M4=CMAC(Key,M3)

The output parameter M5 satisfies: M5=KMS_KH_BuildKTemp

Among them, CMD_TYPE_OUT_Parameters: is all the output parameters corresponding to CMD_TYPE.

KMS_KH_BuildKTemp may be a temporary key KTemp generated by the start message of key system construction before restart, or a new temporary key generated by the first SHE for the restart message of key system construction.

It should be noted that, compared with the start message of key system construction, after the first SHE corresponding to the first vehicle device successfully verifies the restart message of key system construction, the value of KMS_KH_BuildCounter in the SHE remains unchanged.

Considering that each time the start message of key system construction is executed, the corresponding SHE will increase the locally stored KMS_KH_BuildCounter by 1 when starting the key system construction. After the construction of the first key is completed (for example, the execution of the first request message, or the success of the first key loading message), the Counter field corresponding to the first key is set to the value of KMS_KH_BuildCounter. Therefore, after the first vehicle-mounted device or the second vehicle-mounted device is restarted, the state of key generation can be determined by obtaining the state data of the key system, especially for the first key that has been generated but not yet loaded before the restart. At this time, the server or agent can obtain the first parameter of the first key from the corresponding SHE, generate the first key loading message, and continue to send the first key to each client or agent that has not obtained the first key. distribution without having to restart the operation that built the first key.

As shown in FIG. 6 , it is a schematic flowchart of a method for generating a key in a restart scenario provided by the present application. Taking the restart of the second in-vehicle device as an example, the following steps are included:

Step 601: The second vehicle-mounted device sends a second message to the first vehicle-mounted device; the second message is used for at least one of the following: querying the second parameter of the first key, requesting the first vehicle-mounted device to generate the first key, or instructing the first vehicle-mounted device to Second, the on-board equipment restarts.

In some embodiments, the second in-vehicle device may be a KMS client or a KMS proxy. For example, when the first vehicle-mounted device is a server and the second vehicle-mounted device is a client, the second vehicle-mounted device can send a second message to the first vehicle-mounted device, or the second vehicle-mounted device can send a second message to the agent, and The proxy end forwards the second message to the first vehicle-mounted device.

For another example, when the first vehicle-mounted device is the server and the second vehicle-mounted device is the agent, the second vehicle-mounted device may send the second message to the first vehicle-mounted device. Optionally, the second vehicle-mounted device may also receive a second message from a client managed by the second vehicle-mounted device.

Step 602: the first vehicle-mounted device sends a verification message of the second message to the first SHE.

Wherein, the first SHE is the SHE corresponding to the first vehicle-mounted device.

Step 603: After verifying the verification message of the second message, the first SHE returns a verification response message of the second message to the first vehicle-mounted device.

The verification of the second message by the first in-vehicle device is realized through steps 602 and 603 .

Step 604: The first vehicle-mounted device sends a third message to the second vehicle-mounted device according to the verification response message of the second message; the third message includes at least one of the following items: the second parameter of the first key and the information of the first key.

For example, when the first vehicle-mounted device is a server and the second vehicle-mounted device is a client, the first vehicle-mounted device can send a third message to the second vehicle-mounted device, or the first vehicle-mounted device can send a third message to the agent , and forward the third message to the second in-vehicle device by the agent.

For another example, when the first vehicle-mounted device is the server and the second vehicle-mounted device is the agent, the first vehicle-mounted device may send the third message to the second vehicle-mounted device. Optionally, the second vehicle-mounted device may also send a third message to the client managed by the second vehicle-mounted device.

For another example, when the first vehicle-mounted device is an agent, the first vehicle-mounted device may receive the third message forwarded by the server, and may also send the third message to the second vehicle-mounted device managed by the first vehicle-mounted device. For another example, when the first vehicle-mounted device is an agent, the first vehicle-mounted device may generate a third message, and send the third message to a second vehicle-mounted device that may be managed by the first vehicle-mounted device.

The following uses scenarios 5.1 to 5.2 as examples to illustrate the above process.

In scenario 5.1, the second message sent by the second vehicle-mounted device to the first vehicle-mounted device is the first query message.

For the restart of the second in-vehicle device, after the restart, after the secure tunnel is established successfully, the first in-vehicle device (for example, an agent or server) generates a message sent to the first SHE according to the input parameters of the first query message. The verification message of the first query message, the verification message of the first query message carries the input parameter of the first query message, and after passing the first SHE verification, returns the output parameter of the first query response message (that is, the verification response of the second message information).

It should be noted that the security verification key of the first query message may be the key used between the first vehicle-mounted device and the second vehicle-mounted device, and the security verification key of the verification message of the second message may be the key used between the first vehicle-mounted device and the second vehicle-mounted device. The key used between the first SHEs.

Correspondingly, the first vehicle-mounted device may generate a third message to be sent to the second vehicle-mounted device according to the output parameter of the first query response message, the third message carries the output parameter of the first query response message, and sends the third message to For the restarted second vehicle-mounted device, the second vehicle-mounted device obtains the output parameters of the first query response message after verifying the third message. It should be noted that the security verification key of the third message may be the key used between the first vehicle-mounted device and the second vehicle-mounted device, and the security verification key of the verification response message of the second message may be the key used between the first vehicle-mounted device and the second vehicle-mounted device. The key used between the first SHEs. For specific input parameters and output parameters of the first query response message, refer to the first query response message above.

In scenario 5.2, the second message sent by the second vehicle-mounted device to the first vehicle-mounted device is a request message for the first key.

When the second in-vehicle device is an agent, the restarted agent can send the first query message to the first in-vehicle device (server) to trigger the service end to return the first query response message, and the agent can report to the agent managed by the agent. The client sends the first query response message, so that each client completes the verification with the SHE corresponding to the client, and obtains the corresponding temporary key or status data, etc., to continue the construction of the key system.

Correspondingly, the first vehicle-mounted device generates a first key loading message according to the first key request message.

Considering that the first key may have been generated during the restart process of the second vehicle-mounted device, or it has not been generated after the restart of the second vehicle-mounted device, the following uses scenarios 5.2.1 to 5.2.2 as examples for illustration.

Scenario 5.2.1, in some embodiments, the first vehicle-mounted device generates a first key loading message according to the second parameter of the first key and the first message; the first key is the first secure hardware expansion unit before restarting generated key. Therefore, the first vehicle-mounted device can send the first key loading message to the second vehicle-mounted device. In a possible implementation manner, the second vehicle-mounted device may carry the first query message in the restart message constructed by the key system.

Scenario 5.2.2, in some embodiments, the first vehicle-mounted device generates the first request message according to the second parameter of the first key and the first message; and sends the first request message to the first SHE, and the SHE verifies the first request message. After a request message, a first response message is generated, where the first response message carries a first parameter of the first key. Therefore, after the first vehicle-mounted device receives the first response message, it generates a first key loading message according to the first parameter of the first key, and sends it to the second vehicle-mounted device, so that the second vehicle-mounted device loads the first key key. Wherein, the first request message may be carried in the restart message of key system construction and sent.

In the key system construction scenario, for example, after the start message of the key system construction is executed, the first vehicle-mounted device executes the second query message to query the state data of the key, and the state data of the key may include: the key of the key information such as marking, querying whether the key forms a pair, etc. For details, reference may be made to the above status data, which will not be repeated here. To ensure the security of the key, the second query message cannot query the content of the key.

For another example, the server may not know whether the second on-vehicle device has been loaded or filled. At this time, the user can trigger the key verification process through the key management tool. For example, the off-vehicle device can trigger the server to send the SHE A second query message is sent to obtain the loading status of the first key.

In another possible scenario, when the first vehicle-mounted device or the second vehicle-mounted device is started, the first vehicle-mounted device or the second vehicle-mounted device checks whether the construction state of the key is completed. For example, if the construction status of the key is not completed, report to the police, prohibit the vehicle from driving, etc. In another possible scenario, after the first vehicle-mounted device or the second vehicle-mounted device restarts, the first vehicle-mounted device or the second vehicle-mounted device sends a second query message to query the loading status of the first key.

The parameters that may be involved in the second query message are introduced with examples below. For example, as shown in Table 16.

Table 16

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	1616
M2M2	ININ	128128
M3M3	OUTout	(13，或24)8(13, or 24)8
M4M4	OUTout	128128

Taking the first vehicle-mounted device as an example, the first vehicle-mounted device may generate an input parameter of the second query message. Among them, the input parameter M1 satisfies:

M1＝KEY_ID|memory slot1

The input parameter M2 satisfies: M2=CMAC(Key,M1)

Wherein, memory slot1 is used to represent the key of the query corresponding to the second query message.

In a possible scenario, KEY_ID is the security verification key of the second query message, and Key is a key corresponding to KEY_ID. For example, after the start message of key system construction is executed, during the key system construction process, when the first vehicle device executes the second query message to query key information, then KEY_ID is the key address of the temporary key. If the KEY_ID is 0, it means that the second query message has no verification information, and the following M2 and M4 are ignored.

After the first SHE verifies that the second query message is successful, it may correspondingly generate a second query response message, wherein the second query response message may include the following parameters. Among them, the output parameter M3 satisfies:

M3＝KEY_ID|memory slot1|Key1 Info

Among them, Key1 Info is the key information corresponding to the key address of memory slot1, for example, Key1 Info satisfies:

Key1 Info＝KeyFlags|00|Counter(28 bits)|PairSlot|KeyID,

Among them, KeyFlags can satisfy:

KeyFlags can occupy 7 bits, among which 00 occupies 2 bits, and KeyID occupies 32 bits. Counter occupies 28 bits. PairSlot is used to identify whether the key Key1 of the query forms a pair, or Slave, that is, whether it contains "memory slot2" and "Key2Info". For example, if the PairSlot value is 0, it does not contain; if the PairSlot value is 1, it is a Pair; if the PairSlot value is 2, it is a Slave.

The output parameter M4 satisfies: M4=CMAC(Key,M3)

Therefore, after the first in-vehicle device unlocks the second query response message, it can verify the parameters in the second query response message, and then obtain the query result of the key.

After all the first keys to be constructed in the key system are successfully constructed, a non-KMS device may send a key system construction completion message to the first vehicle-mounted device, and the first SHE verifies the message. It is used to inform SHE that the construction of the key system of this KMS is completed, and the completion of the construction of the key system includes the successful generation of all the first keys of the key system, the success of the key loading verification of the key system, etc. It should be noted that the message may not include other messages, and may contain an encrypted and integrity-protected state information: the construction of the KMS key system is completed, and the result is success or failure.

As shown in Figure 7, the embodiment of the present application provides a method for generating a key, including the following steps:

Step 701: The first vehicle-mounted device obtains a key system construction completion message.

In a possible scenario, during this key system construction process, the start message for key system construction may be generated by an off-vehicle device and sent to the first on-vehicle device (for example, a server or agent) (for example, by The key system construction start message initiated by the server, key management tool or APP outside the vehicle), and the completion message of the key system construction is also generated by the device outside the vehicle.

A possible scenario, during the key system construction process, the start message of the key system construction is generated by the in-vehicle device and sent to the server (for example, the long-term key update initiated by the in-vehicle CDC or the central control panel ), the completion message of the key system construction can also be generated by the in-vehicle device or by the off-vehicle device, which is not limited here.

It should be noted that the key system construction completion message can use the same security verification key as the key system construction start message, and the details can be found in Table 11, which will not be repeated here.

For example, the first vehicle-mounted device may be a KMS server or a KMS agent. For example, when the first vehicle-mounted device is the server, the first vehicle-mounted device may send a key system construction completion message to the client, or the first vehicle-mounted device may send a key system construction completion message to the agent, and the agent sends a key system construction completion message to the client. The client forwards the key system construction completion message. When the first vehicle-mounted device is an agent, the first vehicle-mounted device may receive a key system construction completion message forwarded by the server, and may also send a key system construction completion message to a client managed by the first vehicle-mounted device.

Step 702: The first vehicle-mounted device sends a verification message of the key system construction completion message to the first SHE according to the key system construction completion message.

Wherein, the first SHE is the SHE corresponding to the first vehicle-mounted device. The first SHE can be set in the same ECU as the first vehicle-mounted device, or can be set separately, which is not limited here. The first in-vehicle device may be a KMS for managing keys in the ECU.

Step 703: The first SHE verifies the verification message of the key system construction completion message, and sends the verification result to the first vehicle-mounted device.

Step 704: the first vehicle-mounted device sends a key system construction completion message to the second vehicle-mounted device.

Wherein, the second vehicle-mounted device may be a KMS client or a KMS agent. For example, when the second vehicle-mounted device is the client, the second vehicle-mounted device can receive the key system construction completion message sent by the first vehicle-mounted device, and can also forward the key sent by the first vehicle-mounted device through the agent of the second vehicle-mounted device. System build complete message. When the second vehicle-mounted device is an agent, the second vehicle-mounted device can receive the key system construction completion message sent by the first vehicle-mounted device, and can also send a key system construction completion message to the client managed by the second vehicle-mounted device.

Step 705: The second vehicle device sends a verification message of the key system construction completion message to the second SHE according to the key system construction completion message.

Wherein, the second SHE is the SHE corresponding to the second vehicle-mounted device. The second SHE can be set in the same ECU as the first vehicle-mounted device, or can be set separately, which is not limited here. The second in-vehicle device may be a KMS for managing keys in the ECU.

Step 706: The second SHE verifies the verification message of the key system construction completion message, and sends the verification result to the second vehicle-mounted device.

Step 707: the second vehicle-mounted device sends the verification result of the second vehicle-mounted device to the first vehicle-mounted device.

The following examples illustrate the possible ways of the key system construction completion message, as shown in Table 17, including the possible parameters involved in the key system construction completion message.

Table 17

参数ParameterParameterParameter	Directiondirection	Width(bits)Width(bits)
M1M1	ININ	8080
M2M2	ININ	128128

In a possible implementation manner, the key system construction completion message may be used to inform the corresponding SHE that the key system construction of the KMS is completed, and the date when the key system construction is completed. The key system construction completion message may include the following input parameters. Among them, the input parameter M2 satisfies: M2=CMAC(Key,M1)

Among them, Key is the key corresponding to KEY_ID. KEY_ID is the key address of the security verification key corresponding to the key system construction completion message. For the construction of the key system initiated outside the vehicle, the value must be the KEY_ID of the fixed key (because the construction of the command message must also be completed outside the vehicle); for the long-term key update initiated by the CDC or the central control panel in the vehicle , it can be the KEY_ID corresponding to the long-term key, for example, the KEY_ID of the long-term key for one car one secret.

The input parameter M1 can satisfy:

M1=KEY_ID|BuildStatus|BuildCounter|BuildDate

Wherein, the BuildStatus in the key system construction completion message indicates the construction status of the key system, for example, 0—indicates that the construction is successful, and other values—indicates that the construction fails. When the SHE successfully verifies the key system construction completion message, it can update the KMS_KH_BuildStatus value in the SHE according to the BuildStatus in the key system construction completion message.

BuildCounter is the value of the build count for this key system construction.

When SHE verifies the key system construction completion message, if the value of BuildCounter in the key system construction completion message is consistent with the KMS_KH_BuildCounter value in SHE, continue other verifications, otherwise ignore the key system construction completion message and return ERC_PARAMETER_INVALID .

When the SHE verifies the key system construction completion message, the KMS_KH_BuildStatus in the SHE must be "1-under construction", otherwise the key system construction completion message is ignored and the error message ERC_KMS_KH_STATUS_INVALID is returned.

If any key or any check fails, SHE cannot update the value of KMS_KH_BuildStatus and returns ERC_KMS_KH_NOT_FINISHED.

After the SHE successfully verifies the key system construction completion message, the SHE checks whether all the first keys affected by KMS_KH_BuildStatus have been constructed. For example, including BuildStatus, Counter checks for each key. Only when all the first key checks pass, the key system construction completion message returns the verification result ERC_NO_ERROR. Otherwise, return the verification result ERC_KMS_KH_NOT_FINISHED.

After the SHE has successfully verified the key system construction completion message, at this time, the SHE sets KMS_KH_BuildStatus to "2-build successfully", and refreshes the KMS_KH_BuildDate. That is, when the key system is built each time, the date and time when the key system is built are stored in KMS_KH_BuildDate of the SHE.

When the SHE determines that the BuildStatus indicates that the build is successful (for example, the value of the BuildStatus is 0), it updates the completion time of the key system construction. BuildDate indicates the completion time of the key system construction completion message. When the system time can be read from the system, this parameter can be ignored, and the SHE directly reads the current time from the system as the key system construction completion time, and updates it to KMS_KH_BuildDate. When SHE cannot read the system time from the system, you can check this parameter first, for example, whether the parameter BuildDate is greater than the value of KMS_KH_BuildDate in SHE. Optionally, you can also refer to the KMS_CFG_KeyLifetime value. For example, when BuildDate is greater than or equal to the sum of KMS_KH_BuildDate and KMS_CFG_KeyLifetime (or half of the value, etc.), verify that the parameter is legal and update the parameter to KMS_KH_BuildDate.

If the BuildStatus value indicates that the build failed, SHE sets KMS_KH_BuildStatus to "3-Build Failed", and does not need to refresh the KMS_KH_BuildDate value.

Through steps 704 to 707, it is ensured that the second vehicle-mounted device executes the key system construction completion message. That is, the server needs to distribute the parameters of the key system construction completion message to each agent and client, and the agent distributes it to each client it acts as an agent for synchronizing the status data such as the KMS_KH_BuildCounter value of each second vehicle-mounted device. After the in-vehicle key system construction is completed (success/failure), the first vehicle-mounted device and the second vehicle-mounted device should notify SHE to set the build status KMS_KH_BuildStatus to "build successfully" or "build failed", and update the build date.

FIG. 8 is a schematic diagram of a possible system architecture applicable to the embodiment of the present application. The system architecture shown in FIG. 8 includes a vehicle and a diagnostic device. Wherein, the vehicle may be any vehicle having a key authentication function. The diagnosis device may refer to a diagnosis instrument, may also refer to a diagnosis server, and may also refer to a diagnosis server cluster. It should be understood that the embodiment of the present application does not limit the number of vehicles and diagnostic devices in the system architecture. For example, one diagnostic device may perform information interaction with only one vehicle, or may perform information interaction with multiple vehicles. Moreover, in addition to vehicles and diagnostic equipment, the system architecture applicable to the embodiment of the present application may also include other equipment, such as supplier equipment, manufacturer equipment, production line equipment, and sales equipment, etc., and this embodiment of the application also Not limited. Also, the diagnostic device in the embodiment of the present application may integrate all functions on one independent physical device, or distribute the functions on multiple independent physical devices, which is not limited in the embodiment of the present application.

In the embodiment of the present application, the vehicle diagnosis may be implemented in a wired manner or in a wireless manner. For example, when vehicle diagnosis is implemented based on wired methods, the diagnostic equipment usually has a diagnostic line, and the vehicle is preset with a diagnostic interface. The diagnostic personnel can directly insert one end of the diagnostic line of the diagnostic equipment into the diagnostic interface of the vehicle. Enter the diagnostic command on the device so that the diagnostic command is sent to the vehicle through the diagnostic line. Wherein, the diagnostic interface may refer to a unified diagnostic service (unified diagnostic services, UDS) interface, may also refer to an on-board diagnostics (OBD) interface, or may refer to other interfaces capable of realizing command transmission functions, without limitation. . When the vehicle diagnosis is realized based on the wireless method, the diagnostic equipment and the vehicle can have near-field communication functions such as Bluetooth or wireless local area network (WLAN), and the diagnostic personnel can first connect the diagnostic equipment through the near-field communication function of the diagnostic equipment and the vehicle. and the vehicle, and then enter the diagnostic command on the diagnostic device so that the diagnostic command is transmitted to the vehicle wirelessly. Exemplarily, the diagnostic equipment can also be provided with a liquid crystal display, and after obtaining the diagnostic results, the diagnostic equipment can also synchronously display the diagnostic results on the liquid crystal display, so as to remind the diagnostic personnel to check the diagnostic results in time and quickly find out the fault location and cause of failure.

As shown in Figure 9, the present application provides a method for obtaining an in-vehicle key, including:

Step 901: The off-vehicle device sends a first message to the first on-vehicle device.

Correspondingly, the first on-vehicle device receives the first message sent by the off-vehicle device; the first message is used to request the first on-vehicle device to obtain the first key.

In a possible implementation, the first key may be a long-term key that triggers the generation of the first vehicle-mounted device, or a fixed key stored in advance by the vehicle, or a fixed key of the vehicle stored on a cloud server. This is not limited.

For example, the off-vehicle device may be a diagnostic device, and the diagnostic device may establish a secure tunnel with the vehicle to send a first message to the first vehicle-mounted device, where the first message may include a certificate corresponding to the diagnostic device, a PIN code, and the like. Alternatively, the device may also send the first message through the gateway, which is not limited here.

Step 902: The first vehicle-mounted device generates a role verification request message according to the first message and the verification information of the first vehicle-mounted device, and the role verification request message is used for the server to obtain the authority of the first key for the first vehicle-mounted device and the first vehicle-mounted device Verify the verification information;

In a possible implementation manner, the first vehicle-mounted device can encrypt the PIN code obtained after encrypting the PIN code, and generate the verification information of the first vehicle-mounted device according to the authority information of the first key, which is used by the server to verify the first key. Therefore, the first vehicle-mounted device can generate a role verification request message through the certificate corresponding to the diagnostic device, the encrypted PIN code, and the encrypted permission information of the first key.

Step 903: the first vehicle-mounted device sends a role verification request message to the server.

In a possible implementation manner, the first vehicle-mounted device may send the role verification request message to the server in an encrypted manner, and the specific encryption manner is not limited in this application.

Step 904: the server verifies the role verification request message, and generates a role verification response message.

Wherein, the response message of the role verification includes: the verification result of the role verification request message.

In a possible implementation manner, the server may verify the encrypted PIN code, verify the certificate corresponding to the diagnostic device, and also verify the authority information of the first key. For example, when the first message is used to request the first vehicle-mounted device to generate the first key, it may be verified whether the first vehicle-mounted device has the authority and capability to generate the first key. When the first message is used to request the server to send the first key to the first vehicle-mounted device, it may be verified whether the first vehicle-mounted device has the authority to obtain the first key. When the first message is used to request the diagnostic device to obtain the first key on the first vehicle-mounted device for diagnosis, it may be verified whether the first vehicle-mounted device and the diagnostic device have the authority to obtain the first key.

Step 905: the server sends a response message of role verification to the first vehicle-mounted device.

Correspondingly, the first vehicle-mounted device receives the response message of the role verification sent by the server.

For example, the response message of the role verification may include agreeing or denying the first vehicle-mounted device to obtain the first key. Optionally, the response message of role verification may also include other information. Alternatively, the information may also be sent by the server, which is not limited here.

In a possible implementation manner, after step 905, the first vehicle-mounted device may generate a first key of the first vehicle-mounted device or the second vehicle-mounted device. For a specific implementation manner, reference may be made to the implementation manner in FIG. 3 . For example, the first vehicle-mounted device receives a first message sent by the server; the first message is used to instruct the first vehicle-mounted device to generate a first key; the first vehicle-mounted device generates a first request message according to the first message; the first request message uses The first security hardware expansion unit corresponding to the first vehicle-mounted device generates a first response message; the first response message includes: first key information; the first key information is generated after encrypting the first key.

It should be noted that the way the first vehicle-mounted device determines to generate the first key of the first vehicle-mounted device or the second vehicle-mounted device may be determined by the first message sent by the server, or it may be the response of the first vehicle-mounted device according to the role verification If the message is determined, at this time, the response message of the role verification may include the content in the first message.

In a possible implementation manner, after step 905, the server may send the encrypted first key to the first vehicle-mounted device. Correspondingly, the first vehicle-mounted device receives the first key sent by the server. Wherein, the method for the server to send the encrypted first key can refer to the method in scenario 2 of the above-mentioned embodiment, where the off-vehicle device initiates sending the first key loading message to the first vehicle-mounted device, so that the first vehicle-mounted device transmits the first Key Loading message, filling the first key.

In some other embodiments, the server may send the encrypted first key to the first in-vehicle device through a message sent separately, or it may be carried in the response message of the role verification, which is not limited in this application.

In a possible implementation manner, after step 905, when the verification result of the role verification request message is that the verification is successful, the first on-vehicle device sends the first key to the off-vehicle device.

In another possible implementation manner, the server may indicate to the first vehicle-mounted device that the first vehicle-mounted device agrees to send the first key through a message sent separately, or it may also be indicated by a response message of role verification, so that the first vehicle-mounted device The device may determine to send the first key to the off-vehicle device.

There may be multiple ways for the first in-vehicle device to send the first key to the out-of-vehicle device. For example, the way the first on-vehicle device sends the first key to the off-vehicle device may also be sent by referring to the first key loading message, so that the off-vehicle device can After verification, the first key is obtained. Of course, the first key may also be sent to the off-vehicle device through other secure transmission methods.

Figure 10 is a schematic structural diagram of a key generation device provided by the embodiment of the present application. The chip or circuit in the first vehicle-mounted device is another example of a chip or circuit that can be set in the first security expansion unit, and another example is a chip or circuit that can be set in the first security expansion unit.

Furthermore, the key generation device 1001 may further include a bus system, wherein the processor 1002, the memory 1004, and the transceiver 1003 may be connected through the bus system.

It should be understood that the above processor 1002 may be a chip. For example, the processor 1002 may be a field programmable gate array (field programmable gate array, FPGA), may be an application specific integrated circuit (ASIC), may also be a system chip (system on chip, SoC), or It can be a central processing unit (central processor unit, CPU), or a network processor (network processor, NP), or a digital signal processing circuit (digital signal processor, DSP), or a microcontroller (micro controller) unit, MCU), it can also be a programmable controller (programmable logic device, PLD) or other integrated chips.

In the implementation process, each step of the above-mentioned method may be completed by an integrated logic circuit of hardware in the processor 1002 or instructions in the form of software. The steps of the methods disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor 1002 . The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory 1004, and the processor 1002 reads the information in the memory 1004, and completes the steps of the above method in combination with its hardware.

It should be noted that the processor 1002 in the embodiment of the present application may be an integrated circuit chip, which has a signal processing capability. In the implementation process, each step of the above-mentioned method embodiments may be completed by an integrated logic circuit of hardware in a processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components . Various methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.

It can be understood that the memory 1004 in this embodiment of the present application may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. Among them, the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, many forms of RAM are available such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM ) and direct memory bus random access memory (direct rambus RAM, DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but not be limited to, these and any other suitable types of memory.

When the key generation device 1001 corresponds to the first vehicle-mounted device in the above method, the key generation device may include a processor 1002 , a transceiver 1003 and a memory 1004 . The memory 1004 is used to store instructions, and the processor 1002 is used to execute the instructions stored in the memory 1004, so as to implement any one or any number of corresponding methods shown in FIGS. 1 to 8 above. related programs.

When the key generating device 1001 is the above-mentioned first vehicle-mounted device, the key generating device 1001 may be used to execute the key generating method performed by the first vehicle-mounted device in any one of the above-mentioned embodiments. When the key generation device 1001 is the above-mentioned first vehicle-mounted device, the transceiver 1003 obtains a first message; the first message is used to instruct the first vehicle-mounted device to construct a first key; the processor 1002 generates a first request message according to the first message ; The first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: first key information; the first key information is encrypted by the first key Generated.

When the key generation device 1001 is the above-mentioned first secure hardware extension unit, the key generation device 1001 may be used to execute the key generation method performed by the first secure hardware extension unit in any of the above embodiments. The transceiver 1003 is used to receive the first request message sent by the first vehicle-mounted device corresponding to the first security hardware expansion unit; the first request message is generated by the first vehicle-mounted device requesting the first security hardware expansion unit to construct a first key; process After the device 1002 successfully verifies the first request message, it generates first key information; the first key information is generated after encrypting the first key.

Based on the above embodiments and the same idea, FIG. 11 is a schematic diagram of a key generation device provided in an embodiment of the present application. As shown in FIG. 11 , the key generation device 1100 may be a first vehicle-mounted device or a first security hardware expansion unit, It can also be a chip or a circuit, such as a chip or a circuit that can be set in the first vehicle-mounted device or the first security hardware expansion unit.

The key generation device may correspond to the first vehicle-mounted device or the first secure hardware expansion unit in the above method. The key generation device may implement the steps performed by the first vehicle-mounted device or the first secure hardware expansion unit in any one or any multiple of the corresponding methods shown in FIG. 1 to FIG. 8 above. The key generation device may include an acquisition unit 1101 and a processing unit 1102 . Optionally, a receiving unit 1103 and a sending unit 1104 may also be included.

When the key generation device 1100 is the above-mentioned first vehicle-mounted device and implements the steps performed by the first vehicle-mounted device in FIG. 3 above, the obtaining unit 1101 is used to obtain the first message; the first message is used to indicate Construct the first key; the processing unit 1102 generates a first request message according to the first message; the first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: First key information; the first key information is generated after encrypting the first key.

In a possible implementation manner, the receiving unit 1103 is configured to receive the first response message sent from the first security hardware extension unit.

A possible implementation manner, the receiving unit 1103 is configured to receive the first parameter of the first key sent from the first secure hardware extension unit;

A processing unit 1102, configured to generate a first key loading message according to a first parameter of the first key;

The sending unit 1104 is configured to send a first key loading message to the second vehicle-mounted device; the first key loading message is used for filling the first key after the second vehicle-mounted device successfully verifies the first key loading message.

In a possible implementation manner, after the obtaining unit 1101 obtains the first message, the sending unit 1104 is further configured to send a status update message to the first security hardware extension unit; the status update message includes: the construction status of the in-vehicle key; The status update message is used for the first security hardware expansion unit to update the construction status of its own in-vehicle key after the verification of the status update message is successful.

In a possible implementation, the processing unit 1102 sends a first query request to the first security hardware expansion unit through the sending unit 1104 after determining that the first vehicle-mounted device is restarted; the first query request is used to query the second parameter of the first key ; Receive the first query response message sent by the first security hardware expansion unit through the receiving unit 1103; the first query response message is returned after the first security hardware expansion unit verifies the first query request; the first query response message includes: The second parameter of the first key; according to the second parameter of the first key and the first message, generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before the restart of the first vehicle-mounted device key.

In a possible implementation manner, the receiving unit 1103 is configured to receive the temporary key sent from the first security hardware extension unit; the temporary key is used to encrypt the first request message.

In a possible implementation, the receiving unit 1103 is configured to receive a second message sent by the second vehicle-mounted device; the second message is used for at least one of the following: querying the second parameter of the first key, requesting the first vehicle-mounted device to generate The first key may instruct the second on-vehicle device to restart.

In a possible implementation manner, after the processing unit 1102 verifies the second message, the sending unit 1104 sends a third message to the second in-vehicle device; the third message includes at least one of the following: the second parameter of the first key, First key information.

Receive the first message sent by the in-vehicle device or the out-of-vehicle device through the receiving unit 1103;

After receiving the initialization or update information of the configuration file through the receiving unit 1103, the first message is obtained;

After receiving the initialization or update information of the fixed key of the vehicle through the receiving unit 1103, the first message is obtained;

After the receiving unit 1103 receives the initialization or update information of the shared key between the on-vehicle devices of the vehicle, the first message is obtained.

In some other embodiments, the key generating device may be a security hardware expansion unit in the vehicle, and the device includes:

The receiving unit 1103 is configured to receive a first request message sent by the first vehicle-mounted device corresponding to the first security hardware expansion unit; the first request message is generated by the first vehicle-mounted device requesting the first security hardware expansion unit to construct a first key;

The processing unit 1102 is configured to generate first key information after successfully verifying the first request message; the first key information is generated after encrypting the first key.

In a possible implementation manner, the sending unit 1104 is configured to send a first response message to the first vehicle-mounted device; the first response message includes: first key information.

A possible implementation manner, after the processing unit 1102 successfully verifies the first request message, generates the first parameter of the first key; sends the first parameter of the first key to the first vehicle-mounted device through the sending unit 1104; The first parameter of a key is used to fill the first key in the second on-vehicle device.

In a possible implementation, the receiving unit 1103 is also configured to receive a status update message sent by the first vehicle-mounted device; the status update message includes: the construction status of the in-vehicle key; the processing unit 1102 is also configured to verify the status update message After success, update the build status of your own in-vehicle key.

In a possible implementation manner, the receiving unit 1104 is further configured to receive a first query request sent by the first vehicle-mounted device after the first vehicle-mounted device restarts; the first query request is used to query the second parameter of the first key;

The processing unit 1102 is configured to send a first query response message to the first vehicle-mounted device through the sending unit 1104 after verifying the first query request; the first query response message includes: the second parameter of the first key; the first key The second parameter of the key is used for the first vehicle device to generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before restarting.

In a possible implementation, the processing unit 1102 is configured to generate a temporary key after the first request message is verified successfully; send the temporary key to the first vehicle-mounted device through the sending unit 1104; the temporary key is used to encrypt the first request message.

In a possible implementation manner, the receiving unit 1103 is configured to receive a verification message of a second message from the first vehicle-mounted device; the second message is received by the first vehicle-mounted device and sent by the second vehicle-mounted device; the second message is used for at least the following One item: querying the second parameter of the first key, requesting the first vehicle-mounted device to generate the first key, or instructing the second vehicle-mounted device to restart.

In a possible implementation manner, the processing unit 1102 is configured to, after verifying the second message, send a verification response message of the second message to the first vehicle-mounted device through the sending unit; the response message of the second message is used by the first vehicle-mounted device Sending a third message to the second vehicle-mounted device; the third message includes at least one of the following items: the second parameter of the first key, and information about the first key.

The sending unit 1104 and the receiving unit 1103 can be a sending unit or a transmitter when sending information, the receiving unit 1103 can be a receiving unit or a receiver when receiving information, and the sending unit 1104 and the receiving unit 1103 can be transceivers, this transceiver, The transmitter or receiver may be a radio frequency circuit. When the key generating device 1100 includes a storage unit, the storage unit is used to store computer instructions, the processing unit 1103 is connected to the storage unit in communication, and the processing unit 1103 executes the computer instructions stored in the storage unit. The key generation apparatus 1100 can be used to execute the method executed by the first vehicle-mounted device or the first secure hardware expansion unit in the above embodiment. Wherein, the processing unit 1103 may be a general central processing unit (CPU), a microprocessor, or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC).

When the key generation device 1100 is a chip, the sending unit 1104 and the receiving unit 1103 may be input and/or output interfaces, pins or circuits, and the like. The processing unit 1103 may execute the computer-executable instructions stored in the storage unit, so that the chip in the key generation device 1100 executes the method performed in any one of the embodiments. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc., and the storage unit may also be a storage unit located outside the chip in the key generation device 1100, such as a read-only memory (Read Only Memory, ROM) Or other types of static storage devices that can store static information and instructions, random access memory (Random Access Memory, RAM), etc.

For the concepts, explanations, detailed descriptions and other steps involved in the key generation device 1100 related to the technical solutions provided by the embodiments of the present application, please refer to the foregoing methods or descriptions of these contents in other embodiments, and details are not repeated here.

Fig. 12 is a schematic structural diagram of a key acquisition device provided in the embodiment of the present application. As shown in Fig. 12, the device can be a first vehicle-mounted device or server, or a chip or a circuit, for example, it can be set in the first vehicle-mounted device A chip or a circuit in a device, another example is a chip or a circuit that can be installed in a server, and another example is a chip or a circuit that can be installed in a server.

Furthermore, the key acquisition device 1201 may further include a bus system, wherein the processor 1202, the memory 1204, and the transceiver 1203 may be connected through the bus system.

It should be understood that the above processor 1202 may be a chip. For example, the processor 1202 may be a field programmable gate array (field programmable gate array, FPGA), may be an application specific integrated circuit (ASIC), may also be a system chip (system on chip, SoC), or It can be a central processing unit (central processor unit, CPU), or a network processor (network processor, NP), or a digital signal processing circuit (digital signal processor, DSP), or a microcontroller (micro controller) unit, MCU), it can also be a programmable controller (programmable logic device, PLD) or other integrated chips.

In the implementation process, each step of the above method may be implemented by an integrated logic circuit of hardware in the processor 1202 or instructions in the form of software. The steps of the methods disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor 1202 . The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory 1204, and the processor 1202 reads the information in the memory 1204, and completes the steps of the above method in combination with its hardware.

It should be noted that the processor 1202 in the embodiment of the present application may be an integrated circuit chip, which has a signal processing capability. In the implementation process, each step of the above-mentioned method embodiments may be completed by an integrated logic circuit of hardware in a processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components . Various methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.

It can be understood that the memory 1204 in this embodiment of the present application may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. Among them, the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, many forms of RAM are available such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM ) and direct memory bus random access memory (direct rambus RAM, DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but not be limited to, these and any other suitable types of memory.

In the case where the key obtaining device 1201 corresponds to the first vehicle-mounted device in the above method, the key obtaining device may include a processor 1202 , a transceiver 1203 and a memory 1204 . The memory 1204 is used to store instructions, and the processor 1202 is used to execute the instructions stored in the memory 1204, so as to implement the related solution of the first vehicle-mounted device in the method shown in FIG. 9 above.

When the key obtaining device 1201 is the above-mentioned first vehicle-mounted device, the key obtaining device 1201 may be used to execute the method performed by the first vehicle-mounted device in the above-mentioned embodiment.

The key acquisition device 1201 is the above-mentioned first vehicle-mounted device, and when the embodiment in FIG. 9 is executed:

The transceiver 1203 is configured to receive the first message sent by the off-vehicle device; and send an identity verification request message to the server. The first message is used to request the first on-vehicle device to obtain the first key; the identity verification response message sent by the server is received; the identity verification response message includes: the verification result of the identity verification request message.

The processor 1202 is configured to generate an identity verification request message according to the first message and the verification information of the first vehicle-mounted device, and the identity verification request message is used for the server to verify the authority of the first vehicle-mounted device to obtain the first key and the first vehicle-mounted device The information is verified.

In a possible implementation manner, the transceiver 1203 is further configured to receive a first message sent by the server; the first message is used to instruct the first vehicle-mounted device to generate a first key; the processor 1202 is further configured to generate a second key according to the first message. A request message; the first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: first key information; Generated after key encryption.

In a possible implementation manner, the transceiver 1203 is also configured to receive the first key sent by the server.

In a possible implementation manner, the processor 1202 is further configured to send the first key to the off-vehicle device through the transceiver 1203 when the verification result of the identity verification request message is that the verification is successful.

In the case where the key obtaining device 1201 corresponds to the server in the above method, the key obtaining device may include a processor 1202, a transceiver 1203, and a memory 1204. The memory 1204 is used to store instructions, and the processor 1202 is used to execute the instructions stored in the memory 1204, so as to realize the related solution of the server in the method shown in FIG. 9 above.

When the key obtaining device 1201 is the above server, the key obtaining device 1201 may be used to execute the method performed by the first vehicle-mounted device in the above embodiment.

When the key acquisition device 1201 is the above-mentioned server, and the embodiment in FIG. 9 is executed:

The transceiver 1203 is configured to receive an identity verification request message sent by the first vehicle-mounted device; the identity verification request message is generated by the first vehicle-mounted device according to the first message sent by the off-vehicle device and the verification information of the first vehicle-mounted device;

The processor 1202 is configured to verify the authority of the first vehicle-mounted device to obtain the first key and the verification information of the first vehicle-mounted device according to the identity verification request message, and generate an identity verification response message; the identity verification response message includes: identity verification Validation result of the request message.

The transceiver 1203 is configured to send a response message of identity verification to the first vehicle-mounted device.

In a possible implementation manner, the transceiver 1203 is further configured to send a first message to the first vehicle-mounted device; the first message is used to instruct the first vehicle-mounted device to generate a first key.

In a possible implementation manner, the transceiver 1203 is also configured to send the first key to the first vehicle-mounted device.

Fig. 13 is a schematic diagram of a key obtaining device provided in the embodiment of the present application. As shown in Fig. 13, the key obtaining device 1300 can be a first vehicle-mounted device or a server, or can be a chip or a circuit, for example, it can be set in the first Chips or circuits in in-vehicle devices or servers. Wherein, the first vehicle-mounted device may be any ECU in the vehicle.

The key acquisition device may correspond to the first vehicle-mounted device in the above method. The key acquisition device may implement the steps performed by the first vehicle-mounted device in any one or multiple corresponding methods shown in FIG. 9 above. The device for obtaining a key may include an obtaining unit 1301 , a processing unit 1302 , a sending unit 1303 and a receiving unit 1304 .

When the key acquisition device 1300 is the above-mentioned first vehicle-mounted device, and implements the steps performed by the above-mentioned first vehicle-mounted device in FIG. 9 ,

The receiving unit 1304 is configured to receive a first message sent by the off-vehicle device; the first message is used to request the first on-vehicle device to obtain a first key; receive an identity verification response message sent by the server; the identity verification response message includes: Validation result of the validation request message.

The processing unit 1302 is configured to generate an identity verification request message according to the first message and the verification information of the first vehicle-mounted device, and the identity verification request message is used for the server to obtain the authority of the first key for the first vehicle-mounted device and the authentication information of the first vehicle-mounted device. Verify the information for verification.

The sending unit 1303 is configured to send an identity verification request message to the server.

In a possible implementation manner, the receiving unit 1304 is further configured to receive a first message sent by the server; the first message is used to instruct the first vehicle-mounted device to generate a first key; the processing unit 1302 is further configured to, according to the first message, Generate a first request message; the first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: first key information; the first key information is for the first Generated after encryption with a key.

In a possible implementation manner, the receiving unit 1304 is further configured to receive the first key sent by the server.

In a possible implementation manner, the processing unit 1302 is further configured to send the first key to the off-vehicle device through the sending unit 1303 when the verification result of the identity verification request message is that the verification is successful.

When the key acquisition device 1300 is the above-mentioned server and implements the steps performed by the first vehicle-mounted device in FIG. 9 above,

The receiving unit 1304 is configured to receive an identity verification request message sent by the first vehicle-mounted device; the identity verification request message is generated by the first vehicle-mounted device according to the first message sent by the off-vehicle device and the verification information of the first vehicle-mounted device;

The processing unit 1302 is configured to verify the authority of the first vehicle-mounted device to obtain the first key and the verification information of the first vehicle-mounted device according to the identity verification request message, and generate an identity verification response message; the identity verification response message includes: Validation result of the validation request message.

The sending unit 1303 is configured to send a response message of identity verification to the first vehicle-mounted device.

In a possible implementation manner, the sending unit 1303 is further configured to send a first message to the first vehicle-mounted device; the first message is used to instruct the first vehicle-mounted device to generate a first key.

In a possible implementation manner, the sending unit 1303 is further configured to send the first key to the first vehicle-mounted device.

The sending unit 1303 can be a transceiver unit or a transmitter when sending information, the receiving unit 1304 can be a transceiver unit or a receiver when receiving information, the sending unit 1303 and the receiving unit 1304 can be transceivers, and the transceiver, transmitter or receiver The device can be a radio frequency circuit. When the key acquisition device 1300 includes a storage unit, the storage unit is used to store computer instructions. The acquisition unit or the processing unit can be respectively connected to the storage unit in communication, and the acquisition unit or the processing unit executes the computer stored in the storage unit. An instruction, so that the key acquisition device can be used to execute the method executed by the first vehicle-mounted device or the server in any of the above embodiments. Wherein, the acquiring unit or processing unit may be a general central processing unit (CPU), a microprocessor, or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC).

When the key obtaining device 1300 is a chip, the sending unit 1303 and the receiving unit 1304 may be input and/or output interfaces, pins or circuits, and the like. The acquisition unit or the processing unit may execute the computer-executed instructions stored in the storage unit, so that the chip in the key acquisition device 1300 executes the method performed by the first vehicle-mounted device or the server in the embodiment. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc., and the storage unit may also be a storage unit located outside the chip in the key acquisition device 1300, such as a read-only memory (Read Only Memory, ROM) Or other types of static storage devices that can store static information and instructions, random access memory (Random Access Memory, RAM), etc.

For the concepts, explanations, detailed descriptions and other steps involved in the key acquisition device 1300 related to the technical solutions provided by the embodiments of the present application, please refer to the foregoing methods or descriptions of these contents in other embodiments, and details are not repeated here.

According to the method provided in the embodiment of the present application, the present application also provides a computer program product, the computer program product including: computer program code, when the computer program code is run on the computer, the computer is made to execute the computer program described in Fig. 1 to Fig. 9 . The method of any one of the embodiments is illustrated.

According to the method provided in the embodiment of the present application, the present application also provides a computer-readable storage medium, the computer-readable medium stores program code, and when the program code is run on the computer, the computer is made to execute the steps shown in Figures 1 to 9. The method of any of the illustrated embodiments.

According to the method provided in the embodiment of the present application, the present application further provides a key generation system, which includes at least two of the foregoing first vehicle-mounted device, the first secure hardware expansion unit, or the server.

The embodiment of the present application also provides a vehicle, the vehicle includes at least one unit to be diagnosed mentioned in the above-mentioned embodiments of the present application, or the vehicle includes at least one of the first vehicle-mounted equipment and the first safety hardware expansion unit mentioned in the above-mentioned embodiments of the present application .

The embodiment of the present application also provides a vehicle, the vehicle includes at least one unit to be diagnosed mentioned in the above-mentioned embodiments of the present application, or the vehicle includes at least one first vehicle-mounted device and the server mentioned in the above-mentioned embodiments of the present application.

The terms "component", "module", "system" and the like are used in this specification to refer to a computer-related entity, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be components. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. A component may, for example, be based on a signal having one or more packets of data (e.g., data from two components interacting with another component between a local system, a distributed system, and/or a network, such as the Internet via a signal interacting with other systems). Communicate through local and/or remote processes.

Those of ordinary skill in the art can appreciate that various illustrative logical blocks (illustrative logical blocks) and steps (steps) described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, or a combination of computer software and electronic hardware. accomplish. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

If the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), magnetic disk or optical disc and other media that can store program codes. .

The above is only a specific implementation of the application, but the scope of protection of the application is not limited thereto. Anyone familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the application. Should be covered within the protection scope of this application. Therefore, the protection scope of the present application should be determined by the protection scope of the claims. Those skilled in the art should understand that the embodiments of the present application may be provided as methods, systems, or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the present application. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

Apparently, those skilled in the art can make various changes and modifications to this application without departing from the protection scope of this application. In this way, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

A method for generating a key, characterized in that it is applied to a vehicle, comprising:

The first vehicle-mounted device obtains a first message; the first message is used to instruct the first vehicle-mounted device to construct a first key;

Generate a first request message according to the first message; the first request message is used for the first safety hardware expansion unit corresponding to the first vehicle-mounted device to generate a first response message; the first response message includes: Key information; the first key information is generated after encrypting the first key.
The method of claim 1, further comprising:

Receive the first response message sent from the first security hardware extension unit.
The method according to claim 1 or 2, further comprising:

receiving a first parameter of the first key sent from the first secure hardware extension unit;

The first vehicle-mounted device generates a first key loading message according to the first parameter of the first key;

The first vehicle-mounted device sends the first key loading message to the second vehicle-mounted device; the first key loading message is used after the second vehicle-mounted device successfully verifies the first key loading message , filling the first key.
The method according to any one of claims 1-3, wherein after the first vehicle-mounted device obtains the first message, further comprising:

The first in-vehicle device sends a status update message to the first secure hardware expansion unit; the status update message includes: the construction status of the key in the vehicle; the status update message is used for the first secure hardware expansion unit After successfully verifying the state update message, update the construction state of its own in-vehicle key according to the state update message.
The method according to any one of claims 1-4, wherein the method further comprises:

After determining that the first vehicle-mounted device is restarted, send a first query request to the first security hardware expansion unit; the first query request is used to query the second parameter of the first key;

receiving a first query response message sent by the first security hardware expansion unit; the first query response message is returned after the first security hardware expansion unit verifies the first query request; the first The query response message includes: a second parameter of the first key;

According to the first message, generate a first request message, including:

The first request message is generated according to the second parameter of the first key and the first message; the first key is a key to be generated by the first security hardware expansion unit before restarting.
The method according to any one of claims 1-5, wherein the method further comprises:

receiving a temporary key sent from the first secure hardware extension unit; the temporary key is used to encrypt the first request message.
The method according to any one of claims 1-6, further comprising:

receiving a second message sent by the second vehicle-mounted device; the second message is used for at least one of the following:

Querying the second parameter of the first key, requesting the first vehicle-mounted device to generate the first key, or instructing the second vehicle-mounted device to restart.
The method of claim 7, further comprising:

After verifying the second message, send a third message to the second vehicle-mounted device; the third message includes at least one of the following: the second parameter of the first key, the first key information.
A method for generating a key, characterized in that it is applied to a vehicle, comprising:

The first safety hardware expansion unit receives the first request message sent by the first vehicle-mounted device corresponding to the first safety hardware expansion unit; the first request message is used by the first vehicle-mounted device to request the first safety hardware The expansion unit constructs the first key;

After the first request message is verified successfully, first key information is generated; the first key information is generated after encrypting the first key.
The method of claim 9, further comprising:

Sending the first response message to the first vehicle-mounted device; the first response message includes: first key information.
The method according to claim 9 or 10, further comprising:

After successfully verifying the first request message, generating a first parameter of the first key;

Sending the first parameter of the first key to the first vehicle-mounted device; the first parameter of the first key is used for the second vehicle-mounted device to fill the first key.
The method according to any one of claims 9-11, wherein the method further comprises:

receiving a status update message sent by the first vehicle-mounted device; the status update message includes: the construction status of the in-vehicle key;

After successfully verifying the state update message, update the construction state of its own in-vehicle key according to the state update message.
The method according to any one of claims 9-12, wherein the method further comprises:

After the first vehicle-mounted device restarts, receiving a first query request sent by the first vehicle-mounted device; the first query request is used to query the second parameter of the first key;

After verifying the first query request, send a first query response message to the first vehicle-mounted device; the first query response message includes: the second parameter of the first key; the first key The second parameter of the key is used by the first vehicle-mounted device to generate the first request message; the first key is the key to be generated by the first security hardware expansion unit before restarting.
The method according to any one of claims 9-13, further comprising:

After successfully verifying the first request message, generating a temporary key;

sending the temporary key to the first in-vehicle device; the temporary key is used to encrypt the first request message.
The method according to any one of claims 9-14, further comprising:

Receive a verification message of a second message from the first vehicle-mounted device; the second message is sent by the first vehicle-mounted device and received by the second vehicle-mounted device; the second message is used for at least one of the following: query the the second parameter of the first key, request the first vehicle-mounted device to generate the first key, or instruct the second vehicle-mounted device to restart.
The method of claim 15, further comprising:

After verifying the second message, send a verification response message of the second message to the first vehicle-mounted device; the response message of the second message is used for the first vehicle-mounted device to send the second message to the second vehicle-mounted device A third message; the third message includes at least one of the following: a second parameter of the first key, and information about the first key.
A key generation device, characterized in that it includes: a processor and a communication interface, the communication interface is used to receive signals from other communication devices except the key generation device and transmit them to the processor or transfer signals from the processing The signal of the processor is sent to other communication devices except the key generation device; the processor is used to implement the method as described in any one of claims 1 to 8 through a logic circuit or executing code instructions.
A key generation device, characterized in that it includes: a processor and a communication interface, the communication interface is used to receive signals from other communication devices except the key generation device and transmit them to the processor or transfer signals from the processing The signal of the processor is sent to other communication devices except the key generation device; the processor is used to implement the method as described in any one of claims 9 to 16 through a logic circuit or executing code instructions.
A vehicle, characterized in that the vehicle comprises a first vehicle-mounted device and a first security hardware expansion unit, the first vehicle-mounted device is used to implement the method according to any one of claims 1 to 8, the The first security hardware expansion unit is used to implement the method according to any one of claims 9-16.
A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, and when the computer program is executed, the method, Or implement the method as described in any one of claims 9 to 16 above.
A computer program product, characterized in that the computer program product includes a computer program or an instruction, and when the computer program or instruction is executed by the key generation device, the implementation of any one of the above claims 1 to 8 method, or implement a method as described in any one of claims 9 to 16 above.
A system on a chip, characterized in that it comprises:

A processor, used to call the computer program or computer instruction stored in the memory, so that the processor executes the program code in the memory, so as to realize the method as described in any one of the above claims 1 to 8, or realize A method as claimed in any one of claims 9 to 16 above.