Vehicle diagnostic system, method and device

Abstract

A vehicle diagnostic system, method and device are used to solve the unsafe effects caused by using long-term keys for vehicle diagnosis. The vehicle diagnostic system includes a key management system and a unit to be diagnosed. The key management system receives a key authorization request sent by a diagnostic device, generates a temporary key according to the key authorization request, and sends a key authorization response to the diagnostic device, carrying the temporary key in the key authorization response. The key management system configures the temporary key to the unit to be diagnosed, so that the diagnostic device and the unit to be diagnosed can complete the diagnosis based on the temporary key and obtain the diagnostic result. Among them, the temporary key is independent of the long-term key in the vehicle. By configuring a temporary key to complete vehicle diagnosis, the diagnostic device can be prevented from contacting the long-term key in the vehicle as much as possible. This not only helps to protect the privacy data of the owner, but also reduces the possibility of illegal personnel using the long-term key to control the operation of the vehicle, thereby improving the driving safety of the owner.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking technology, and in particular to a vehicle diagnostic system, method and device. Background Art

[0002] In the field of vehicle networking technology, an authentication mechanism is set between each electronic control unit inside the vehicle. This authentication mechanism requires each electronic control unit to interact based on a key. Therefore, under normal circumstances, a vehicle will be encapsulated with a large number of keys. These keys not only involve the keys preset by the chip manufacturer before the vehicle leaves the factory, the keys preset by the equipment supplier, and the keys preset by the original equipment manufacturer, but may also cover the owner's key set in the vehicle after the vehicle leaves the factory. These keys are long-term keys, and the owner can use these long-term keys to complete vehicle operations such as vehicle control, driving, and voice interaction before the vehicle is scrapped.

[0003] At this stage, all operations performed on the vehicle also need to be completed based on the above-mentioned long-term keys. These operations not only cover the test phase before the vehicle leaves the factory and the use phase after the vehicle leaves the factory, but also include the diagnosis phase after the vehicle fails. This means that the diagnostic personnel must first obtain the long-term key in the vehicle before diagnosing the vehicle. However, in theory, the long-term key should not be leaked outside the vehicle. Because if these long-term keys are obtained by illegal persons, then the illegal persons can not only obtain the owner's private data (such as driving data) through these long-term keys, but even worse, they may use these long-term keys to control the operation of the vehicle, affecting the owner's driving safety.

[0004] In summary, there is a need for a vehicle diagnostic system to avoid the unsafe impact caused by using a long-term key for vehicle diagnosis. Summary of the invention

[0005] The present application provides a vehicle diagnostic system, method and device to avoid the unsafe impact caused by using a long-term key for vehicle diagnosis.

[0006] In the first aspect, the present application provides a vehicle diagnostic system, including a key management system and a unit to be diagnosed located in a vehicle. When performing diagnosis, the key management system can receive a key authorization request sent by a diagnostic device, generate a temporary key according to the key authorization request, and send a key authorization response to the diagnostic device, carrying the temporary key in the key authorization response. After that, the key management system can configure the temporary key to the unit to be diagnosed, so that the diagnostic device uses the temporary key to decrypt the diagnostic request sent by the diagnostic device to obtain the information to be diagnosed, complete the diagnosis based on the information to be diagnosed, and send the diagnostic result to the diagnostic device. Among them, the temporary key is independent of the long-term key in the vehicle. In the above design, by configuring a temporary key to complete the vehicle diagnosis, the diagnostic device can be prevented from contacting the long-term key in the vehicle as much as possible. This not only helps to protect the privacy data of the car owner, but also reduces the possibility of illegal persons using long-term keys to control the operation of the vehicle, thereby improving the driving safety of the car owner.

[0007] In a possible design, the vehicle diagnostic system may also include a diagnostic device, which may send a key authorization request to the key management system, receive a key authorization response sent by the key management system, use the temporary key carried in the key authorization response to encrypt the information to be diagnosed to generate a diagnostic request, send the diagnostic request to the unit to be diagnosed, and then receive the diagnostic result sent by the unit to be diagnosed. In the above design, through the three-party interaction process between the diagnostic device, the key management system and the unit to be diagnosed, the three parties can accurately know which stage of the diagnosis is currently in, so as to facilitate the completion of this diagnosis in a collaborative manner. Moreover, in this method, the diagnostic device triggers the key management system to generate a temporary key, and the temporary key can only be generated when the diagnosis needs to be performed, which helps to save processing resources. Furthermore, the design transmits the information to be diagnosed between the diagnostic device and the unit to be diagnosed by encrypting the temporary key, which can not only prevent the diagnostic device from obtaining the long-term key in the vehicle and maintain the safety of the owner's driving, but also try to avoid the information to be diagnosed from being hijacked during the transmission process, thereby improving the safety of vehicle diagnosis.

[0008] In a possible design, the temporary key may also correspond to a valid duration, and the valid duration corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis. This design may also flexibly configure the diagnosis duration, which helps to improve the flexibility of the diagnosis operation.

[0009] In one possible design, after the diagnostic device uses the temporary key to initiate a diagnostic operation on the unit to be diagnosed, it can also send a secure heartbeat message to the key management system within the validity period corresponding to the temporary key and according to the preset cycle duration. Correspondingly, if the key management system receives the secure heartbeat message sent by the diagnostic device within the preset cycle duration, the key management system can continue to validate the temporary key in the unit to be diagnosed. If the key management system does not receive the secure heartbeat message sent by the diagnostic device within the preset cycle duration, the key management system can invalidate the temporary key in the unit to be diagnosed. This design not only supports the diagnostic device to set the validity period corresponding to the temporary key according to its own diagnostic needs, but also enables the key management system to manage each temporary key more conveniently and flexibly through the interaction of secure heartbeat messages.

[0010] In a possible design, before the diagnostic device sends a security heartbeat message to the key management system according to a preset period, it can also generate first verification information using at least one feature information used when generating a temporary key, and generate the security heartbeat message according to the first verification information. Correspondingly, after the key management system receives the security heartbeat message sent by the diagnostic device within the preset period, it can also generate second verification information according to at least one feature information used when generating the temporary key. If it is determined that the second verification information matches the first verification information, the temporary key can continue to take effect. Among them, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value or a second random value. Among them, the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device. This design uses at least one feature information used to generate a temporary key to generate the verification information carried in the security heartbeat message, so that the security heartbeat message can be bound to the temporary key (or the diagnostic session corresponding to the temporary key), and the diagnostic session corresponding to the temporary key is maintained by using the security heartbeat message bound to the temporary key, which can facilitate the key management system to accurately manage each temporary key.

[0011] In a possible design, the second verification information may satisfy the following formula:

[0012] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0013] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0014] In a possible design, after the key management system configures the temporary key to the unit to be diagnosed, it can also invalidate the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has passed. This design can monitor the validity period corresponding to each temporary key by the key management system without the participation of the diagnostic device, thereby helping to reduce the working pressure of the diagnostic device.

[0015] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request. This design can also flexibly configure the unit to be diagnosed applicable to this diagnosis, which helps to further improve the flexibility of the diagnostic operation.

[0016] In a possible design, the unit to be diagnosed may refer to all the units to be diagnosed involved in this diagnosis. In this way, the temporary key can be synchronously configured to all the units to be diagnosed involved in this diagnosis, without configuring a separate temporary key for each unit to be diagnosed. This not only helps to reduce the number of temporary keys that the key management system needs to maintain and save processing resources, but also reduces the complexity of this diagnosis through the same temporary key and improves the diagnostic efficiency.

[0017] In one possible design, the key authorization request may include at least one feature information, such as at least one of a first random value, a feature identifier, or an authorization code, wherein the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before sending a key authorization response to the diagnostic device, the key management system may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, use the transmission security key to encrypt a temporary key to generate a ciphertext, and generate a key authorization response based on the ciphertext; correspondingly, after receiving the key authorization response sent by the key management system, the diagnostic device may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key. This design uses encrypted ciphertext to send a temporary key to the diagnostic device. Regardless of whether the diagnostic device is outside the vehicle or directly encapsulated in the vehicle, this method can minimize the tampering of the temporary key during transmission, which helps the diagnostic device receive the correct temporary key.

[0018] In a possible design, before sending a key authorization response, the key management system can also derive a second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information to generate a third verification information, and then generate a key authorization response based on the third verification information and the ciphertext; correspondingly, after receiving the key authorization response, the diagnostic device can also first derive a second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information in the key authorization response to generate a sixth verification information, and when it is determined that the sixth verification information is the same as the third verification information, the ciphertext is decrypted to obtain a temporary key. This design also sets verification information to verify the authenticity of the ciphertext transmission. Therefore, even if the temporary key is tampered with during the transmission process, this method can prevent the diagnostic device from obtaining the tampered temporary key to carry out diagnosis as much as possible, effectively protecting the security of vehicle diagnosis.

[0019] In one possible design, after decrypting the ciphertext to obtain the temporary key, the diagnostic device can also generate fourth verification information based on the ciphertext, the third verification information, and one or more of at least one feature information, and send the fourth verification information to the key management system; correspondingly, after receiving the fourth verification information, the key management system can also use the ciphertext, the third verification information, and one or more of at least one feature information to generate fifth verification information. If the fourth verification information and the fifth verification information match, the temporary key can be configured to the unit to be diagnosed in the vehicle. In this design, by verifying whether the temporary key received by the diagnostic device is correct before the key management system configures the temporary key, it helps the key management system detect tampering during the temporary key issuance process. In this way, the key management system can only configure the temporary key to the unit to be diagnosed when the diagnostic device receives the correct temporary key, which helps to ensure the security of performing diagnosis based on the temporary key.

[0020] In a possible design, the transmission security key can satisfy the following formula:

[0021] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0022] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0023] Furthermore, the ciphertext can satisfy the following formula:

[0024] C = AES-GCM (tK, {M});

[0025] Wherein, C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm using the counting mode and carrying the Galois message authentication code (GMAC), and {M} is the temporary key.

[0026] In a possible design, the second symmetric key may satisfy the following formula:

[0027] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0028] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0029] Furthermore, the third verification information may satisfy the following formula:

[0030] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0031] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0032] In a possible design, the fifth check information may satisfy the following formula:

[0033] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0034] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0035] In the second aspect, the present application provides a vehicle diagnostic method, which is applicable to a key management system in a vehicle, and includes: the key management system receives a key authorization request sent by a diagnostic device, generates a temporary key according to the key authorization request, and sends a key authorization response to the diagnostic device, carrying the temporary key in the key authorization response, after which the key management system can configure the temporary key to the unit to be diagnosed in the vehicle, so that the diagnostic device and the unit to be diagnosed can complete the diagnosis based on the temporary key. The temporary key is independent of the long-term key in the vehicle.

[0036] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0037] In a possible design, after sending a key authorization response to the diagnostic device, the key management system can also wait to receive a security heartbeat message sent by the diagnostic device. If the security heartbeat message sent by the diagnostic device is not received within a preset period, the temporary key in the unit to be diagnosed can be invalidated. The security heartbeat message is sent by the diagnostic device to the key management system in a periodic manner within the validity period corresponding to the temporary key.

[0038] In one possible design, the security heartbeat message may include first verification information, which is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value; the feature identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device. In this case, when the key management system receives a security heartbeat message sent by the diagnostic device within a preset period, the key management system can also generate second verification information based on at least one feature information used when generating the temporary key, and when it is determined that the second verification information matches the first verification information, the temporary key can continue to take effect.

[0039] In a possible design, the second verification information may satisfy the following formula:

[0040] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0041] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0042] In a possible design, after configuring the temporary key to the unit to be diagnosed in the vehicle, the key management system may also invalidate the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has expired.

[0043] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0044] In a possible design, the key management system configures the temporary key to the unit to be diagnosed in the vehicle, including: the key management system configures the temporary key to each unit to be diagnosed required for this diagnosis.

[0045] In one possible design, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the key management system sends a key authorization response to the diagnostic device, it can also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain a temporary key.

[0046] In one possible design, the key management system generates a key authorization response based on the ciphertext, including: the key management system first encrypts the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generates the key authorization response based on the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used by the diagnostic device to perform verification before decrypting the ciphertext.

[0047] In a possible design, after the key management system sends the key authorization response to the diagnostic device and before configuring the temporary key to the unit to be diagnosed in the vehicle, it can also receive the fourth verification information sent by the diagnostic device, use the ciphertext, the third verification information and one or more of the at least one feature information to generate the fifth verification information, and determine that the fourth verification information matches the fifth verification information. The fourth verification information is generated based on one or more of the ciphertext, the third verification information and the at least one feature information.

[0048] In a possible design, the transmission security key can satisfy the following formula:

[0049] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0050] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0051] Furthermore, the ciphertext can satisfy the following formula:

[0052] C = AES-GCM (tK, {M});

[0053] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0054] In a possible design, the second symmetric key may satisfy the following formula:

[0055] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0056] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0057] Furthermore, the third verification information may satisfy the following formula:

[0058] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0059] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0060] In a possible design, the fifth check information may satisfy the following formula:

[0061] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0062] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0063] In a third aspect, the present application provides a vehicle diagnostic method, which is applicable to a diagnostic device, and the method includes: the diagnostic device sends a key authorization request to a key management system in the vehicle, so that the key management system generates a temporary key based on the key authorization request and configures it to a unit to be diagnosed in the vehicle, and the temporary key is independent of the long-term key in the vehicle; thereafter, the diagnostic device receives a key authorization response sent by the key management system, and the key authorization response includes a temporary key, and the diagnostic device uses the temporary key to initiate a diagnostic operation on the unit to be diagnosed.

[0064] In one possible design, the diagnostic device uses a temporary key to initiate a diagnostic operation on the unit to be diagnosed, including: the diagnostic device first uses the temporary key to encrypt the information to be diagnosed to generate a diagnostic request, and sends the diagnostic request to the unit to be diagnosed, and then receives the diagnostic result sent by the unit to be diagnosed. The diagnostic request is used for the unit to be diagnosed configured with the temporary key to obtain a diagnostic result according to the information to be diagnosed carried in the diagnostic request.

[0065] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0066] In one possible design, after the diagnostic device sends a diagnostic request to the unit to be diagnosed and before receiving the diagnostic result sent by the unit to be diagnosed, it can also send a security heartbeat message to the key management system within the validity period corresponding to the temporary key according to a preset period, so that the key management system continues to validate the temporary key according to the security heartbeat message.

[0067] In one possible design, before the diagnostic device sends a security heartbeat message to the key management system within a preset period within the validity period corresponding to the temporary key, it can also use at least one characteristic information used to generate the temporary key to generate first verification information, and generate a security heartbeat message based on the first verification information, so that the key management system verifies the security heartbeat message based on the first verification information before continuing to validate the temporary key.

[0068] In a possible design, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value, wherein the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0069] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0070] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0071] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0072] In a possible design, the units to be diagnosed may refer to all the units to be diagnosed involved in this diagnosis.

[0073] In one possible design, the key authorization response may include a ciphertext, where the ciphertext is obtained by the key management system encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the key management system encrypting at least one feature information based on a first symmetric key. At least one feature information is carried in the key authorization request and sent to the key management system, and at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, where the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after receiving the key authorization response sent by the key management system, the diagnostic device can also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0074] In a possible design, the key authorization response may also include third verification information, which is obtained by the key management system based on the second symmetric key to encrypt the ciphertext and at least one feature information, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, before the diagnostic device uses the first symmetric key to encrypt at least one feature information to generate a transmission security key, it may also derive the second symmetric key based on the first symmetric key, use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information, and determine that the sixth verification information matches the third verification information.

[0075] In one possible design, after the diagnostic device uses the transmission security key to decrypt the ciphertext to obtain a temporary key, it can also generate fourth verification information based on the ciphertext, third verification information and one or more of at least one feature information, and send the fourth verification information to the key management system, so that the key management system verifies the fourth verification information before configuring the temporary key.

[0076] In a possible design, the transmission security key can satisfy the following formula:

[0077] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0078] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0079] Furthermore, the ciphertext can satisfy the following formula:

[0080] C = AES-GCM (tK, {M});

[0081] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0082] In a possible design, the second symmetric key may satisfy the following formula:

[0083] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0084] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0085] Furthermore, the sixth verification information may satisfy the following formula:

[0086] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0087] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0088] In a possible design, the fourth verification information may satisfy the following formula:

[0089] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0090] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0091] In a fourth aspect, the present application provides a vehicle diagnostic method, which is applicable to a unit to be diagnosed in a vehicle, and comprises: the unit to be diagnosed obtains a temporary key, receives a diagnostic request sent by a diagnostic device, and uses the temporary key to decrypt the diagnostic request to complete the diagnosis. The diagnostic request is generated by encrypting the temporary key, and the temporary key is independent of the long-term key in the vehicle.

[0092] In a possible design, the unit to be diagnosed in the vehicle obtains a temporary key, including: the unit to be diagnosed receives temporary key validation information sent by the key management system in the vehicle, and stores the temporary key carried in the temporary key validation information in a random access memory (RAM) according to the temporary key validation information. In this way, since RAM has the characteristic of losing data after power failure, if a diagnostic fault is found during the diagnosis process, or other reasons lead to the fact that the diagnosis is no longer desired, even if the validity period of the temporary key corresponding to this diagnosis has not expired, the unit to be diagnosed can be made to lose the temporary key corresponding to this diagnosis by powering off the vehicle, thereby achieving the purpose of invalidating the temporary key.

[0093] In a possible design, after the diagnosis unit obtains the temporary key, it can also receive temporary key expiration information sent by the key management system in the vehicle, and delete the temporary key stored in the RAM according to the temporary key expiration information.

[0094] In a fifth aspect, the present application provides a vehicle diagnostic system, including a diagnostic device and a unit to be diagnosed, the unit to be diagnosed may be located in the vehicle, and the diagnostic device is connected to the unit to be diagnosed. When performing the diagnosis, the diagnostic device may send a key authorization request to the unit to be diagnosed, and after receiving the key authorization request, the unit to be diagnosed may generate a temporary key and send a key authorization response to the diagnostic device, carrying the temporary key in the key authorization response. After receiving the key authorization response, the diagnostic device may use the temporary key carried in the key authorization response to initiate a diagnostic operation on the unit to be diagnosed, and the unit to be diagnosed may complete the diagnosis based on the temporary key. Among them, the temporary key is independent of the long-term key in the vehicle. The above design can complete the diagnostic operation between the diagnostic device and the unit to be diagnosed by generating a temporary key by the unit to be diagnosed, without the participation of other components in the vehicle. In this way, the normal operation of other components in the vehicle can be minimized, and the complexity of the diagnostic process can be reduced through two-party interaction.

[0095] In a possible design, the unit to be diagnosed can also generate temporary keys for other units to be diagnosed in the vehicle, which are used by the diagnostic device to diagnose other units to be diagnosed. In this way, the method can also manage the temporary keys of other diagnostic units through one or more units to be diagnosed, so that the diagnostic device can obtain the temporary keys of each unit to be diagnosed through communication interaction with the one or more units to be diagnosed, and there is no need to obtain the temporary keys through interaction with each unit to be diagnosed.

[0096] In one possible design, after receiving the key authorization response, the diagnostic device can use the temporary key carried in the key authorization response to encrypt the information to be diagnosed to generate a diagnostic request, and send the diagnostic request to the unit to be diagnosed. Correspondingly, after receiving the diagnostic request, the unit to be diagnosed can use the temporary key to decrypt the diagnostic request to obtain the information to be diagnosed, and then perform a diagnostic operation based on the information to be diagnosed to obtain a diagnostic result, and send the diagnostic result to the diagnostic device.

[0097] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0098] In one possible design, after the diagnostic device uses a temporary key to initiate a diagnostic operation on the unit to be diagnosed, the diagnostic device may also send a security heartbeat message to the unit to be diagnosed within the validity period corresponding to the temporary key and according to a preset period. If the unit to be diagnosed receives the security heartbeat message sent by the diagnostic device within the preset period, the unit to be diagnosed may continue to validate the temporary key in the unit to be diagnosed. If the unit to be diagnosed does not receive the security heartbeat message sent by the diagnostic device within the preset period, the unit to be diagnosed may invalidate the temporary key in the unit to be diagnosed.

[0099] In one possible design, before the diagnostic device sends a security heartbeat message to the unit to be diagnosed according to a preset period, it can also generate first verification information using at least one feature information used when generating a temporary key, and generate the security heartbeat message based on the first verification information. Correspondingly, after the unit to be diagnosed receives the security heartbeat message sent by the diagnostic device within the preset period, it can also generate second verification information based on at least one feature information used when generating the temporary key. If it is determined that the second verification information matches the first verification information, the temporary key can continue to take effect. Among them, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value. Among them, the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device.

[0100] In a possible design, the second verification information may satisfy the following formula:

[0101] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0102] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0103] In a possible design, after the unit to be diagnosed generates a temporary key and configures it to take effect, it may also invalidate the temporary key after a validity period corresponding to the temporary key has elapsed.

[0104] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0105] In a possible design, the units to be diagnosed may refer to all the units to be diagnosed involved in this diagnosis.

[0106] In one possible design, the key authorization request may include at least one feature information, such as at least one of a first random value, a feature identifier, or an authorization code, wherein the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the unit to be diagnosed sends a key authorization response to the diagnostic device, it may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, use the transmission security key to encrypt a temporary key to generate a ciphertext, and generate a key authorization response based on the ciphertext; correspondingly, after receiving the key authorization response sent by the unit to be diagnosed, the diagnostic device may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0107] In one possible design, before sending the key authorization response, the unit to be diagnosed may also derive a second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information to generate third verification information, and then generate a key authorization response based on the third verification information and the ciphertext; correspondingly, after receiving the key authorization response, the diagnostic device may also first derive a second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information in the key authorization response to generate sixth verification information, and when it is determined that the sixth verification information is the same as the third verification information, the ciphertext is decrypted to obtain a temporary key.

[0108] In one possible design, after decrypting the ciphertext to obtain the temporary key, the diagnostic device can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information, and send the fourth verification information to the unit to be diagnosed; correspondingly, after receiving the fourth verification information, the unit to be diagnosed can also use the ciphertext, the third verification information and one or more of at least one feature information to generate fifth verification information. If the fourth verification information and the fifth verification information match, the temporary key can be configured to the unit to be diagnosed in the vehicle.

[0109] In a possible design, the transmission security key can satisfy the following formula:

[0110] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0111] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0112] Furthermore, the ciphertext can satisfy the following formula:

[0113] C = AES-GCM (tK, {M});

[0114] Wherein, C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm using the counting mode and carrying the Galois message authentication code (GMAC), and {M} is the temporary key.

[0115] In a possible design, the second symmetric key may satisfy the following formula:

[0116] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0117] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0118] Furthermore, the third verification information may satisfy the following formula:

[0119] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0120] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0121] In a possible design, the fifth check information may satisfy the following formula:

[0122] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0123] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0124] In a sixth aspect, the present application provides a vehicle diagnostic method, which is applicable to a unit to be diagnosed in a vehicle, and the method includes: the unit to be diagnosed receives a key authorization request sent by a diagnostic device, generates a temporary key according to the key authorization request, and sends a key authorization response to the diagnostic device, carrying the temporary key in the key authorization response, after which the unit to be diagnosed can make the temporary key configuration effective and complete the diagnosis based on the temporary key. The temporary key is independent of the long-term key in the vehicle.

[0125] In a possible design, the unit to be diagnosed may also generate a temporary key for other units to be diagnosed in the vehicle, which is used by the diagnostic device to diagnose the other units to be diagnosed.

[0126] In one possible design, the unit to be diagnosed completes diagnosis based on a temporary key, including: the unit to be diagnosed receives a diagnostic request sent by a diagnostic device, uses a temporary key to decrypt the diagnostic request to obtain information to be diagnosed, performs a diagnostic operation based on the information to be diagnosed to obtain a diagnostic result, and sends the diagnostic result to the diagnostic device.

[0127] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0128] In a possible design, after the unit to be diagnosed sends a key authorization response to the diagnostic device, it can also wait to receive a security heartbeat message sent by the diagnostic device. If the security heartbeat message sent by the diagnostic device is not received within a preset period, the temporary key can be invalidated. The security heartbeat message is sent by the diagnostic device to the unit to be diagnosed in a periodic manner within the validity period corresponding to the temporary key.

[0129] In one possible design, the security heartbeat message may include first verification information, and the first verification information is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value. The feature identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, when the unit to be diagnosed receives a security heartbeat message sent by the diagnostic device within a preset period, the unit to be diagnosed can generate second verification information based on at least one feature information used when generating the temporary key, and when it is determined that the second verification information matches the first verification information, the temporary key can continue to be effective.

[0130] In a possible design, the second verification information may satisfy the following formula:

[0131] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0132] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0133] In a possible design, after the diagnosis unit makes the temporary key configuration effective, it may also invalidate the temporary key after the validity period corresponding to the temporary key has expired.

[0134] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0135] In a possible design, the unit to be diagnosed makes the temporary key configuration effective, including: the unit to be diagnosed configures the temporary key to each unit to be diagnosed required for this diagnosis.

[0136] In one possible design, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the unit to be diagnosed sends a key authorization response to the diagnostic device, it can also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain a temporary key.

[0137] In a possible design, the unit to be diagnosed generates a key authorization response based on the ciphertext, including: the unit to be diagnosed first encrypts the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generates a key authorization response based on the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used by the diagnostic device to perform verification before decrypting the ciphertext.

[0138] In a possible design, after the diagnostic unit sends the key authorization response to the diagnostic device and before the temporary key configuration takes effect, it can also receive fourth verification information sent by the diagnostic device, use the ciphertext, the third verification information, and one or more of the at least one feature information to generate fifth verification information, and determine that the fourth verification information and the fifth verification information match. The fourth verification information is generated based on one or more of the ciphertext, the third verification information, and the at least one feature information.

[0139] In a possible design, the transmission security key can satisfy the following formula:

[0140] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0141] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0142] Furthermore, the ciphertext can satisfy the following formula:

[0143] C = AES-GCM (tK, {M});

[0144] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0145] In a possible design, the second symmetric key may satisfy the following formula:

[0146] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0147] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0148] Furthermore, the third verification information may satisfy the following formula:

[0149] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0150] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0151] In a possible design, the fifth check information may satisfy the following formula:

[0152] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0153] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0154] In a possible design, the unit to be diagnosed validates the temporary key configuration, including: the unit to be diagnosed stores the temporary key in the RAM of the unit to be diagnosed. Correspondingly, the unit to be diagnosed invalidates the temporary key, including: the unit to be diagnosed deletes the temporary key stored in the RAM.

[0155] In the seventh aspect, the present application provides a vehicle diagnostic method, which is applicable to a diagnostic device, and the method includes: the diagnostic device sends a key authorization request to a unit to be diagnosed in the vehicle, so that the unit to be diagnosed generates a temporary key based on the key authorization request and configures it to take effect, and the temporary key is independent of the long-term key in the vehicle; thereafter, the diagnostic device receives a key authorization response sent by the unit to be diagnosed, the key authorization response includes the temporary key, and the diagnostic device uses the temporary key to initiate a diagnostic operation on the unit to be diagnosed.

[0156] In one possible design, the diagnostic device uses a temporary key to initiate a diagnostic operation on the unit to be diagnosed, including: the diagnostic device first uses the temporary key to encrypt the information to be diagnosed to generate a diagnostic request, and sends the diagnostic request to the unit to be diagnosed, and then receives the diagnostic result sent by the unit to be diagnosed. The diagnostic request is used by the unit to be diagnosed to diagnose and obtain a diagnostic result based on the information to be diagnosed obtained by parsing the diagnostic request using the temporary key.

[0157] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0158] In one possible design, after the diagnostic device sends a diagnostic request to the unit to be diagnosed and before receiving the diagnostic result sent by the unit to be diagnosed, it can also send a security heartbeat message to the unit to be diagnosed within the validity period corresponding to the temporary key according to a preset period, so that the unit to be diagnosed continues to validate the temporary key according to the security heartbeat message.

[0159] In one possible design, before the diagnostic device sends a security heartbeat message to the unit to be diagnosed within the validity period corresponding to the temporary key and according to a preset period, it can also use at least one characteristic information used to generate the temporary key to generate first verification information, and generate a security heartbeat message based on the first verification information, so that the unit to be diagnosed can verify the security heartbeat message based on the first verification information before continuing to validate the temporary key.

[0160] In a possible design, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value, wherein the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0161] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0162] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0163] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0164] In one possible design, the key authorization response may include a ciphertext, where the ciphertext is obtained by the unit to be diagnosed encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the unit to be diagnosed encrypting at least one feature information based on a first symmetric key. At least one feature information is carried in the key authorization request and sent to the unit to be diagnosed, and at least one feature information includes at least one of a first random value, a characteristic identifier, or an authorization code, where the first random value is generated by the diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after the diagnostic device receives the key authorization response sent by the unit to be diagnosed, it can also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0165] In a possible design, the key authorization response may also include third verification information, which is obtained by the unit to be diagnosed using the second symmetric key to encrypt the ciphertext and at least one feature information, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, before the diagnostic device uses the first symmetric key to encrypt at least one feature information to generate a transmission security key, it may also derive the second symmetric key based on the first symmetric key, use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information, and determine that the sixth verification information matches the third verification information.

[0166] In one possible design, after the diagnostic device uses the transmission security key to decrypt the ciphertext to obtain a temporary key, it can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information, and send the fourth verification information to the unit to be diagnosed, so that the unit to be diagnosed can verify the fourth verification information before configuring the effective temporary key.

[0167] In a possible design, the transmission security key can satisfy the following formula:

[0168] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0169] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0170] Furthermore, the ciphertext can satisfy the following formula:

[0171] C = AES-GCM (tK, {M});

[0172] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0173] In a possible design, the second symmetric key may satisfy the following formula:

[0174] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0175] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0176] Furthermore, the sixth verification information may satisfy the following formula:

[0177] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0178] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0179] In a possible design, the fourth verification information may satisfy the following formula:

[0180] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0181] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0182] In an eighth aspect, the present application provides a vehicle diagnostic device, which is a key management system in a vehicle, and includes: a transceiver unit, used to receive a key authorization request sent by a diagnostic device, and send a key authorization response to the diagnostic device, the key authorization response including a temporary key; a generation unit, used to generate a temporary key according to the key authorization request, and the temporary key is independent of the long-term key in the vehicle; a configuration unit, used to configure the temporary key to the unit to be diagnosed in the vehicle, so that the diagnostic device and the unit to be diagnosed complete the diagnosis based on the temporary key.

[0183] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0184] In a possible design, after the transceiver unit sends a key authorization response to the diagnostic device, the transceiver unit can also wait to receive a security heartbeat message sent by the diagnostic device. If the security heartbeat message sent by the diagnostic device is not received within a preset period, the configuration unit can invalidate the temporary key in the unit to be diagnosed. The security heartbeat message is sent by the diagnostic device to the key management system in a periodic manner within the validity period corresponding to the temporary key.

[0185] In one possible design, the security heartbeat message may include first verification information, and the first verification information is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value; the feature identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device. In this case, when the transceiver unit receives the security heartbeat message sent by the diagnostic device within a preset period, the generation unit can also generate second verification information based on at least one feature information used when generating the temporary key, and the configuration unit can continue to validate the temporary key when it is determined that the second verification information matches the first verification information.

[0186] In a possible design, the second verification information may satisfy the following formula:

[0187] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0188] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0189] In a possible design, after the configuration unit configures the temporary key to the unit to be diagnosed in the vehicle, the configuration unit may also invalidate the temporary key in the unit to be diagnosed after a valid time period corresponding to the temporary key has elapsed.

[0190] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0191] In a possible design, the configuration unit is specifically used to: configure the temporary key to each unit to be diagnosed required for this diagnosis.

[0192] In one possible design, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the transceiver unit sends a key authorization response to the diagnostic device, the generation unit may also first use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt the temporary key using the transmission security key.

[0193] In one possible design, the generating unit is specifically used to: first encrypt the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generate a key authorization response according to the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used for the diagnostic device to perform verification before decrypting the ciphertext.

[0194] In a possible design, after the transceiver unit sends the key authorization response to the diagnostic device: the transceiver unit may also receive the fourth verification information sent by the diagnostic device; the generation unit may also use the ciphertext, the third verification information, and one or more of at least one feature information to generate the fifth verification information; if the configuration unit determines that the fourth verification information and the fifth verification information match, the temporary key may be configured to the unit to be diagnosed in the vehicle; if the configuration unit determines that the fourth verification information and the fifth verification information do not match, the temporary key may not be configured to the unit to be diagnosed in the vehicle. The fourth verification information is generated based on one or more of the ciphertext, the third verification information, and at least one feature information.

[0195] In a possible design, the transmission security key can satisfy the following formula:

[0196] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0197] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0198] Furthermore, the ciphertext can satisfy the following formula:

[0199] C = AES-GCM (tK, {M});

[0200] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0201] In a possible design, the second symmetric key may satisfy the following formula:

[0202] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0203] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0204] Furthermore, the third verification information may satisfy the following formula:

[0205] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0206] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0207] In a possible design, the fifth check information may satisfy the following formula:

[0208] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0209] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0210] In the ninth aspect, the present application provides a vehicle diagnostic device, which is a diagnostic equipment, and includes: a transceiver unit, used to send a key authorization request to a key management system in the vehicle, and receive a key authorization response sent by the key management system, the key authorization response includes a temporary key, and the temporary key is independent of the long-term key in the vehicle; wherein the key authorization request is used by the key management system to generate a temporary key and configure it to the unit to be diagnosed in the vehicle; a diagnostic unit, used to initiate a diagnostic operation on the unit to be diagnosed using the temporary key.

[0211] In one possible design, the diagnosis unit is specifically used to: encrypt the information to be diagnosed using a temporary key to generate a diagnosis request; the transceiver unit is also used to: send a diagnosis request to the unit to be diagnosed, and receive a diagnosis result sent by the unit to be diagnosed. The diagnosis request is used for the unit to be diagnosed configured with the temporary key to obtain a diagnosis result according to the information to be diagnosed carried in the diagnosis request.

[0212] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0213] In one possible design, after the transceiver unit sends a diagnosis request to the unit to be diagnosed and before receiving the diagnosis result sent by the unit to be diagnosed, the transceiver unit can also send a security heartbeat message to the key management system within the validity period corresponding to the temporary key according to a preset period, so that the key management system continues to validate the temporary key according to the security heartbeat message.

[0214] In one possible design, before the transceiver unit sends a security heartbeat message to the key management system, the diagnostic unit may also use at least one feature information used when generating a temporary key to generate first verification information, and generate a security heartbeat message based on the first verification information, so that the key management system verifies the security heartbeat message based on the first verification information before continuing to validate the temporary key.

[0215] In a possible design, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value, wherein the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0216] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0217] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0218] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0219] In a possible design, the units to be diagnosed may refer to all the units to be diagnosed involved in this diagnosis.

[0220] In one possible design, the key authorization response may include a ciphertext, where the ciphertext is obtained by the key management system encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the key management system encrypting at least one feature information based on a first symmetric key. At least one feature information is carried in the key authorization request and sent to the key management system, and at least one feature information includes at least one of a first random value, a characteristic identifier, or an authorization code, where the first random value is generated by the diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after the transceiver unit receives the key authorization response sent by the key management system, the diagnostic unit may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0221] In a possible design, the key authorization response may also include third verification information, which is obtained by the key management system based on the second symmetric key to encrypt the ciphertext and at least one feature information, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, after the transceiver unit receives the key authorization response, the diagnostic unit may also first derive the second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information. If it is determined that the sixth verification information matches the third verification information, the diagnostic unit may use the first symmetric key to encrypt at least one feature information to generate a transmission security key. If it is determined that the sixth verification information does not match the third verification information, the diagnostic unit may not generate a transmission security key.

[0222] In one possible design, after the diagnostic unit uses the transmission security key to decrypt the ciphertext to obtain a temporary key: the diagnostic unit can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information: the transceiver unit can also send the fourth verification information to the key management system so that the key management system verifies the fourth verification information before configuring the temporary key.

[0223] In a possible design, the transmission security key can satisfy the following formula:

[0224] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0225] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0226] Furthermore, the ciphertext can satisfy the following formula:

[0227] C = AES-GCM (tK, {M});

[0228] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0229] In a possible design, the second symmetric key may satisfy the following formula:

[0230] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0231] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0232] Furthermore, the sixth verification information may satisfy the following formula:

[0233] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0234] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0235] In a possible design, the fourth verification information may satisfy the following formula:

[0236] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0237] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0238] In the tenth aspect, the present application provides a vehicle diagnostic device, which is a unit to be diagnosed in a vehicle, and includes: an acquisition unit, used to obtain a temporary key, the temporary key is independent of the long-term key in the vehicle; a transceiver unit, used to receive a diagnostic request sent by a diagnostic device, the diagnostic request is generated by encrypting the temporary key; a diagnostic unit, used to decrypt the diagnostic request using the temporary key to complete the diagnosis.

[0239] In one possible design, the transceiver unit is also used to: receive temporary key validation information sent by the key management system in the vehicle; the acquisition unit is specifically used to: obtain the temporary key from the temporary key validation information; the diagnostic unit is also used to: store the temporary key in a random access memory (RAM).

[0240] In a possible design, after the acquisition unit acquires the temporary key: the transceiver unit can also receive temporary key expiration information sent by the key management system in the vehicle; the diagnostic unit can also delete the temporary key stored in the RAM according to the temporary key expiration information.

[0241] In an eleventh aspect, the present application provides a vehicle, comprising a vehicle diagnostic system as described in any of the first aspects above.

[0242] In the twelfth aspect, the present application provides a vehicle diagnostic device, which is a unit to be diagnosed in a vehicle, and includes: a transceiver unit, used to receive a key authorization request sent by a diagnostic device, and send a key authorization response to the diagnostic device, the key authorization response including a temporary key, and the temporary key is independent of the long-term key in the vehicle; a generation unit, used to generate the temporary key according to the key authorization request; and a diagnostic unit, used to complete the diagnosis based on the temporary key.

[0243] In a possible design, the generating unit may also generate temporary keys for other units to be diagnosed in the vehicle, which are used by the diagnostic device to diagnose the other units to be diagnosed.

[0244] In one possible design, the transceiver unit is also used to: receive a diagnostic request sent by a diagnostic device; the diagnostic unit is specifically used to: use a temporary key to decrypt the diagnostic request to obtain information to be diagnosed, and perform a diagnostic operation based on the information to be diagnosed to obtain a diagnostic result; the transceiver unit is also used to: send the diagnostic result to the diagnostic device.

[0245] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0246] In a possible design, after the transceiver unit sends a key authorization response to the diagnostic device, the transceiver unit can also wait to receive a security heartbeat message sent by the diagnostic device. If the security heartbeat message sent by the diagnostic device is not received within a preset period, the diagnostic unit can invalidate the temporary key. The security heartbeat message is sent by the diagnostic device to the unit to be diagnosed in a periodic manner within the effective period corresponding to the temporary key.

[0247] In one possible design, the security heartbeat message may include first verification information, and the first verification information is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value. Among them, the feature identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, when the transceiver unit receives the security heartbeat message sent by the diagnostic device within a preset period, then: the generation unit can also generate second verification information based on at least one feature information used when generating the temporary key; the diagnostic unit can continue to validate the temporary key when it is determined that the second verification information matches the first verification information.

[0248] In a possible design, the second verification information may satisfy the following formula:

[0249] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0250] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0251] In a possible design, after the generation unit generates the temporary key according to the key authorization request, the diagnosis unit may also configure the temporary key to take effect, and invalidate the temporary key after the validity period corresponding to the temporary key has expired.

[0252] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0253] In a possible design, after the generation unit generates the temporary key according to the key authorization request, the diagnosis unit may also configure the temporary key to each unit to be diagnosed required for this diagnosis.

[0254] In one possible design, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the transceiver unit sends a key authorization response to the diagnostic device, the generation unit may also first use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt the temporary key using the transmission security key.

[0255] In one possible design, the generating unit is specifically used to: first encrypt the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generate a key authorization response according to the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used for the diagnostic device to perform verification before decrypting the ciphertext.

[0256] In a possible design, after the transceiver unit sends the key authorization response to the diagnostic device: the transceiver unit may also receive fourth verification information sent by the diagnostic device, and the generation unit may also use the ciphertext, the third verification information, and one or more of at least one feature information to generate fifth verification information, and if the diagnostic unit determines that the fourth verification information and the fifth verification information match, the temporary key configuration may be effective. The fourth verification information is generated based on one or more of the ciphertext, the third verification information, and at least one feature information.

[0257] In a possible design, the transmission security key can satisfy the following formula:

[0258] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0259] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0260] Furthermore, the ciphertext can satisfy the following formula:

[0261] C = AES-GCM (tK, {M});

[0262] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0263] In a possible design, the second symmetric key may satisfy the following formula:

[0264] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0265] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0266] Furthermore, the third verification information may satisfy the following formula:

[0267] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0268] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0269] In a possible design, the fifth check information may satisfy the following formula:

[0270] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0271] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0272] In one possible design, after the generation unit generates the temporary key according to the temporary key authorization request, the diagnosis unit may also store the temporary key in the RAM of the unit to be diagnosed, and delete the temporary key stored in the RAM when the temporary key is to be invalidated.

[0273] In the thirteenth aspect, the present application provides a vehicle diagnostic device, which is a diagnostic equipment, and includes: a transceiver unit, used to send a key authorization request to the unit to be diagnosed in the vehicle, and receive a key authorization response sent by the unit to be diagnosed; wherein the key authorization request is used to generate a temporary key for the unit to be diagnosed, the temporary key is independent of the long-term key in the vehicle, and the key authorization response includes the temporary key; a diagnostic unit, used to initiate a diagnostic operation on the unit to be diagnosed using the temporary key.

[0274] In a possible design, the diagnosis unit is specifically used to: encrypt the information to be diagnosed using a temporary key to generate a diagnosis request; the transceiver unit is also used to: send a diagnosis request to the unit to be diagnosed, and receive a diagnosis result sent by the unit to be diagnosed. The diagnosis request is used by the unit to be diagnosed to diagnose and obtain a diagnosis result based on the information to be diagnosed obtained by parsing the diagnosis request using the temporary key.

[0275] In a possible design, the temporary key may also correspond to a validity period, and the validity period corresponding to the temporary key may be preconfigured, or may be indicated through a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0276] In one possible design, after the transceiver unit sends a diagnostic request to the unit to be diagnosed and before receiving the diagnostic result sent by the unit to be diagnosed, the transceiver unit can also send a security heartbeat message to the unit to be diagnosed within the validity period corresponding to the temporary key according to a preset period, so that the unit to be diagnosed continues to validate the temporary key according to the security heartbeat message.

[0277] In one possible design, before the transceiver unit sends a security heartbeat message to the unit to be diagnosed, the diagnostic unit may also use at least one feature information used when generating a temporary key to generate first verification information, and generate a security heartbeat message based on the first verification information, so that the unit to be diagnosed can verify the security heartbeat message based on the first verification information before continuing to validate the temporary key.

[0278] In a possible design, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value, wherein the feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0279] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0280] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0281] In a possible design, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0282] In one possible design, the key authorization response may include a ciphertext, where the ciphertext is obtained by the unit to be diagnosed encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the unit to be diagnosed encrypting at least one feature information based on a first symmetric key. At least one feature information is carried in the key authorization request and sent to the unit to be diagnosed, and at least one feature information includes at least one of a first random value, a characteristic identifier, or an authorization code, where the first random value is generated by the diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after the transceiver unit receives the key authorization response sent by the unit to be diagnosed, the diagnostic unit may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0283] In a possible design, the key authorization response may also include third verification information, which is obtained by the unit to be diagnosed by encrypting the ciphertext and at least one feature information based on the second symmetric key, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, the diagnostic unit may also first derive the second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information. If it is determined that the sixth verification information matches the third verification information, the diagnostic unit may use the first symmetric key to encrypt at least one feature information to generate a transmission security key. If it is determined that the sixth verification information does not match the third verification information, the diagnostic unit may not generate a transmission security key.

[0284] In one possible design, after the diagnostic unit uses the transmission security key to decrypt the ciphertext to obtain a temporary key: the diagnostic unit can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information, and the transceiver unit can also send the fourth verification information to the unit to be diagnosed, so that the unit to be diagnosed can verify the fourth verification information before configuring the effective temporary key.

[0285] In a possible design, the transmission security key can satisfy the following formula:

[0286] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0287] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0288] Furthermore, the ciphertext can satisfy the following formula:

[0289] C = AES-GCM (tK, {M});

[0290] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0291] In a possible design, the second symmetric key may satisfy the following formula:

[0292] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0293] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0294] Furthermore, the sixth verification information may satisfy the following formula:

[0295] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0296] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0297] In a possible design, the fourth verification information may satisfy the following formula:

[0298] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0299] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0300] In a fourteenth aspect, the present application provides a vehicle comprising a unit to be diagnosed as described in any of the above-mentioned aspects of the twelfth aspect, or comprising a unit to be diagnosed as described in any of the above-mentioned aspects of the twelfth aspect and a diagnostic device as described in any of the above-mentioned aspects of the thirteenth aspect.

[0301] In the fifteenth aspect, the present application provides a vehicle diagnostic device, comprising a processor and a communication interface, wherein the communication interface is used to receive signals from other communication devices other than the vehicle diagnostic device and transmit them to the processor or send signals from the processor to other communication devices other than the vehicle diagnostic device; the processor is used to implement a method as described in any one of the second aspect above, or implement a method as described in any one of the third aspect above, or implement a method as described in any one of the fourth aspect above, or implement a method as described in any one of the sixth aspect above, or implement a method as described in any one of the seventh aspect through a logic circuit or execution code instructions.

[0302] In the sixteenth aspect, the present application provides a vehicle diagnostic device, which may include a processor, the processor is connected to a memory, the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the device executes a method as described in any one of the second aspects above, or executes a method as described in any one of the third aspects above, or executes a method as described in any one of the fourth aspects above, or executes a method as described in any one of the sixth aspects above, or executes a method as described in any one of the seventh aspects above.

[0303] In the seventeenth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed, it implements the method as described in any one of the second aspect above, or implements the method as described in any one of the third aspect above, or implements the method as described in any one of the fourth aspect above, or implements the method as described in any one of the sixth aspect above, or implements the method as described in any one of the seventh aspect above.

[0304] In aspect 18, the present application provides a computer program product, comprising a computer program or instructions. When the computer program or instructions are executed by a communication device, it implements a method as described in any one of the second aspect above, or implements a method as described in any one of the third aspect above, or implements a method as described in any one of the fourth aspect above, or implements a method as described in any one of the sixth aspect above, or implements a method as described in any one of the seventh aspect above.

[0305] In the nineteenth aspect, the present application provides a chip, which may include a processor and an interface, the processor being used to read instructions through the interface to execute a method as described in any one of the second aspect above, or a method as described in any one of the third aspect above, or a method as described in any one of the fourth aspect above, or a method as described in any one of the sixth aspect above, or a method as described in any one of the seventh aspect above.

[0306] For the beneficial effects of the second to nineteenth aspects mentioned above, please refer to the technical effects that can be achieved by the corresponding design in the first aspect mentioned above, and they will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0307] Figure 1 A schematic diagram of a possible system architecture applicable to the embodiments of the present application;

[0308] Figure 2 An exemplary diagram of a life cycle of a long-term key in a vehicle provided by an embodiment of the present application is shown;

[0309] Figure 3 A schematic diagram showing a flow chart corresponding to the vehicle diagnostic method provided in the first embodiment of the present application;

[0310] Figure 4 A schematic diagram showing a flow chart corresponding to a diagnostic method based on the SecOC protocol provided in the present application is exemplified;

[0311] Figure 5 An exemplary method of assembling a diagnostic request provided by an embodiment of the present application is shown;

[0312] Fig. 6A A schematic diagram of a method for configuring a temporary key is exemplarily shown;

[0313] Figure 6B Another schematic diagram of a method for configuring a temporary key is shown as an example;

[0314] Figure 6C A schematic diagram showing another method for configuring a temporary key is exemplified;

[0315] Figure 7A schematic diagram showing a flow chart corresponding to the vehicle diagnostic method provided in the second embodiment of the present application;

[0316] Figure 8 The following is a flow chart showing the vehicle diagnostic method according to the third embodiment of the present application;

[0317] Fig. 9 A schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of the present application;

[0318] Fig.10 A schematic diagram of the structure of another vehicle diagnostic device provided in an embodiment of the present application;

[0319] Fig.11 A schematic diagram of the structure of another vehicle diagnostic device provided in an embodiment of the present application;

[0320] Fig.12 A schematic diagram of the structure of another vehicle diagnostic device provided in an embodiment of the present application;

[0321] Fig.13 A schematic diagram of the structure of another vehicle diagnostic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0322] It should be noted that the diagnostic scheme in the embodiment 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 (V2V), etc. For example, it can be applied to a vehicle with a key authentication function, or other devices with a key authentication function in a vehicle. The other devices include but are not limited to: other sensors such as a vehicle-mounted terminal, a vehicle-mounted controller, 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. The vehicle can implement the diagnostic method provided by the present application through the vehicle-mounted terminal, the vehicle-mounted controller, the vehicle-mounted module, the vehicle-mounted module, the vehicle-mounted component, the vehicle-mounted chip, the vehicle-mounted unit, the vehicle-mounted radar or the vehicle-mounted camera. Of course, the diagnostic scheme in the embodiment of the present application can also be used for other intelligent terminals with a key authentication function other than the vehicle, or be set in other intelligent terminals with a key authentication function other than the vehicle, or be set in a component of the intelligent terminal. The intelligent terminal can be an intelligent transportation device, an intelligent home device, a robot, etc. For example, it includes but is not limited to smart terminals or controllers, chips, other sensors such as radars or cameras, and other components within smart terminals.

[0323] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0324] Figure 1 A possible system architecture diagram applicable to the embodiment of the present application is shown in FIG. Figure 1 The system architecture shown includes a vehicle to be diagnosed and a diagnostic device. Among them, the vehicle to be diagnosed can be any vehicle with a key authentication function. The diagnostic device can refer to a diagnostic instrument, a diagnostic server, or a diagnostic server cluster. It should be understood that the embodiment of the present application does not limit the number of vehicles to be diagnosed and the number of diagnostic devices in the system architecture. For example, one diagnostic device can only interact with one vehicle to be diagnosed, or it can interact with multiple vehicles to be diagnosed. Moreover, in addition to the vehicle to be diagnosed and the diagnostic device, the system architecture to which the embodiment of the present application is applicable may also include other devices, such as supplier equipment, manufacturer equipment, production line equipment, and sales equipment, etc., which are not limited to the embodiment of the present application. In addition, the diagnostic device in the embodiment of the present application can integrate all functions on an independent physical device, or distribute the functions on multiple independent physical devices, which are not limited to the embodiment of the present application.

[0325] In the embodiments of the present application, vehicle diagnosis can be implemented in a wired manner or in a wireless manner. For example, when vehicle diagnosis is implemented based on a wired manner, the diagnostic device is usually provided with a diagnostic line, and a diagnostic interface is preset on the vehicle to be diagnosed. The diagnostic personnel can directly insert one end of the diagnostic line of the diagnostic device into the diagnostic interface of the vehicle to be diagnosed, and then input the diagnostic command on the diagnostic device so that the diagnostic command is sent to the vehicle to be diagnosed through the diagnostic line. Among them, the diagnostic interface can refer to a unified diagnostic services (UDS) interface, or an on-board diagnostics (OBD) interface, or other interfaces that can realize the command transmission function, without limitation. When vehicle diagnosis is implemented based on a wireless manner, the diagnostic device and the vehicle to be diagnosed can have near-field communication functions such as Bluetooth or wireless local area network (WLAN). The diagnostic personnel can first connect the diagnostic device and the vehicle to be diagnosed through the near-field communication function of the diagnostic device and the vehicle to be diagnosed, and then input the diagnostic command on the diagnostic device so that the diagnostic command is transmitted to the vehicle to be diagnosed via wireless means. Exemplarily, the diagnostic device may also be provided with a liquid crystal display screen. After obtaining the diagnostic results, the diagnostic device may also synchronously display the diagnostic results on the liquid crystal display screen to remind the diagnostic personnel to check the diagnostic results in time and quickly identify the fault location and cause.

[0326] The following is based on Figure 1 The system architecture shown in the figure first introduces some terms involved in this application.

[0327] (1) Electronic control unit (ECU).

[0328] In the embodiment of the present application, the interior of the vehicle to be diagnosed may be equipped with multiple ECUs, such as Figure 1 ECU1, ECU 2, ..., ECU N are shown, and N is a positive integer. Each ECU can have its own specific functions, and also supports simple sensor data processing and complex logic calculations. Common ECUs currently include but are not limited to: vehicle sensors, vehicle cameras, multi-domain controllers (MDC), automated-driving control units (ADCU), telematics boxes (T-Box), cockpit domain controllers (CDC), vehicle gateways, vehicle control units (VCU), battery management systems (BMS), thermal management systems (TMS), power distribution units (PDU), etc.

[0329] In the embodiment of the present application, each ECU in the vehicle to be diagnosed can rely on the communication technology set when the vehicle to be diagnosed leaves the factory to exchange messages. These communication technologies can be, for example, local internet (LIN) technology, Flexray network technology or controller area network (CAN) technology, or other communication technologies for realizing message interaction. When relying on CAN technology to exchange messages, 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 has only a message identifier, but does not carry a source address or a destination address. Each ECU connected to the CAN bus can choose which message frame to receive by the message identifier. Although the message interaction method based on CAN technology has strong real-time performance and reliability, there is no built-in security function in CAN technology. In this case, once the attacker deciphers the CAN bus, each CAN message frame injected by the attacker may be read by the ECU in the vehicle to be diagnosed and considered as a legitimate CAN message frame, so that the attacker can completely control the function of the vehicle to be diagnosed, such as braking or acceleration, which is very unsafe for users to use the vehicle.

[0330] In order to solve the above problems, each ECU in the vehicle to be diagnosed should also 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 the 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 be an illegal control command injected into the CAN bus by an illegal person, so the ECU can not perform the corresponding control operation to prevent illegal personnel from controlling the vehicle. If the parsing is successful, it means that the CAN message frame belongs to a legal control command injected into the CAN bus by a legal person (such as the owner), so the ECU can perform the corresponding control operation. 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 owner.

[0331] (2) Key management system (KMS).

[0332] In the embodiment of the present application, the interior of the vehicle to be diagnosed may also be equipped with a KMS, such as Figure 1The KMS shown in the figure. KMS is mainly responsible for generating keys, managing keys and clearing keys in the vehicle to be diagnosed. These keys include the long-term keys introduced above. Unlike traditional information and communications technology (ICT), most ECUs in the Internet of Vehicles follow the EVITA standard and the secure hardware extension (SHE) standard. For example, considering the performance and cost of setting keys under the EVITA standard and the SHE standard, the long-term keys in the KMS can be set as symmetric keys.

[0333] Figure 2 The following is an exemplary diagram of a life cycle of a long-term key in a vehicle provided by an embodiment of the present application. Figure 2 As shown, the entire life cycle of the long-term key in the car involves communication interactions between the original equipment manufacturer (OEM), the supplier, and the vehicle sales point. Among them, the OEM side can specifically include the OEM R&D line and the OEM production line. The supplier side can specifically include chip suppliers and component suppliers. For ease of understanding, whether it is the chips provided by chip suppliers or the ECUs or vehicle components assembled by component suppliers using these chips, they are collectively referred to as ECUs. The supplier side can specifically include the supplier R&D line and the supplier production line. As shown in the figure, the long-term key in the car has a life cycle of 10.1 seconds, which is 10 seconds. Figure 2 As shown, the entire life cycle of the long-term key in the car can include the following stages:

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

[0335] In stage 202, the OEM R&D line sends the key hierarchy and symmetric key 1 to the supplier R&D line. The sending operation needs to be performed in a secure and confidential environment, such as by arranging a special person to deliver it secretly, or by transmitting it in an encrypted peer-to-peer (P2P) manner, or by other secure communication methods, without limitation.

[0336] In stage 203, the supplier R&D line derives the symmetric key 2 provided by the supplier based on the symmetric key 1 and the key hierarchy. The symmetric key 2 may include the root key of the chip required for assembling the ECU, the root key of the ECU required for assembling the vehicle component or the vehicle, and the root key of the vehicle component assembled from the ECU. The symmetric key 2 may also be configured to be updateable, that is, the symmetric key 2 may be changed according to different production environments.

[0337] In stage 204, the supplier production line applies for a key from the supplier R&D line when assembling ECUs or vehicle parts.

[0338] In stage 205, the supplier R&D line returns symmetric key 1 and symmetric key 2 to the supplier production line.

[0339] In stage 206, the supplier production line calls the hardware security module (HSM) or SHE standard to encapsulate symmetric key 1 and symmetric key 2 in their respective ECUs or vehicle components.

[0340] In stage 207, the supplier production line notifies the OEM production line to assemble the whole vehicle.

[0341] In stage 208, the OEM production line assembles the whole vehicle based on the ECU or vehicle parts encapsulating the symmetric key 1 and the symmetric key 2, and applies for the key from the OEM R&D line during the assembly process.

[0342] In stage 209, the OEM R&D line returns the symmetric key 3 to the OEM production line. The symmetric key 3 may include the root key and working key preset by the OEM side. The symmetric key 3 is suitable for the after-sales stage of the vehicle, for example, for replacing the ECU or vehicle parts, or updating the software configuration.

[0343] In stage 210, the OEM production line encapsulates the symmetric key 3 in the vehicle, and then provides the vehicle to a vehicle sales point for sale. At this point, the vehicle is simultaneously encapsulated with the symmetric key 1, the symmetric key 2, and the symmetric key 3.

[0344] In stage 211, after the vehicle is sold, if the ECU or vehicle parts in the vehicle are damaged, or the vehicle software configuration needs to be updated, the owner can also place the vehicle at the vehicle sales point, and the vehicle sales point will apply to the OEM for after-sales service based on the symmetric key 3. In addition, after the vehicle is sold, the owner can also pre-install some owner keys in the vehicle according to the prompt. At this time, the vehicle is encapsulated with symmetric key 1, symmetric key 2, symmetric key 3 and the owner key at the same time.

[0345] It should be understood that all operations on the OEM R&D line side in the above-mentioned stages can be completed through the administrator set up on the OEM side and the key management system on the OEM side, and all operations on the supplier R&D line side can be completed through the administrator set up on the supplier side and the key management system on the supplier R&D line side. This application does not provide specific explanations on this.

[0346] according to Figure 2 As shown in the content, during 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 key 1 preset by the OEM R&D line according to business needs, symmetric key 2 derived from symmetric key 1 by the supplier R&D line, symmetric key 3 preset by the OEM side, and the car owner's key, etc. These long-term keys can be applied to different scenarios respectively. For example, Table 1 exemplifies an application scenario of each long-term key managed by a KMS.

[0347]

[0348] Table 1

[0349] As shown in Table 1, the long-term keys managed by the KMS in the car are not only used for mutual authentication between the various ECUs in the car, but also for mutual authentication between the ECUs in the car and external devices. Therefore, long-term keys play a vital role in the vehicle. Once the long-term keys are leaked outside the car, illegal personnel outside the car are likely to use these long-term keys to perform some illegal operations on the vehicle, which is not conducive to improving the user's car experience.

[0350] (3) Vehicle diagnosis.

[0351] In the process of vehicle development, vehicle diagnosis is mainly applicable to the following four stages: development stage; experimental stage (such as B / C / D sample experiment or DVP experiment); component production stage; vehicle assembly, end of line (EOL) and after-sales stage. Before the fourth stage (i.e. before the vehicle leaves the factory), the R&D personnel will also pre-install a diagnostic module in the vehicle and pre-define some diagnostic services in the diagnostic module. The diagnostic module is connected to each ECU in the vehicle through a standard UDS diagnostic interface. When certain faults occur, the diagnostic module can automatically call the pre-defined diagnostic service, thereby issuing a diagnostic request in the vehicle to diagnose and repair the fault. For example, in vehicle diagnosis that relies on CAN technology, the pre-defined diagnostic services mainly include processing capability diagnosis and internal diagnosis. Processing function diagnosis can include the ability to obtain fault codes, input / output control capability diagnosis, security access function diagnosis, data acquisition function diagnosis, program control function diagnosis, and refresh function diagnosis. Internal diagnosis can include ECU initialization diagnosis, fault self-detection diagnosis when the ECU is turned off, and continuous fault self-detection diagnosis when the ECU is turned off. Vehicle diagnosis that relies on CAN technology can not only provide the ability to quickly access diagnostic results, but also control each ECU to perform its own functions without disconnecting the CAN bus. In this type of vehicle diagnosis, the various ECUs in the vehicle can be divided into the following two categories based on the different processing methods of the results of the fault self-detection diagnosis: the main ECU node, which can determine whether it has a fault based on the diagnostic results of the fault self-detection, and can store the corresponding fault information if it is determined that it has a fault; the auxiliary ECU node, which can determine whether it has a fault based on the diagnostic results of the fault self-detection, and can send the corresponding fault information to the main ECU node if it is determined that it has a fault, and the main ECU node will store it. This method allows the owner to send a diagnostic request directly from the car to repair the fault when a fault occurs, without having to send the vehicle back to the vehicle sales point for after-sales diagnosis.

[0352] However, the predefined diagnostic services in the vehicle cannot completely cover all fault scenarios. When the predefined diagnostic services cannot be used to diagnose the fault, the owner needs to send the vehicle back to the vehicle sales point for after-sales diagnosis. In after-sales diagnosis, the diagnostic personnel often need to initiate a diagnostic request from outside the vehicle to inside the vehicle. In this case, the diagnostic personnel must obtain the long-term keys corresponding to each ECU in the vehicle in advance, otherwise the diagnostic request sent by the diagnostic personnel cannot be authenticated by these ECUs, resulting in diagnostic failure. However, the long-term keys in the vehicle should not be leaked outside the vehicle in theory. Because if the diagnostic personnel obtain these long-term keys, then the diagnostic personnel can also obtain the user privacy data protected by these long-term keys based on these long-term keys, and may even use these long-term keys to control the operation of the vehicle, which is not conducive to the user's driving experience. Although it is also possible to replace the long-term key after the diagnosis is completed using the long-term key, this replacement operation is not only complicated in operation process, but also cannot solve the problem of user privacy data leakage.

[0353] In view of this, the present application provides a vehicle diagnostic method for using a temporary key for diagnosis in a scenario where off-vehicle diagnosis is required, while not contacting, modifying, or leaking sensitive data already in the vehicle (such as long-term keys preset in the vehicle and user privacy data protected by these long-term keys). Of course, in another scenario, if there is no long-term key preset in the vehicle, but the ECU in the vehicle also needs to be diagnosed based on the key's security features, the vehicle diagnostic method in the present application can also be used.

[0354] The vehicle diagnostic method in the present application is introduced below with a specific embodiment. It should be noted that the terms "system" and "network" in the embodiments of the present application can 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 three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0355] Furthermore, unless otherwise specified, the ordinal numbers 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 verification information, the second verification information, and the third verification information are only used to distinguish different verification information, and do not indicate the difference in priority or importance of the three verification information.

[0356] [Example 1]

[0357] Figure 3 The flowchart corresponding to the vehicle diagnosis method provided in the first embodiment of the present application is exemplarily shown. The method is applicable to the diagnosis device, the key management system in the vehicle to be diagnosed, and the unit to be diagnosed, for example Figure 1 The diagnostic equipment, key management system and one or more ECUs are shown. Figure 3 As shown, the method includes:

[0358] Step 301: The diagnostic device sends a key authorization request to the key management system.

[0359] In the above step 301, the diagnostic device may refer to a device outside the vehicle to be diagnosed, for example, it may be other equipment independent of the OEM equipment and the supplier equipment, or it may be a part of the OEM equipment or a part of the supplier equipment. In this case, considering the risk of key leakage in off-vehicle diagnosis, the diagnostic device may not use the long-term key in the vehicle to be diagnosed to initiate the diagnosis, but may send a key authorization request to the key management system in the vehicle to be diagnosed before initiating the diagnosis to apply for the temporary key corresponding to this diagnosis. In this way, if the subsequent diagnostic device receives the temporary key, the diagnostic device and the vehicle to be diagnosed can complete the off-vehicle diagnostic operation based on the temporary key to avoid the long-term key in the vehicle to be diagnosed from leaking outside the vehicle.

[0360] Step 302: The key management system generates a temporary key corresponding to the current diagnosis according to the key authorization request, wherein the temporary key is independent of the long-term key in the vehicle to be diagnosed.

[0361] In the above step 302, the temporary key corresponding to the current diagnosis can be a globally unique temporary key, that is, the temporary key is unique among all currently existing diagnoses. In this way, even if the diagnostic device is currently performing different diagnoses on the vehicle to be diagnosed, the unit to be diagnosed in the vehicle to be diagnosed can only parse the information to be diagnosed corresponding to the diagnosis itself, and will not confuse the information to be diagnosed corresponding to the diagnosis of other units to be diagnosed, thereby helping to ensure the accuracy of each diagnosis in the scenario where the temporary key is used to perform the diagnosis.

[0362] Step 303: The key management system sends a key authorization response to the diagnostic device, where the key authorization response includes a temporary key.

[0363] It should be understood that the above steps 301 to 303 are performed by the diagnostic device to apply for a temporary key from the key management system, which is only an optional implementation. In another optional implementation, other devices can also apply for a temporary key from the key management system and send it to the diagnostic device. This method places the operation of applying for a temporary key and the diagnostic operation in different devices for separate execution, which not only helps to reduce the working pressure of the diagnostic device, but also decouples the operation of applying for a temporary key from the diagnostic operation. Even if the diagnostic device is performing another diagnosis, other devices can apply in advance for a temporary key for this diagnosis, so that the diagnostic device can directly use the temporary key of this diagnosis to seamlessly perform this diagnosis after performing another diagnosis, without having to re-acquire the temporary key corresponding to this diagnosis, thereby helping to improve diagnostic efficiency.

[0364] Step 304 : The key management system allocates a temporary key to the unit to be diagnosed in the vehicle to be diagnosed.

[0365] In the above step 304, the unit to be diagnosed may include only one ECU or multiple ECUs at the same time. When the unit to be diagnosed includes multiple ECUs, these multiple ECUs can complete a diagnostic task in combination, and each ECU in the multiple ECUs corresponds to its own diagnostic subtask. Among them, the diagnostic subtask of each ECU can be independent of the diagnostic subtasks of other ECUs. In this case, the multiple ECUs can first execute their respective diagnostic subtasks to obtain multiple diagnostic results, and then combine the multiple diagnostic results to obtain the final diagnostic result. Alternatively, the multiple ECUs can also have priorities, and the diagnostic subtask of the ECU with a high priority depends on the diagnostic result of the ECU with a low priority. In this case, the ECU with a low priority can first execute the corresponding diagnostic subtask to obtain the diagnostic result, and then the ECU with a high priority can call the diagnostic result of the ECU with a low priority to continue to execute the diagnostic subtask corresponding to the ECU with a high priority, until all ECUs are diagnosed, and the final diagnostic result is obtained by combining the diagnostic results of multiple ECUs. There are many possible implementation methods, which are not listed here one by one.

[0366] In an optional implementation, the temporary key may also correspond to an applicable scope and a valid duration. The applicable scope of the temporary key refers to which diagnosis units the temporary key corresponds to, and the valid duration of the temporary key refers to how long the temporary key is valid. In this implementation, the applicable scope and valid duration of the temporary key may have a variety of possible situations, for example:

[0367] In a possible case, each temporary key corresponds to the same scope of application and validity period, which can be written into the key management system of the vehicle to be diagnosed by the R&D personnel through the one-time pad context before the vehicle to be diagnosed leaves the factory. If the scope of application preset in the one-time pad context is all ECUs in the vehicle to be diagnosed, and the validity period preset in the one-time pad context is one day, then the key management system can randomly generate a globally unique temporary key for each key authorization request received, and then configure the temporary key to all ECUs in the vehicle to be diagnosed. When the validity period of the temporary key is maintained by the key management system, the key management system can also start a timer (the timing period is 24 hours) after the configuration is successful, and when the timer ends, it is determined that the validity period of the temporary key has ended, so the key management system can invalidate the temporary key in each ECU. When the validity period of the temporary key is maintained by the diagnostic device, the validity period preset in the one-time pad context can also be pre-synchronized to the diagnostic device, so that the diagnostic device can start the timer to count the same validity period (for example, 24 hours) each time it receives the temporary key sent by the key management system, and when the timer ends, the diagnostic device can instruct the key management system to invalidate the temporary key.

[0368] In another possible case, the key authorization request indicates the applicable scope and valid duration corresponding to the temporary key. The applicable scope and valid duration can be set by the OEM-side R&D personnel or diagnostic personnel according to the diagnostic needs of this time, or can be set according to the configuration information customized by the car owner, without specific limitation. Assuming that the key authorization request indicates that the applicable scope corresponding to this diagnosis is the vehicle-mounted camera and the valid duration is one day, after the key management system receives the key authorization request, it can first randomly generate a globally unique temporary key, and then configure the temporary key to the vehicle-mounted camera in the vehicle to be diagnosed. The key management system can also start the timer after the configuration is successful (the timing duration is 24 hours), and the temporary key in the vehicle-mounted camera will be invalidated after the timer ends.

[0369] In another possible case, the key authorization request only indicates the applicable scope corresponding to the temporary key, but does not indicate the valid duration. In this case, after receiving the key authorization request, the key management system can first randomly generate a globally unique temporary key, and then configure the temporary key to the applicable scope indicated in the key authorization request. After that, the key management system can return the temporary key to the diagnostic device. Correspondingly, after receiving the temporary key for the key authorization request, the diagnostic device can start a timer to count the valid duration corresponding to the temporary key. When the timer expires, the diagnostic device can instruct the key management system to invalidate the temporary key.

[0370] In an example of the above implementation, the applicable scope corresponding to each temporary key can be set to each unit to be diagnosed required for this diagnosis. In this way, the diagnostic device can directly use the same temporary key to interact with each diagnostic unit corresponding to this diagnosis, without switching the temporary key for each diagnostic unit, thereby helping to improve diagnostic efficiency.

[0371] In an embodiment of the present application, there may be multiple ways for the diagnostic device to invalidate a temporary key. For example, in one possible way, after determining that the effective duration of the temporary key has ended, the diagnostic device may directly send an instruction message to the key management system to release the temporary key, so as to instruct the key management system to directly invalidate the temporary key in the ECU. For another example, in another possible way, the diagnostic device may also periodically send a security heartbeat message bound to the temporary key to the key management system within the effective duration of the temporary key, and no longer send the security heartbeat message after the effective duration of the temporary key has ended. In this way, when the key management system has not received the security heartbeat message bound to the temporary key after more than one period, the key management system may determine that the temporary key has expired, and thus the key management system may invalidate the temporary key in the ECU. By setting an effective duration for the temporary key, the present application enables the key management system to manage each temporary key more conveniently and flexibly.

[0372] In an optional implementation, "the key management system configures the temporary key in the ECU", may mean: the key management system sends the temporary key to the ECU, and allows the ECU to store the temporary key in the random access memory (RAM) of the ECU. Correspondingly, "the key management system invalidates the temporary key in the ECU" may mean: the key management system allows the ECU to delete the temporary key stored in the RAM of the ECU. In this implementation, since RAM has the characteristic of losing data after power failure, if a diagnostic fault is found during the diagnosis process, or other reasons lead to the fact that the diagnosis is no longer desired, even if the validity period of the temporary key corresponding to this diagnosis has not expired, the diagnostic personnel can also make the ECU lose the temporary key corresponding to this diagnosis by powering off the vehicle to be diagnosed, thereby achieving the purpose of invalidating the temporary key.

[0373] Step 305: The diagnostic device encrypts the information to be diagnosed using a temporary key to generate a diagnostic request.

[0374] Step 306: The diagnostic device sends a diagnostic request to the unit to be diagnosed.

[0375] In the above step 306, when all ECUs in the vehicle to be diagnosed are connected to the CAN bus, the diagnostic device can directly send a diagnostic request to the CAN bus and carry a message authentication code (also called a message identifier) ​​in the diagnostic request.

[0376] Step 307: the unit to be diagnosed uses the temporary key to decrypt the diagnosis request to obtain the information to be diagnosed, and performs a diagnosis operation according to the information to be diagnosed to obtain a diagnosis result.

[0377] In the above step 307, any ECU in the vehicle to be diagnosed can obtain the diagnostic request from the CAN bus. Then, the ECU can verify the message authentication code in the diagnostic request to determine whether it belongs to the message it wants to obtain. If the temporary key stored in the RAM of the ECU is the same as the temporary key used for the encrypted diagnostic request, the ECU can parse the diagnostic request to obtain the information to be diagnosed, and then diagnose based on the information to be diagnosed to obtain the diagnostic result. If the RAM of the ECU does not store the temporary key, or the stored temporary key is different from the temporary key used for the encrypted diagnostic request, the ECU cannot parse the information to be diagnosed, and thus cannot diagnose to obtain the diagnostic result. This method helps to only allow the unit to be diagnosed that is configured with a temporary key to perform the diagnosis corresponding to the temporary key, thereby effectively controlling the diagnostic operations of each unit to be diagnosed.

[0378] In the field of vehicle networking technology, the sending and receiving operations between two nodes need to rely on various communication protocols. The two nodes can be an off-board diagnostic device and an ECU inside the vehicle, or any two ECUs inside the vehicle. The following takes the SecOC protocol as an example to introduce the specific implementation process of interactive diagnostic requests between the diagnostic device and the unit to be diagnosed. Among them, the SecOC protocol is an optional software module in the basic software layer (basic software of AUTOSAR, BSW) layer in the framework of AUTOSAR software. The SecOC protocol can provide a message integrity authentication mechanism for ECU messages at the protocol data unit (PDU) level, and can ensure the freshness of ECU messages, preventing illegal personnel from replaying historical messages and causing problems in ECU control. Figure 4 The following is a flow chart showing a diagnostic method based on the SecOC protocol provided in the present application. Figure 4 As shown, the method includes:

[0379] Step 401: The diagnostic device generates a first message authentication code according to the information to be diagnosed, a fresh value (FV) and a temporary key.

[0380] In the above step 401, the diagnostic device can use a counter to determine the freshness value of the sent message and the received message. Each time the diagnostic device sends a message, it can add 1 to the internally stored freshness value. In this way, since the message authentication code sent by the diagnostic device is generated based on the current freshness value, even if an illegal person sends a historical message (carrying a historical freshness value) previously generated by the diagnostic device to the unit to be diagnosed, the unit to be diagnosed can determine whether the received message is a fresh message based on the freshness value carried in the first message authentication code. When it is not a fresh message but a historical message, the unit to be diagnosed may not execute the corresponding control command. This method can better prevent illegal persons from using historical messages to control the vehicle to be diagnosed, thereby helping to improve the anti-attack capability of the vehicle to be diagnosed.

[0381] In an optional implementation, a message authentication code generator may also be provided in the diagnostic device, and the message authentication code generator is used to process the input information according to a preset generation algorithm to obtain a message authentication code and output it. When the preset generation algorithm is CMAC-AES128 (complying with RFC 4493), if the diagnostic device inputs the information to be diagnosed I, the fresh value FV and the temporary key {M} into the message authentication code generator together, the message authentication code generator can calculate and output the first message authentication code L1 according to the following formula (1.1):

[0382] L1=CMAC-AES128(I||FV,{M})……(1.1)

[0383] According to the above formula (1.1), when the temporary key {M} is a symmetric key of AES128 bits in length, the length of the first message authentication code L1 can also be 128 bits.

[0384] Step 402: The diagnostic device generates a diagnostic request according to the information to be diagnosed, the fresh value and the first message authentication code, and sends the request to the unit to be diagnosed.

[0385] In the above step 402, considering that the data field of the CAN message frame is only 8 bytes, if the total length of the information to be diagnosed, the fresh value and the first message authentication code is not greater than 8 bytes, the diagnostic device can directly splice the information to be diagnosed, the fresh value and the first message authentication code to generate a diagnostic request. If the total length of the information to be diagnosed, the fresh value and the first message authentication code is greater than 8 bytes, these three information cannot actually be directly assembled in the CAN message frame. In this case, in order to smoothly transmit the information to be diagnosed, the diagnostic device can also truncate the fresh value and the first message authentication code before splicing, and then assemble the truncated fresh value, the truncated first message authentication code and the information to be diagnosed to obtain a diagnostic request. Considering that the security of the transmission of the information to be diagnosed will decrease linearly as the length of the first message authentication code becomes smaller, and the message authentication code of 64 bits or more in length generally has sufficient anti-attack capabilities, therefore, when the diagnostic device truncates the message authentication code, it can also set the length of the first message authentication code to be not less than 64 bits.

[0386] Figure 5 An exemplary method of assembling a diagnostic request provided by an embodiment of the present application is shown as follows: Figure 5 As shown, this method first divides the fresh value into the low bit of the fresh value and the high bit of the fresh value, divides the first message authentication code into the low bit of the first message authentication code and the high bit of the first message authentication code, and then takes the low bit of the fresh value and the high bit of the first message authentication code, and sequentially concatenates the diagnosis information, the low bit of the fresh value and the high bit of the message authentication code to obtain a diagnosis request.

[0387] Step 403: the unit to be diagnosed parses the diagnosis request to obtain the information to be diagnosed, the fresh value and the message authentication code.

[0388] For example, if the diagnostic device is as described above Figure 5The diagnostic request is spliced ​​in the manner shown, and the unit to be diagnosed will obtain the low bit of the fresh value and the high bit of the first message authentication code. In this case, the unit to be diagnosed also needs to restore the complete fresh value based on the low bit of the fresh value carried in the diagnostic request and the fresh value stored locally in the unit to be diagnosed, wherein the locally stored fresh value is determined based on the low bit of the fresh value carried in the historical message most recently received by the unit to be diagnosed. In an optional recovery method, if the low bit of the fresh value carried in the diagnostic request is less than the low bit of the locally stored fresh value, it means that the low bit of the fresh value has a value range overflow during the increment process (for example, the low bit of the binary fresh value will become 0 when it increases by 1 from 1 to 0, and the high bit of the fresh value will increase by 1 accordingly), so the unit to be diagnosed can first add 1 to the high bit of the locally stored fresh value, and then splice the high bit of the locally stored fresh value and the low bit of the fresh value carried in the diagnostic request together to obtain a complete fresh value. If the low bit of the fresh value carried in the diagnostic request is not less than the low bit of the locally stored fresh value, it means that the low bit of the fresh value gradually increases without overflowing. Therefore, the unit to be diagnosed can directly concatenate the high bit of the locally stored fresh value and the low bit of the fresh value carried in the diagnostic request to obtain a complete fresh value.

[0389] Step 404: the unit to be diagnosed generates a second message authentication code according to the information to be diagnosed, the fresh value and the temporary key.

[0390] In an optional implementation, before generating the second message authentication code, the unit to be diagnosed may also compare the recovered fresh value with the stored fresh value. If the recovered fresh value is equal to the locally stored fresh value, or the recovered fresh value is less than the locally stored fresh value, it means that the diagnostic request may be an offensive message resent by an illegal person using a historical diagnostic request. Therefore, the unit to be diagnosed may not execute the corresponding control command, or may also return a warning message to the diagnostic device, so that the diagnostic personnel can check the illegal intrusion in time and maintain vehicle safety. If the recovered fresh value is greater than the locally stored fresh value, it means that the diagnostic request is not a resent message. Therefore, the unit to be diagnosed can obtain the temporary key pre-configured by the key management system from the local RAM and perform subsequent authentication operations based on the temporary key.

[0391] In the embodiment of the present application, a message authentication code parser may also be provided in the unit to be diagnosed, and the message authentication code parser is used to process the input information according to the same preset generation algorithm as the message authentication code generator in the diagnostic device to obtain and output the message authentication code. When the preset generation algorithm is CMAC-AES128 (in compliance with RFC 4493), if the unit to be diagnosed inputs the information to be diagnosed I, the recovered fresh value FV and the temporary key {M} stored in the local RAM into the message authentication code parser, the message authentication code parser can calculate and output the second message authentication code L2 according to the above formula (1.1).

[0392] Step 405, the unit to be diagnosed determines whether the second message authentication code generated by itself is the same as the first message authentication code carried in the diagnosis request. If they are the same, it means that the temporary key stored in the local RAM of the unit to be diagnosed is the same as the temporary key corresponding to the information to be diagnosed, and the unit to be diagnosed belongs to the unit to be diagnosed, so the unit to be diagnosed can perform diagnosis based on the information to be diagnosed to obtain a diagnosis result. If they are different, it means that the temporary key stored in the local RAM of the unit to be diagnosed is different from the temporary key corresponding to the information to be diagnosed, and the unit to be diagnosed does not belong to the unit to be diagnosed, so the unit to be diagnosed may not perform the diagnostic operation.

[0393] The above-mentioned implementation method authenticates the diagnostic request by using a message authentication code generated by a fresh value and a temporary key. It can not only prevent the information to be diagnosed from being tampered with during transmission outside the vehicle, but also accurately detect the behavior of illegal persons using historical messages to attack the vehicle, and can also perform diagnostic operations when the authentication information is accurately transmitted, thereby helping to accurately ensure the safety of the vehicle during the off-vehicle diagnosis stage.

[0394] In the embodiment of the present application, although the fresh value increases monotonically according to the number of times the message is sent during the life cycle of the whole vehicle, the diagnostic device and the unit to be diagnosed each maintain their own fresh value, which may cause the fresh value between the diagnostic device and the unit to be diagnosed to be out of sync due to some unpredictable anomalies. For example, in one case, although the diagnostic device sends a diagnostic request to the CAN bus, the CAN bus loses the diagnostic request due to some fault. In this case, the unit to be diagnosed cannot obtain the diagnostic request, so the fresh value in the unit to be diagnosed will be smaller than the fresh value in the diagnostic device. In order to avoid this phenomenon, the present application can also set a certain fault-tolerant mechanism between the diagnostic device and the unit to be diagnosed to maintain accurate fresh value data. For example, under an optional fault-tolerant mechanism, the diagnostic device and the unit to be diagnosed can be synchronized with their respective fresh values ​​regularly. Once it is found that the fresh value of a certain device is less than the fresh value of another device, the device with a smaller fresh value can be allowed to correct its own fresh value. In this way, the diagnostic device and the unit to be diagnosed can always maintain the same fresh value.

[0395] It should be noted that the above content is only an exemplary introduction to a method of authenticating a diagnostic request between a diagnostic device and a unit to be diagnosed, and this application is not limited to authenticating a diagnostic request in this way. At present, all solutions that can be used for diagnostic requests in vehicles are included in the protection scope of this application, and this application will not go into details.

[0396] Step 308: the unit to be diagnosed sends the diagnosis result to the diagnostic device.

[0397] In the embodiment of the present application, the validity period of the temporary key can be a fixed period or the duration of the current diagnosis. When the validity period of the temporary key corresponds to the duration of the current diagnosis:

[0398] If the validity period of the temporary key is maintained by the unit to be diagnosed, the unit to be diagnosed can determine that the diagnosis is over after sending the diagnosis result to the diagnostic device, so the unit to be diagnosed can directly delete the temporary key stored in its RAM;

[0399] If the validity period of the temporary key is maintained by the diagnostic device, the diagnostic device can determine that the current diagnosis is over after receiving the diagnostic result sent by the unit to be diagnosed, so the diagnostic device may no longer send a security heartbeat message to the key management system, or the diagnostic device may send an instruction message to release the temporary key to the key management system;

[0400] If the validity period of the temporary key is maintained by the key management system, the diagnostic device can also send an indication message of obtaining the diagnostic result to the key management system after receiving the diagnostic result sent by the unit to be diagnosed, so that the key management system can determine the end of this diagnosis based on the indication message, thereby invalidating the temporary key in the unit to be diagnosed.

[0401] The above-mentioned embodiment 1 can configure a temporary key for the diagnostic operation outside the vehicle. By using the temporary key, the diagnosis unit can be diagnosed directly from outside the vehicle in a safe, compliant and clean manner, and the sensitive data inside the vehicle (such as the long-term key set in the vehicle or other protected data) can be avoided as much as possible. This not only helps to protect the privacy data of the car owner, but also reduces the possibility of illegal persons using long-term keys to control the operation of the vehicle, thereby improving the driving safety of the car owner.

[0402] It should be noted that the present application does not limit the order of implementing steps 301 to 304 in the first embodiment. For example:

[0403] Fig. 6A A schematic diagram of a method for configuring a temporary key is shown as an example. Fig. 6AAs shown, in this example, after the key management system generates a temporary key according to the key authorization request sent by the diagnostic device, it can first configure the temporary key to each ECU to be diagnosed. When the configuration is successful, the key management system can then send a key authorization response to the diagnostic device. Of course, if the configuration is unsuccessful, the key management system may not return the temporary key to the diagnostic device, but may reconfigure it. If the configuration has not been successful within a preset number of times or a preset period of time, the key management system may also return a configuration error response message to the diagnostic device. This method will only return the temporary key to the diagnostic device if the configuration is successful, which helps the diagnostic device to initiate a diagnostic request only when the temporary key is stored in each ECU to be diagnosed. Therefore, this method can effectively save the internal resources of the diagnostic device.

[0404] Figure 6B Another schematic diagram of a method for configuring a temporary key is shown as an example. Figure 6B As shown, in this example, after the key management system generates a temporary key according to the key authorization request sent by the diagnostic device, it can first send a key authorization response to the diagnostic device, and then configure the temporary key to each ECU to be diagnosed. In this case, the operation of the diagnostic device generating a diagnostic request and the operation of the key management system configuring a temporary key can be performed in parallel. In this way, compared with the solution in which the diagnostic device waits for the temporary key to be successfully configured before receiving the key authorization response, the diagnostic efficiency in this way is higher.

[0405] Figure 6C A schematic diagram of another method for configuring a temporary key is shown as an example. Figure 6C As shown, in this example, after the key management system generates a temporary key according to the key authorization request sent by the diagnostic device, it can first send a key authorization response to the diagnostic device, and then wait for the response of the diagnostic device. If the diagnostic device sends a response and indicates in the response that the diagnostic device has received the correct temporary key, the key management system can then configure the temporary key to each ECU to be diagnosed. In this case, the key management system will only configure the temporary key after determining that the diagnostic device has received the correct temporary key. In the case where the diagnostic device does not receive the temporary key (that is, the key management system does not receive a response) or the diagnostic device receives an incorrect temporary key, the key management system may not configure the temporary key, because even if the temporary key is configured, the diagnosis cannot continue due to the difference between the configured temporary key and the temporary key used by the diagnostic device to encrypt the information to be diagnosed. Therefore, this method can effectively save the internal resources of the key management system.

[0406] In the embodiment of the present application, if the temporary key is sent directly in plain text, the temporary key is likely to be hijacked during the transmission process, thereby causing an unsafe impact on vehicle diagnosis. In order to solve this problem, the present application also proposes a method of completing vehicle diagnosis by secretly transmitting the temporary key. Figure 6C The configuration shown is used to further introduce the vehicle diagnosis method in this application through Example 2.

[0407] [Example 2]

[0408] Figure 7 The flowchart corresponding to the vehicle diagnostic method provided in the second embodiment of the present application is exemplarily shown. The method is applicable to the diagnostic device, the key management system in the vehicle to be diagnosed, and the unit to be diagnosed, for example Figure 1 The diagnostic equipment, key management system and one or more ECUs are shown. Figure 7 As shown, the method includes:

[0409] Step 701: The diagnostic device sends a key authorization request to a key management system, where the key authorization request includes at least one feature information.

[0410] In the above step 701, at least one feature information may refer to feature information related to this diagnosis that is transparent to the diagnostic device but opaque to the key management system, for example, information that the diagnostic device knows but the key management system does not know in all the information that may be used in the process of authenticating the temporary key between the diagnostic device and the key management system. In this way, the diagnostic device and the key management system can store complete information, so that the diagnostic device and the key management system can use the same algorithm to authenticate the temporary key based on the complete information. For example, at least one feature information may include diagnostic object information and diagnostic device information. Among them, the diagnostic object information is used to indicate the unit to be diagnosed, for example, it may include the characteristic identification (identity document, ID) of the diagnostic service required for this diagnosis, and may also include the vehicle identification number (vehicle identification number, VIN) of the vehicle to be diagnosed or the identification of the unit to be diagnosed. When the diagnostic object information includes the characteristic ID of a service, this diagnosis is applicable to all ECUs with the service. For example, if the diagnostic object information is SecOC, it means that this diagnosis is applicable to each ECU using the SecOC message authentication mechanism, and the temporary key corresponding to this key authorization request needs to be configured to each ECU using the SecOC message authentication mechanism. The diagnostic device information is used to indicate the diagnostic device, and may include, for example, a message authentication code (MAC) (also called an authorization code) corresponding to the diagnostic device, and may also include a device number of the diagnostic device, etc.

[0411] In an optional implementation, at least one of the characteristic information may also include a first random value Nonce1 generated by the diagnostic device. The first random value Nonce1 may be a random value of any length, which is subsequently used only once. Preferably, in order to ensure the security of temporary key transmission without excessively increasing the burden of blind transmission, the first random value Nonce1 may be selected as a random value of 6 bits in length.

[0412] For ease of understanding, the following exemplifies the example in which the key authorization request includes the first random value Nonce1, the characteristic ID, and the authorization code MAC.

[0413] In step 702, the key management system first generates a temporary key corresponding to this diagnosis, then generates a transmission security key based on at least one feature information, uses the transmission security key to encrypt the temporary key corresponding to this diagnosis to generate a ciphertext, and then uses the transmission security key and the ciphertext to generate verification information MAC11 (i.e., the third verification information).

[0414] In an optional implementation, after the key management system receives the key authorization request, the key management system may also generate a second random value Nonce2, and then use some existing symmetric keys, the second random value Nonce2, and the first random value Nonce1, the characteristic ID and the authorization code MAC in the key authorization request to generate a transmission security key and ciphertext. The second random value Nonce2 may also be a random value of any length that is subsequently used only once, such as a random value of 6 bits. The existing symmetric key is pre-synchronized to the key management system and the diagnostic device, for example, it may refer to at least one long-term key maintained in the key management system (for example, refer to Figure 2 As shown, when the diagnostic device belongs to the OEM R&D line, the existing symmetric key may refer to the root key and working key preset by the OEM R&D line), or may refer to the initial symmetric key from which these long-term keys are derived, or may refer to the symmetric key preset by a technician in this field specifically for encrypting temporary keys. This implementation method can enhance the security of temporary key transmission by using information known to both the diagnostic device and the key management system, and helps reduce the possibility of temporary keys being intercepted when sending them to the diagnostic device.

[0415] In a possible example of the above implementation, in order to save as much as possible the number of symmetric keys synchronized by the key management system and the diagnostic device, the key management system and the diagnostic device can only use an existing symmetric key MK to generate a transmission security key. In this example, the key management system can first use the symmetric key MK to encrypt the feature ID and the authorization code MAC according to the following formula (2.1) to derive the first symmetric key AK:

[0416] AK=HKDF(MK, ID||string "MAC")......(2.1)

[0417] Among them, HKDF refers to a key derivation function (HMAC-based key derivation function, HKDF) based on a hash-based message authentication code (HMAC).

[0418] Then, the key management system can use the first symmetric key AK to encrypt the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the string "TransportKey" according to the following formula (2.2) to derive the transport security key tK:

[0419] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey")......(2.2)

[0420] Afterwards, the key management system can use the transmission security key tK to encrypt the temporary key {M} corresponding to this diagnosis according to the following formula (2.3) to generate the ciphertext C:

[0421] C=AES-GCM(tK,{M})……(2.3)

[0422] AES-GCM refers to an AES symmetric encryption algorithm that uses a counting mode and carries a Galois message authentication code (GMAC).

[0423] In an optional implementation, if the ciphertext is only transmitted to the diagnostic device without other verification, even if the diagnostic device can parse the ciphertext to obtain a temporary key, the temporary key may be a tampered temporary key. Therefore, in order to ensure that the diagnostic device only obtains a temporary key that has not been tampered with, the key management system can also generate a verification information MAC11 using the ciphertext and various feature information used to generate the ciphertext before transmitting the ciphertext, and send the verification information MAC11 together with the ciphertext to the diagnostic device. In this way, as long as the verification information MAC11 is successfully verified, it means that the ciphertext and the various feature information used to generate the ciphertext have not been tampered with during the transmission process. Therefore, the temporary key obtained by the diagnostic device by parsing the ciphertext based on the various feature information used to generate the ciphertext has not been tampered with. Among them, the various characteristic information for generating the ciphertext may include the transmission security key tK, and may also include the first symmetric key AK, characteristic ID, first random value Nonce1 and second random value Nonce2 used to generate the transmission security key tK, or may only include the second random value Nonce2, because only the second random value Nonce2 is information generated by the key management system itself and needs to be sent to the diagnostic device (otherwise the diagnostic device cannot perform the parsing), and the first symmetric key AK, characteristic ID and first random value Nonce1 are all information preset in the diagnostic device or information that the diagnostic device can calculate by itself, and this information will not change due to transmission tampering.

[0424] In a possible example of the above implementation, the key management system may first use the first symmetric key AK to encrypt the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the authorization code MAC according to the following formula (2.4) to derive the second symmetric key macKey:

[0425] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC")......(2.4)

[0426] Then, the key management system can use the second symmetric key macKey to encrypt the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the ciphertext C according to the following formula (2.5) to generate the verification information MAC11:

[0427] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C))……(2.5)

[0428] Step 703: The key management system sends a key authorization response to the diagnostic device, and the key authorization response carries the ciphertext and verification information MAC11.

[0429] In the above step 703, if the key management system also uses some information unknown to the diagnostic device to generate the ciphertext or verification information MAC11, the key authorization response also needs to include the information unknown to the diagnostic device. In this way, the diagnostic device side can obtain complete information to smoothly parse the ciphertext to obtain the temporary key, or smoothly verify the verification information MAC11. Since the key management system in the above step 702 also uses the second random value Nonce2 unknown to the diagnostic device in the process of generating the ciphertext C or the verification information MAC11, the key authorization response can also include the second random value Nonce2.

[0430] According to the above steps 702 and 703, when the key management system sends the temporary key to the diagnostic device, it does not send it directly in plain text form, but sends it in encrypted ciphertext form. This method can better prevent the temporary key from being stolen during the transmission process, thereby helping to ensure the security of the diagnostic process of the vehicle to be diagnosed.

[0431] Step 704, the diagnostic device verifies the verification information MAC11:

[0432] If the verification fails, execute step 705;

[0433] If the verification is successful, execute step 706.

[0434] In the above step 704, the diagnostic device can first use some unknown information carried in the key authorization response, the ciphertext, and some information preset or calculated locally by itself to generate the verification information MAC12 (i.e., the sixth verification information) in the same way as the key management system generates the verification information MAC11. For example, according to the generation method in the above step 702, the diagnostic device can obtain the second random value Nonce2 and the ciphertext C from the key authorization response, and obtain the symmetric key MK, the characteristic ID, the authorization code MAC and the first random value Nonce1 locally, first use the symmetric key MK, the characteristic ID and the authorization code MAC to generate the first symmetric key AK according to the above formula (2.1), then use the first symmetric key AK, the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the authorization code MAC to generate the second symmetric key macKey according to the above formula (2.1), and then use the second symmetric key macKey, the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the ciphertext C to generate the verification information MAC12 according to the above formula (2.5).

[0435] Afterwards, the diagnostic device can determine whether the verification information MAC12 generated by itself is the same as the verification information MAC11 carried in the key authorization response. In theory, if the key authorization response has not been tampered with, the verification information MAC12 generated by the diagnostic device itself and the verification information MAC11 carried in the key authorization response should be the same. If the key authorization response has been tampered with, the verification information MAC12 generated by the diagnostic device itself and the verification information MAC11 carried in the key authorization response are likely to be different.

[0436] Step 705: The diagnostic device ends the current diagnosis.

[0437] In the above steps 704 and 705, if the verification information MAC12 generated by the diagnostic device itself is different from the verification information MAC11 carried in the key authorization response, it means that the key authorization response has been tampered with during the transmission process. In this case, even if the diagnostic device parses the ciphertext to obtain a temporary key, this temporary key is not the temporary key actually generated by the key management system, and the diagnostic device cannot continue to perform diagnostic operations based on the temporary key. Therefore, the diagnostic device can directly end the diagnosis. Of course, in other examples, the diagnostic device can also prompt the diagnostic personnel with a response message of a key authorization error so that the diagnostic personnel can repair the fault in time.

[0438] Step 706: The diagnostic device generates a transmission security key based on at least one feature information, and uses the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0439] In the above steps 704 and 706, if the verification information MAC12 generated by the diagnostic device itself is the same as the verification information MAC11 carried in the key authorization response, it means that the key authorization response is most likely not tampered with during the transmission process, and the temporary key carried in the key authorization response is theoretically the temporary key sent to the diagnostic device by the key management system. In this case, the diagnostic device can parse the ciphertext to obtain the temporary key. In a specific implementation, the diagnostic device can first use some information carried in the key authorization response that it does not know and some information preset or calculated locally to generate a transmission security key in the same way as the key management system generates a transmission security key, and then use the transmission security key to decrypt the ciphertext to obtain a temporary key. For example, according to the generation method in step 702 above, since the first symmetric key AK has been generated when verifying the verification information MAC11 in step 704, the diagnostic device can directly use the first symmetric key AK, the characteristic ID, the first random value Nonce1, the second random value Nonce2 and the string "TransportKey" to generate the transport security key tK according to the above formula (2.2), and then the diagnostic device can use the transport security key tK to decrypt the ciphertext C according to the following formula (2.6) to obtain the temporary key {M}:

[0440] {M}=AES-GCM(tK,C)……(2.6)

[0441] In the embodiment of the present application, the two-step operation of encrypting the temporary key and verifying the verification information M11 is actually equivalent to setting up a double verification mechanism before allowing the diagnostic device to obtain the temporary key. This method can not only prevent the temporary key from being tampered with during transmission, but also prevent the diagnostic device from obtaining the tampered temporary key as much as possible when the temporary key is tampered with, thereby helping to maximize the security of the temporary key during transmission.

[0442] Step 707: The diagnostic device generates verification information MAC21 (ie, fourth verification information) using at least one feature information used when generating the temporary key, and sends the verification information MAC21 to the key management system.

[0443] In the above step 707, after the key management system sends the temporary key to the diagnostic device in ciphertext form, if the diagnostic device does not return a response to the key management system, the key management system does not actually know whether the diagnostic device has parsed the correct temporary key. In this case, if the diagnostic device does not parse the temporary key or parses the wrong temporary key, even if the key management system configures the temporary key to the unit to be diagnosed, the diagnosis cannot be completed between the diagnostic device and the unit to be diagnosed (if the diagnostic device does not parse the temporary key, the diagnostic device will not initiate a diagnostic request; or, if the diagnostic device parses the wrong temporary key, the unit to be diagnosed cannot use the correct temporary key to parse the diagnostic request sent by the diagnostic device). In order to solve this problem, the diagnostic device can also generate verification information MAC21 using at least one feature information used when generating the temporary key after parsing the temporary key and send it to the key management system, so that the key management system verifies whether the diagnostic device has parsed the correct temporary key based on the verification information MAC21. When it is determined that the diagnostic device has parsed the correct temporary key, the key management system will configure the temporary key to the unit to be diagnosed. This method can effectively avoid the key management system from performing useless temporary key configuration operations and save resources in the key management system.

[0444] In the embodiment of the present application, at least one feature information used when generating a temporary key may include one or more of the following: symmetric key MK, feature ID, authorization code MAC, first symmetric key AK, transmission security key tK, second symmetric key macKey, ciphertext C, verification information MAC11. Exemplarily, in an optional implementation, the diagnostic device may use the second symmetric key macKey to encrypt the feature ID, the first random value Nonce1, the second random value Nonce2, the ciphertext C and the verification information MAC11 according to the following formula (2.7) to generate the verification information MAC21:

[0445] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11))……(2.7)

[0446] Step 708, the key management system verifies the verification information MAC21:

[0447] If the verification fails, execute step 705;

[0448] If the verification is successful, execute step 709.

[0449] In the above step 708, the key management system can use at least one feature information used when generating the temporary key to generate the verification information MAC22 (i.e., the fifth verification information) in the same way as the diagnostic device generates the verification information MAC21. For example, according to the generation method in the above step 707, the key management system can use the second symmetric key macKey, the encryption feature ID, the first random value Nonce1, the second random value Nonce2, the ciphertext C and the verification information MAC11 to generate the verification information MAC22 according to the above formula (2.7). Afterwards, the key management system can determine whether the verification information MAC22 generated by itself is the same as the verification information MAC21 generated by the diagnostic device. In theory, if the diagnostic device parses the correct temporary key, the verification information MAC21 generated by the diagnostic device and the verification information MAC22 generated by the key management system should be the same. If the diagnostic device parses the wrong temporary key, the verification information MAC21 generated by the diagnostic device and the verification information MAC22 generated by the key management system are likely to be different. If the diagnostic device does not parse the temporary key, the diagnostic device will not send the verification information MAC21.

[0450] In the embodiment of the present application, after the key management system sends the key authorization response to the diagnostic device, it can immediately switch to the waiting state. As long as the verification information MAC21 sent by the diagnostic device is not received, the key management system can not configure the temporary key to the unit to be diagnosed. When the verification information MAC21 sent by the diagnostic device is received, the key management system can first generate the corresponding verification information MAC22 in the above manner. If the verification information MAC21 and the verification information MAC22 are different, it means that the temporary key received by the diagnostic device is not the temporary key issued by the key management system. In this case, the key management system determines that the temporary key is issued incorrectly (for example, the temporary key is tampered with when it is transmitted outside or inside the vehicle), so the key management system can not configure the temporary key to the unit to be diagnosed. For example, when the verification information MAC21 is not received for more than a preset time, or the key management system determines that the temporary key received by the diagnostic device is not the temporary key issued by the key management system, the key management system can also prompt (or through the diagnostic device) the diagnostic personnel that the key authorization is wrong to end this diagnosis.

[0451] Step 709: The key management system configures a temporary key to the unit to be diagnosed corresponding to this diagnosis.

[0452] In the above step 709, when the verification information MAC22 generated by the key management system is the same as the verification information MAC21 generated by the diagnostic device, it means that the temporary key received by the diagnostic device is the temporary key issued by the key management system. In this case, the key management system can configure the temporary key to the unit to be diagnosed, so that the diagnostic device and the unit to be diagnosed can complete the current diagnostic operation based on the temporary key.

[0453] Step 710: The diagnostic device encrypts the information to be diagnosed using a temporary key, generates a diagnostic request, and sends it to the unit to be diagnosed.

[0454] Step 711, the diagnostic device sends a security heartbeat message to the key management system in a periodic manner within the validity period of the temporary key. The security heartbeat message includes verification information MAC31 (i.e., first verification information). The verification information MAC31 is generated based on at least one feature information used when generating the temporary key.

[0455] In an optional implementation, the diagnostic device may use the second symmetric key macKey to encrypt the characteristic ID, the first random value Nonce1 and the second random value Nonce2 according to the following formula (2.8) to generate the verification information MAC31:

[0456] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2))......(2.8)

[0457] Exemplarily, the temporary key in the embodiment of the present application can be configured as a one-time one-password, that is, each temporary key is valid within a diagnostic period corresponding to the temporary key. In this case, since at least one feature information used to generate the temporary key will not change, the verification information MAC31 generated based on the at least one feature information will not change. In this way, after the diagnostic device sends a diagnostic request, the diagnostic device can only calculate the verification information MAC31 when sending a security heartbeat message for the first time, and when sending a security heartbeat message again subsequently, the verification information MAC31 obtained by the first calculation can be directly obtained and encapsulated in the security heartbeat message, without the need to recalculate the verification information MAC31.

[0458] In the embodiment of the present application, for each temporary key managed by the key management system, the key management system can generate the verification information MAC32 (i.e., the second verification information) corresponding to the temporary key in advance according to at least one feature information used when generating the temporary key in the same way as the verification information MAC31. In this way, after the key management system receives a security heartbeat message sent by the diagnostic device, it can match the verification information MAC31 carried in the security heartbeat message with the verification information MAC32 corresponding to each temporary key managed by the key management system. If there is a verification information MAC32 corresponding to a temporary key that is the same as the verification information MAC31, it means that the temporary key is within the valid duration, so the key management system can continue to validate the temporary key. This method uses at least one feature information used to generate the temporary key to generate the verification information MAC31 carried in the security heartbeat message, which can bind the security heartbeat message to the temporary key (or the diagnostic session corresponding to the temporary key). In this way, as long as the key management system can still receive the security heartbeat message bound to the temporary key, it can be determined that the temporary key is still within the valid duration, so that the key management system can continue to validate the temporary key. This approach uses a secure heartbeat message bound to a temporary key to maintain the diagnostic session corresponding to the temporary key, which makes it easier for the key management system to accurately manage each temporary key.

[0459] Step 712: the unit to be diagnosed uses the temporary key to decrypt the diagnosis request to obtain the information to be diagnosed, and uses the information to be diagnosed to perform diagnosis to obtain the diagnosis result.

[0460] Step 713: the unit to be diagnosed sends the diagnosis result to the diagnostic device.

[0461] Step 714: If the key management system does not receive a security heartbeat message within a period, the temporary key in the unit to be diagnosed is invalidated.

[0462] In the above step 714, when it is determined that the validity period of a temporary key has ended, the diagnostic device may no longer send a security heartbeat message bound to the temporary key. Correspondingly, if the key management system does not receive a security heartbeat message that matches the verification information MAC32 corresponding to the temporary key within a cycle, it can be determined that the validity period of the temporary key has ended. In this case, the key management system can send an invalidation indication message to the unit to be diagnosed so that the unit to be diagnosed deletes the temporary key stored in its RAM.

[0463] The above-mentioned second embodiment uses encrypted ciphertext to send a temporary key to the diagnostic device. In this way, whether the diagnostic device is outside the vehicle or directly encapsulated in the vehicle, this method can prevent the temporary key from being tampered with during the transmission process to the greatest extent, which helps the diagnostic device receive the correct temporary key. Furthermore, the above-mentioned second embodiment also sets verification information M11 to verify the authenticity of the ciphertext transmission. Therefore, even if the temporary key is tampered with during the transmission process, this method can also prevent the diagnostic device from obtaining the tampered temporary key to carry out the diagnosis as much as possible, effectively protecting the security of vehicle diagnosis.

[0464] It should be understood that the various formulas involved in the above-mentioned embodiment 2 can be encapsulated in the underlying communication bearer protocol of the diagnostic equipment and the vehicle to be diagnosed. The underlying communication bearer protocol can refer to the in-vehicle bus communication protocol, such as the CAN protocol or the CANFD protocol, or it can refer to the vehicle Ethernet communication protocol, without specific limitation.

[0465] The above-mentioned embodiments 1 and 2 actually complete the whole process of executing vehicle diagnosis based on temporary keys through three-party interaction among the key management system, the diagnostic device and the unit to be diagnosed. In another optional implementation, the operations of the key management system involved in the above-mentioned embodiments 1 and 2 can also be performed on the unit to be diagnosed side. In this case, the diagnostic device and the unit to be diagnosed can complete the whole process of executing vehicle diagnosis based on temporary keys through two-party interaction. The specific implementation process of this two-party interaction is described in detail below based on embodiment 3.

[0466] [Example 3]

[0467] Figure 8 The flowchart corresponding to the vehicle diagnosis method provided in the third embodiment of the present application is exemplarily shown. The method is applicable to the diagnostic device and the unit to be diagnosed in the vehicle to be diagnosed, for example Figure 1 The diagnostic device shown and one or more ECUs. Figure 8 As shown, the method includes:

[0468] Step 801: The diagnostic device sends a key authorization request to the unit to be diagnosed.

[0469] In the above step 801, the unit to be diagnosed may have multiple possible situations, for example:

[0470] In one possible case, the unit to be diagnosed may refer to a specific ECU in the vehicle to be diagnosed, and the specific ECU is specifically used to generate temporary keys for each ECU in the vehicle to be diagnosed (including the specific ECU). In this case, before the diagnostic device performs a diagnostic operation each time, it may first send a key authorization request to the specific ECU, and the specific ECU generates corresponding temporary keys for each ECU involved in each diagnosis, and then combines the corresponding temporary keys of each ECU involved in each diagnosis to complete each diagnosis.

[0471] In another possible case, the unit to be diagnosed may refer to one or more ECUs involved in this diagnosis. When this diagnosis involves only one ECU, the diagnostic device can directly send a key authorization request to the ECU, and the ECU will generate its own corresponding temporary key to complete this diagnosis. When this diagnosis involves multiple ECUs, the diagnostic device can send a key authorization request to one or more ECUs in the multiple ECUs: for example, the diagnostic device can send a key authorization request to each ECU in the multiple ECUs respectively, and the multiple ECUs will generate their own corresponding temporary keys to complete this diagnosis; for another example, the diagnostic device can also send a key authorization request to only one of the multiple ECUs, and the one ECU will generate the temporary keys corresponding to the multiple ECUs to complete this diagnosis; for another example, the diagnostic device can also send a key authorization request to some (at least two) of the multiple ECUs, and the at least two ECUs will share the work of generating temporary keys for the multiple ECUs, thereby reducing the working pressure of the ECUs.

[0472] In another possible case, the unit to be diagnosed may refer to one or more management ECUs in the vehicle to be diagnosed. There may be multiple management ECUs in the vehicle to be diagnosed, each of which is used to manage one or more ECUs in the vehicle to be diagnosed, and the ECUs managed by any two management ECUs are different. In this case, before the diagnostic device performs a diagnostic operation each time, it can first determine which management ECUs manage each ECU involved in this operation, and then send a key authorization request to these management ECUs. These management ECUs first generate corresponding temporary keys for those ECUs involved in this diagnosis among the ECUs they manage, and then the diagnostic device combines the temporary keys corresponding to each ECU involved in this diagnosis to complete this diagnosis.

[0473] Step 802: the unit to be diagnosed generates a temporary key according to the key authorization request, wherein the temporary key is independent of the long-term key in the vehicle to be diagnosed.

[0474] In the above step 802, when multiple ECUs are involved in this diagnosis, the temporary keys corresponding to the multiple ECUs may be the same or different. Exemplarily, in order to simplify the diagnostic process, the same temporary key may be set for the multiple ECUs. In this case, if only one of the ECUs (such as the specific ECU in the above content, one of the ECUs involved in this diagnosis, or the management ECU) generates the temporary keys of each ECU, then the ECU may directly set a temporary key and synchronously configure it to each ECU. If the temporary keys of each ECU are generated by at least two ECUs (such as the at least two ECUs involved in this diagnosis or at least two management ECUs in the above content), then the at least two ECUs may first set the temporary keys of the one or more ECUs corresponding to each other, and then the at least two ECUs may vote to determine the final temporary key, and finally the at least two ECUs may respectively configure the final temporary key to the one or more ECUs corresponding to each other, or the ECU whose turn it is may directly generate the temporary key in a polling manner and synchronize it to the other ECUs in the at least two ECUs, and the other ECUs may configure it to the one or more ECUs corresponding to each other. There are many possible implementation methods, which are not listed here one by one.

[0475] Step 803: the unit to be diagnosed sends a key authorization response to the diagnostic device, where the key authorization response includes a temporary key.

[0476] For example, after determining the corresponding temporary key, any ECU involved in this diagnosis can also store the temporary key locally in the ECU to validate the temporary key. It should be noted that the operation of the ECU validating the temporary key can be performed before the unit to be diagnosed sends the key authorization response, or after the unit to be diagnosed sends the key authorization response, or it can be performed synchronously with the operation of the unit to be diagnosed sending the key authorization response, without specific limitation.

[0477] Step 804: The diagnostic device uses the temporary key carried in the key authorization response to encrypt the diagnostic request.

[0478] Step 805: The diagnostic device sends a diagnostic request to the unit to be diagnosed.

[0479] It should be noted that the unit to be diagnosed in the above step 805 may be the same as or different from the unit to be diagnosed in the above steps 801 to 803. For example, if the diagnostic device combines one of the ECUs involved in this diagnosis to generate temporary keys for each ECU involved in this diagnosis, then the unit to be diagnosed in the above steps 801 to 803 may refer to one of the ECUs involved in this diagnosis, and the unit to be diagnosed in the above step 805 refers to each ECU involved in this diagnosis. If the diagnostic device combines each ECU involved in this diagnosis to generate temporary keys for each ECU involved in this diagnosis, then the unit to be diagnosed in the above steps 801 to 803 and the unit to be diagnosed in the above step 805 both refer to each ECU involved in this diagnosis.

[0480] Step 806: The unit to be diagnosed uses the temporary key to decrypt the diagnosis request to complete the diagnosis.

[0481] It should be noted that the specific implementation process of the above steps 803 to 806, please refer to the relevant technical solutions introduced in the above embodiments 1 to 2. For example, the series of operations such as encrypting temporary keys and verifying ciphertexts involved in embodiments 1 to 2 are also applicable to embodiment 3 of the present application, and will not be repeated here.

[0482] In the above-mentioned third embodiment, the diagnostic operation based on the temporary key is completed by directly combining the diagnostic device with the unit to be diagnosed. This not only enables the unit to be diagnosed to set a more appropriate temporary key according to its own diagnostic needs, but also allows the temporary key to be transferred without going through the key management system, a third-party device. In this way, this method can not only save communication resources while improving the diagnostic efficiency, but also reduce the impact of unsafe factors caused by tampering by third-party devices during the transmission of the temporary key, thereby improving the security of completing the diagnosis based on the temporary key. In addition, since the key management system no longer needs to participate in the diagnostic work based on the temporary key, this method can also save the working pressure of the key management system.

[0483] It should be noted that the names of the above-mentioned information are only examples. With the evolution of communication technology, the names of any of the above-mentioned information may change. However, no matter how the names change, as long as their meanings are the same as those of the above-mentioned information in this application, they fall within the scope of protection of this application.

[0484] The above mainly introduces the solution provided by the present application from the perspective of the interaction between various network elements. It can be understood that in order to realize the above functions, the above-mentioned network elements include hardware structures and / or software modules corresponding to the execution of various functions. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed in this document, the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0485] According to the above method, Fig. 9 A schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the device can be a key management system, a diagnostic device or a unit to be diagnosed, or it can be a chip or circuit, such as a chip or circuit that can be set in a key management system, or a chip or circuit that can be set in a diagnostic device, or a chip or circuit that can be set in a unit to be diagnosed.

[0486] Furthermore, the vehicle diagnostic device 901 may further include a bus system, wherein the processor 902 , the memory 904 , and the transceiver 903 may be connected via the bus system.

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

[0488] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 902 or an instruction in the form of software. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in the processor 902 for execution. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 904, and the processor 902 reads the information in the memory 904 and completes the steps of the above method in conjunction with its hardware.

[0489] It should be noted that the processor 902 in the embodiment of the present application can be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method embodiment can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor can 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 gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor can be combined and performed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

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

[0491] When the vehicle diagnostic device 901 corresponds to the key management system in the above method, the vehicle diagnostic device may include a processor 902, a transceiver 903 and a memory 904. The memory 904 is used to store instructions, and the processor 902 is used to execute the instructions stored in the memory 904 to implement the above Figures 1 to 8 A related scheme of the key management system in any one or more of the corresponding methods shown in .

[0492] When the vehicle diagnostic device 901 is the above-mentioned key management system, the vehicle diagnostic device 901 can be used to execute the method executed by the key management system in any one of the above-mentioned embodiments 1 to 2.

[0493] The vehicle diagnostic device 901 is the key management system described above, and when executing the first embodiment or the second embodiment:

[0494] The transceiver 903 can receive a key authorization request sent by the diagnostic device, the processor 902 can generate a temporary key according to the key authorization request, and configure the temporary key to the unit to be diagnosed in the vehicle, and the transceiver 903 can also send a key authorization response to the diagnostic device, and carry the temporary key in the key authorization response, so that the diagnostic device and the unit to be diagnosed can complete the diagnosis based on the temporary key. The temporary key is independent of the long-term key in the vehicle.

[0495] In an optional implementation, the temporary key may correspond to a valid duration, which may be preconfigured, or may be indicated by a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0496] In an optional implementation, after sending the key authorization response to the diagnostic device, the transceiver 903 can also wait to receive a security heartbeat message sent by the diagnostic device. If the transceiver 903 has not received the security heartbeat message sent by the diagnostic device within the preset cycle duration, the processor 902 can invalidate the temporary key in the unit to be diagnosed. The security heartbeat message is sent to the key management system by the diagnostic device in a periodic manner within the effective duration corresponding to the temporary key.

[0497] In an optional implementation, the security heartbeat message may include first verification information, the first verification information is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value. Among them, the feature identifier can be used to indicate the unit to be diagnosed, the first random value can be generated by the diagnostic device and sent to the key management system, and the second random value can be generated by the key management system and sent to the diagnostic device. In this case, if the transceiver 903 receives a security heartbeat message sent by the diagnostic device within a preset period, the processor 902 can also generate second verification information based on at least one feature information used when generating the temporary key, and when it is determined that the second verification information matches the first verification information, the temporary key continues to take effect.

[0498] In an optional implementation manner, the second verification information may satisfy the following formula:

[0499] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0500] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0501] In an optional implementation, after configuring the temporary key to the unit to be diagnosed in the vehicle, the processor 902 may also invalidate the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has expired.

[0502] In an optional implementation, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed applicable to this diagnosis. The applicable scope corresponding to the temporary key may be preconfigured or may be indicated by a key authorization request.

[0503] In an optional implementation manner, the processor 902 is specifically configured to: configure a temporary key to each unit to be diagnosed required for this diagnosis.

[0504] In an optional implementation, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code. The first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the transceiver 903 sends a key authorization response to the diagnostic device, the processor 902 may also first use a first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain a temporary key.

[0505] In an optional implementation, the processor 902 is specifically configured to: first encrypt the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generate a key authorization response based on the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used by the diagnostic device to perform verification before decrypting the ciphertext.

[0506] In an optional implementation, after the transceiver 903 sends the key authorization response to the diagnostic device, the transceiver 903 may also receive the fourth verification information sent by the diagnostic device, and the processor 902 may also use the ciphertext, the third verification information, and one or more of the at least one feature information to generate the fifth verification information, and if it is determined that the fourth verification information and the fifth verification information match, the processor 902 may configure the temporary key to the unit to be diagnosed in the vehicle. The fourth verification information is generated based on one or more of the ciphertext, the third verification information, and the at least one feature information.

[0507] In an optional implementation, the transmission security key may satisfy the following formula:

[0508] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0509] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0510] Furthermore, the ciphertext can satisfy the following formula:

[0511] C = AES-GCM (tK, {M});

[0512] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0513] In an optional implementation, the second symmetric key may satisfy the following formula:

[0514] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0515] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0516] Furthermore, the third verification information may satisfy the following formula:

[0517] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0518] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0519] In an optional implementation manner, the fifth verification information may satisfy the following formula:

[0520] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0521] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0522] For the concepts, explanations, detailed descriptions and other steps related to the technical solution of the key management system provided in the embodiment of the present application involved in the vehicle diagnostic device 901, please refer to the description of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0523] When the vehicle diagnostic device 901 corresponds to the diagnostic device in the above method, the vehicle diagnostic device may include a processor 902, a transceiver 903 and a memory 904. The memory 904 is used to store instructions, and the processor 902 is used to execute the instructions stored in the memory 904 to implement the above method. Figures 1 to 8 Relevant schemes of the diagnostic device in any one or more of the corresponding methods shown in .

[0524] When the vehicle diagnostic device 901 is the above-mentioned diagnostic equipment, the vehicle diagnostic device 901 can be used to execute the method executed by the diagnostic equipment in any one of the above-mentioned embodiments 1 to 3.

[0525] The vehicle diagnostic device 901 is the above-mentioned diagnostic equipment, and when executing the first embodiment or the second embodiment:

[0526] The transceiver 903 may send a key authorization request to the key management system in the vehicle. After the key management system generates a temporary key based on the key authorization request and configures it to the unit to be diagnosed in the vehicle, the transceiver 903 may receive a key authorization response sent by the key management system, and then the processor 902 uses the temporary key included in the key authorization response to initiate a diagnostic operation on the unit to be diagnosed. The temporary key is independent of the long-term key in the vehicle.

[0527] In an optional implementation, the processor 902 is specifically used to: encrypt the information to be diagnosed using a temporary key to generate a diagnosis request, and the transceiver 903 is also used to: send a diagnosis request to the unit to be diagnosed, and receive a diagnosis result sent by the unit to be diagnosed. The diagnosis request is used for the unit to be diagnosed configured with a temporary key to perform a diagnosis according to the information to be diagnosed carried in the diagnosis request to obtain a diagnosis result.

[0528] In an optional implementation, the temporary key may also correspond to a validity period, which may be preconfigured, or may be indicated by a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0529] In an optional implementation, after the transceiver 903 sends a diagnosis request to the unit to be diagnosed and before receiving the diagnosis result sent by the unit to be diagnosed, the transceiver 903 may also send a security heartbeat message to the key management system according to a preset cycle duration within the validity period corresponding to the temporary key. The security heartbeat message is used for the key management system to continue to validate the temporary key.

[0530] In an optional implementation, before the transceiver 903 sends the security heartbeat message to the key management system, the processor 902 may also generate first verification information using at least one feature information used when generating the temporary key, and generate the security heartbeat message according to the first verification information. The first verification information is used to verify the security heartbeat message.

[0531] In an optional implementation, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value. The feature identifier is used to indicate the unit to be diagnosed, the first random value may be generated by the diagnostic device and sent to the key management system, and the second random value may be generated by the key management system and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0532] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0533] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0534] In an optional implementation, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key may be used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0535] In an optional implementation, the key authorization response may include a ciphertext, and the ciphertext may be obtained by the key management system encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the key management system encrypting at least one feature information based on a first symmetric key. Among them, at least one feature information may be carried in the key authorization request and sent to the key management system, and at least one feature information may include at least one of a first random value, a characteristic identifier, or an authorization code. Among them, the first random value may be generated by a diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after the transceiver 903 receives the key authorization response sent by the key management system, the processor 902 may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0536] In an optional implementation, the key authorization response may also include third verification information, which may be obtained by the key management system based on the second symmetric key to encrypt the ciphertext and at least one feature information, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, before the processor 902 uses the first symmetric key to encrypt at least one feature information to generate a transmission security key, the processor 902 may also first derive the second symmetric key based on the first symmetric key, and then use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information. If it is determined that the sixth verification information matches the third verification information, the processor 902 may use the first symmetric key to encrypt at least one feature information to generate a transmission security key. If it is determined that the sixth verification information does not match the third verification information, the processor 902 may not generate a transmission security key.

[0537] In an optional embodiment, after the processor 902 uses the transmission security key to decrypt the ciphertext to obtain a temporary key, the processor 902 can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information, and the transceiver 903 can also send the fourth verification information to the key management system so that the key management system verifies the fourth verification information before configuring the temporary key.

[0538] In an optional implementation, the transmission security key may satisfy the following formula:

[0539] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0540] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the key management system itself, and "TransportKey" is the string corresponding to the "transport security key";

[0541] Furthermore, the ciphertext can satisfy the following formula:

[0542] C = AES-GCM (tK, {M});

[0543] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0544] In an optional implementation, the second symmetric key may satisfy the following formula:

[0545] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0546] Among them, macKey is the second symmetric key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, and MAC is the authorization code;

[0547] Furthermore, the sixth verification information may satisfy the following formula:

[0548] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0549] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0550] In an optional implementation manner, the fourth verification information may satisfy the following formula:

[0551] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0552] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the key management system itself, C is the ciphertext, and MAC11 is the third verification information.

[0553] The vehicle diagnostic device 901 is the above-mentioned diagnostic equipment, and when executing the third embodiment:

[0554] The transceiver 903 may send a key authorization request to the unit to be diagnosed in the vehicle, and after the unit to be diagnosed generates a temporary key based on the key authorization request, receive a key authorization response sent by the unit to be diagnosed; the processor 902 may use the temporary key included in the key authorization response to initiate a diagnostic operation on the unit to be diagnosed. The temporary key is independent of the long-term key in the vehicle.

[0555] In an optional implementation, the processor 902 is specifically used to: encrypt the information to be diagnosed using a temporary key to generate a diagnosis request; the transceiver 903 is also used to: send a diagnosis request to the unit to be diagnosed, and receive a diagnosis result sent by the unit to be diagnosed. The diagnosis request is used by the unit to be diagnosed to diagnose and obtain a diagnosis result based on the information to be diagnosed obtained by parsing the diagnosis request using the temporary key.

[0556] In an optional implementation, the temporary key may also correspond to a validity period, which may be preconfigured, or may be indicated by a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0557] In an optional implementation, after the transceiver 903 sends a diagnosis request to the unit to be diagnosed and before receiving the diagnosis result sent by the unit to be diagnosed, the transceiver 903 may also send a security heartbeat message to the unit to be diagnosed within the validity period corresponding to the temporary key according to the preset cycle duration. The security heartbeat message is used for the unit to be diagnosed to continue to take effect on the temporary key.

[0558] In an optional implementation, before the transceiver 903 sends the security heartbeat message to the unit to be diagnosed, the processor 902 may also generate first verification information using at least one feature information used when generating the temporary key, and generate the security heartbeat message according to the first verification information. The first verification information is used for the unit to be diagnosed to verify the security heartbeat message.

[0559] In an optional implementation, at least one feature information may include at least one of a preset initial key, a feature identifier, a first random value, or a second random value. The feature identifier is used to indicate the unit to be diagnosed, the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, the first verification information may satisfy the following formula:

[0560] MAC31=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0561] Among them, MAC32 is the first verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value, and Nonce2 is a second random value.

[0562] In an optional implementation, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0563] In an optional implementation, the key authorization response may also include a ciphertext, where the ciphertext is obtained by the unit to be diagnosed encrypting a temporary key based on a transmission security key, and the transmission security key is obtained by the unit to be diagnosed encrypting at least one feature information based on a first symmetric key. Wherein, at least one feature information is carried in the key authorization request and sent to the unit to be diagnosed, and the at least one feature information includes at least one of a first random value, a characteristic identifier, or an authorization code. Wherein, the first random value is generated by the diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, after the transceiver 903 receives the key authorization response sent by the unit to be diagnosed, the processor 902 may also use the first symmetric key to encrypt at least one feature information to generate a transmission security key, and use the transmission security key to decrypt the ciphertext to obtain a temporary key.

[0564] In an optional implementation, the key authorization response may also include third verification information, which is obtained by the diagnostic unit encrypting the ciphertext and at least one feature information based on the second symmetric key, and the second symmetric key is a symmetric key derived from the first symmetric key. In this case, before the processor 902 uses the first symmetric key to encrypt at least one feature information to generate a transmission security key, the processor 902 may also first derive the second symmetric key based on the first symmetric key, and use the second symmetric key to encrypt the ciphertext and at least one feature information to obtain the sixth verification information. If the sixth verification information matches the third verification information, the processor 902 may use the first symmetric key to encrypt at least one feature information to generate a transmission security key. If the sixth verification information does not match the third verification information, the processor 902 may not generate a transmission security key.

[0565] In an optional embodiment, after the processor 902 uses the transmission security key to decrypt the ciphertext to obtain a temporary key, the processor 902 can also generate fourth verification information based on the ciphertext, the third verification information and one or more of at least one feature information, and the transceiver 903 can also send the fourth verification information to the unit to be diagnosed, so that the unit to be diagnosed verifies the fourth verification information before configuring the temporary key.

[0566] In an optional implementation, the transmission security key may satisfy the following formula:

[0567] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0568] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0569] Furthermore, the ciphertext can satisfy the following formula:

[0570] C = AES-GCM (tK, {M});

[0571] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0572] In an optional implementation, the second symmetric key may satisfy the following formula:

[0573] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0574] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0575] Furthermore, the sixth verification information may satisfy the following formula:

[0576] MAC12=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0577] Among them, MAC12 is the fourth verification information, C is the ciphertext, and Hash is the hash function.

[0578] In an optional implementation manner, the fourth verification information may satisfy the following formula:

[0579] MAC21=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0580] Among them, MAC21 is the fourth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0581] For the concepts, explanations, detailed descriptions and other steps related to the technical solutions of the diagnostic equipment provided in the embodiments of the present application involved in the vehicle diagnostic device 901, please refer to the descriptions of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0582] When the vehicle diagnostic device 901 corresponds to the unit to be diagnosed in the above method, the vehicle diagnostic device may include a processor 902, a transceiver 903 and a memory 904. The memory 904 is used to store instructions, and the processor 902 is used to execute the instructions stored in the memory 904 to implement the above Figures 1 to 8 A related scheme of the unit to be diagnosed in any one or more of the corresponding methods shown in .

[0583] When the vehicle diagnostic device 901 is the above-mentioned unit to be diagnosed, the vehicle diagnostic device 901 can be used to execute the method executed by the unit to be diagnosed in any one of the above-mentioned embodiments 1 to 3.

[0584] The vehicle diagnostic device 901 is the above-mentioned unit to be diagnosed, and when executing the first embodiment or the second embodiment:

[0585] The transceiver 903 can obtain the temporary key and receive the diagnostic request sent by the diagnostic device, which is encrypted by the temporary key; the processor 902 can use the temporary key to decrypt the diagnostic request to complete the diagnosis. The temporary key is independent of the long-term key in the vehicle.

[0586] In an optional implementation, the transceiver 903 is specifically used to: receive temporary key validation information sent by a key management system in the vehicle, wherein the temporary key validation information includes a temporary key. The processor 902 is also used to: store the temporary key carried in the temporary key validation information in the RAM of the unit to be diagnosed.

[0587] In an optional embodiment, after the processor 902 stores the temporary key carried in the temporary key validation information in the RAM of the unit to be diagnosed, the transceiver 903 can also receive temporary key expiration information sent by the key management system, where the temporary key expiration information includes the temporary key, and the processor 902 can also delete the temporary key carried in the temporary key expiration information from the RAM of the unit to be diagnosed.

[0588] The vehicle diagnostic device 901 is the above-mentioned unit to be diagnosed, and when executing the third embodiment:

[0589] The transceiver 903 may receive a key authorization request sent by the diagnostic device, the processor 902 may generate a temporary key according to the key authorization request, the transceiver 903 may also send a key authorization response to the diagnostic device, and carry the temporary key in the key authorization response, and the processor 902 may also complete the diagnosis based on the temporary key. The temporary key is independent of the long-term key in the vehicle to be diagnosed.

[0590] In an optional implementation, the processor 902 may also generate temporary keys corresponding to other units to be diagnosed for other units to be diagnosed.

[0591] In an optional implementation, the transceiver 903 is specifically used to: receive a diagnostic request sent by a diagnostic device; the processor 903 is specifically used to: use a temporary key to decrypt the diagnostic request to obtain information to be diagnosed, and perform a diagnostic operation based on the information to be diagnosed to obtain a diagnostic result; the transceiver 903 is also used to: send the diagnostic result to the diagnostic device.

[0592] In an optional implementation, the temporary key may also correspond to a validity period, which may be preconfigured, or may be indicated by a key authorization request, or may correspond to a period between the start and end of diagnosis.

[0593] In an optional implementation, after the transceiver 903 sends a key authorization response to the diagnostic device, the transceiver 903 may also wait to receive a security heartbeat message sent by the diagnostic device, and if the transceiver 903 does not receive the security heartbeat message sent by the diagnostic device within a preset period, the processor 902 may invalidate the temporary key. The security heartbeat message is sent by the diagnostic device to the unit to be diagnosed in a periodic manner within the effective period corresponding to the temporary key.

[0594] In an optional implementation, the security heartbeat message may include first verification information, and the first verification information is generated by at least one feature information used when generating a temporary key, and the at least one feature information includes at least one of a preset initial key, a feature identifier, a first random value, or a second random value. Among them, the feature identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device. In this case, if the transceiver 903 receives a security heartbeat message sent by the diagnostic device within a preset period, the processor 902 can also generate second verification information based on at least one feature information used when generating the temporary key. If it is determined that the second verification information matches the first verification information, the temporary key can continue to take effect.

[0595] In an optional implementation manner, the second verification information may satisfy the following formula:

[0596] MAC32=HMAC(macKey,Hash(ID||Nonce1||Nonce2));

[0597] Among them, MAC32 is the second verification information, HMAC is a message authentication code generation function based on hash operation, macKey is a symmetric key derived based on a preset initial key, ID is a characteristic identifier, Nonce1 is a first random value; Nonce2 is a second random value.

[0598] In an optional implementation, after the processor 902 generates the temporary key, the processor 902 may also configure the temporary key to take effect, and invalidate the temporary key after a valid time period corresponding to the temporary key has elapsed.

[0599] In an optional implementation, the temporary key may also correspond to an applicable scope, and the applicable scope corresponding to the temporary key is used to indicate the unit to be diagnosed. The applicable scope corresponding to the temporary key may be preconfigured, or may be indicated by a key authorization request.

[0600] In an optional implementation manner, the processor 902 is specifically configured to: configure a temporary key to each unit to be diagnosed required for this diagnosis.

[0601] In an optional implementation, the key authorization request may include at least one feature information, and the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code. The first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device. In this case, before the transceiver 903 sends a key authorization response to the diagnostic device, the processor 902 may also first use a first symmetric key to encrypt at least one feature information to generate a transmission security key, and then use the transmission security key to encrypt a temporary key to generate a ciphertext, and finally generate a key authorization response based on the ciphertext. The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain a temporary key.

[0602] In an optional implementation, the processor 902 is specifically configured to: first encrypt the ciphertext and at least one feature information using the second symmetric key to generate third verification information, and then generate a key authorization response based on the third verification information and the ciphertext. The second symmetric key is a symmetric key derived from the first symmetric key, and the third verification information is used by the diagnostic device to perform verification before decrypting the ciphertext.

[0603] In an optional implementation, after the transceiver 903 sends the key authorization response to the diagnostic device, the transceiver 903 may also receive the fourth verification information sent by the diagnostic device, and the processor 902 may also use the ciphertext, the third verification information, and one or more of the at least one feature information to generate the fifth verification information. If it is determined that the fourth verification information and the fifth verification information match, the processor 902 may make the temporary key configuration effective. If it is determined that the fourth verification information and the fifth verification information do not match, the processor 902 may not make the temporary key configuration effective. The fourth verification information is generated based on one or more of the ciphertext, the third verification information, and the at least one feature information.

[0604] In an optional implementation, the transmission security key may satisfy the following formula:

[0605] tK=HKDF(AK,ID||Nonce1||Nonce2||string "TransportKey");

[0606] Wherein, tK is the transport security key, HKDF refers to the key derivation function based on the hash operation message authentication code, AK is the first symmetric key, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, and the second random value is generated by the unit to be diagnosed, and "TransportKey" is the character string corresponding to the "transport security key";

[0607] Furthermore, the ciphertext can satisfy the following formula:

[0608] C = AES-GCM (tK, {M});

[0609] Where C is the ciphertext, AES-GCM is the AES symmetric encryption algorithm that uses the counting mode and carries the Galois message authentication code, and {M} is the temporary key.

[0610] In an optional implementation, the second symmetric key may satisfy the following formula:

[0611] macKey=HKDF(AK,ID||Nonce1||Nonce2||string "MAC");

[0612] Wherein, macKey is the second symmetric key, HKDF refers to a key derivation function based on a hash operation message authentication code, AK is the first symmetric key, ID is a characteristic identifier, Nonce1 is a first random value, Nonce2 is a second random value, the second random value is generated by the unit to be diagnosed, and MAC is an authorization code;

[0613] Furthermore, the third verification information may satisfy the following formula:

[0614] MAC11=HKDF(macKey,Hash(ID||Nonce1||Nonce2||C));

[0615] Among them, MAC11 is the third verification information, C is the ciphertext, and Hash is the hash function.

[0616] In an optional implementation manner, the fifth verification information may satisfy the following formula:

[0617] MAC22=HMAC(macKey,Hash(ID||Nonce1||Nonce2||C||MAC11));

[0618] Among them, MAC22 is the fifth verification information, HMAC refers to the message authentication code generation function based on hash operation, macKey is the second symmetric key, Hash is the hash function, ID is the characteristic identifier, Nonce1 is the first random value, Nonce2 is the second random value, the second random value is generated by the unit to be diagnosed, C is the ciphertext, and MAC11 is the third verification information.

[0619] In an optional implementation manner, the processor 902 is specifically configured to: store the temporary key in the RAM of the unit to be diagnosed.

[0620] In an optional implementation manner, the processor 902 is specifically configured to: delete the temporary key stored in the RAM of the unit to be diagnosed.

[0621] For the concepts, explanations, detailed descriptions and other steps related to the technical solutions of the unit to be diagnosed provided in the embodiment of the present application involved in the vehicle diagnostic device 901, please refer to the descriptions of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0622] Based on the above embodiments and the same concept, Fig.10 A schematic diagram of a vehicle diagnostic device provided in an embodiment of the present application, such as Fig.10 As shown, the vehicle diagnostic device 1001 may be a key management system in the vehicle, or may be a chip or a circuit, such as a chip or a circuit that may be disposed in a key management system.

[0623] The vehicle diagnostic device can correspond to the key management system in the above method. Figures 1 to 8 The vehicle diagnostic device may include a transceiver unit 1002 , a generation unit 1003 and a configuration unit 1004 .

[0624] When the vehicle diagnostic device 1001 is the above-mentioned key management system, the transceiver unit 1002 can receive the key authorization request sent by the diagnostic device, the generation unit 1003 can generate a temporary key according to the key authorization request, the transceiver unit 1002 can also send a key authorization response to the diagnostic device, and carry the temporary key in the key authorization response, and the configuration unit 1004 can configure the temporary key to the unit to be diagnosed in the vehicle, so that the diagnostic device and the unit to be diagnosed can complete the diagnosis based on the temporary key. Among them, the temporary key is independent of the long-term key in the vehicle.

[0625] The transceiver unit 1002 can be a sending unit or a transmitter when sending information, and can be a receiving unit or a receiver when receiving information. The transceiver unit 1002 can be a transceiver, and this transceiver, transmitter or receiver can be a radio frequency circuit. When the vehicle diagnostic device 1001 includes a storage unit, the storage unit is used to store computer instructions. The generation unit 1003 and the configuration unit 1004 are respectively connected to the storage unit for communication. The generation unit 1003 and the configuration unit 1004 respectively execute the computer instructions stored in the storage unit, so that the vehicle diagnostic device 1001 can be used to execute the method executed by the key management system in any of the above-mentioned embodiments 1 to 2. Among them, the generation unit 1003 or the configuration unit 1004 can be a general-purpose central processing unit (CPU), a microprocessor, or an application specific integrated circuit (Application Specific Intergrated Circuit, ASIC).

[0626] When the vehicle diagnostic device 1001 is a key management system, the transceiver unit 1002 may be an input and / or output interface, a pin or a circuit, etc. The generation unit 1003 and the configuration unit 1004 may execute the computer execution instructions stored in the storage unit, so that the chip in the vehicle diagnostic device 1001 executes the method executed by any one of the embodiments 1 to 2. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip in the vehicle diagnostic device 1001, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0627] For the concepts, explanations, detailed descriptions and other steps involved in the vehicle diagnostic device 1001 and related to the technical solution provided in the embodiment of the present application, please refer to the description of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0628] Based on the above embodiments and the same concept, Fig.11 A schematic diagram of a vehicle diagnostic device provided in an embodiment of the present application, such as Fig.11 As shown, the vehicle diagnostic device 1101 may be a diagnostic device, or may be a chip or a circuit, such as a chip or circuit that may be disposed in a diagnostic device.

[0629] The vehicle diagnostic device may correspond to the diagnostic device in the above method. Figures 1 to 8 The vehicle diagnostic device may include a transceiver unit 1102 and a diagnostic unit 1103 .

[0630] When the vehicle diagnostic device 1101 is the above-mentioned diagnostic equipment and implements the above-mentioned Figure 3 During the steps performed by the diagnostic device in the vehicle, the transceiver unit 1102 may send a key authorization request to the key management system in the vehicle, and after the key management system generates a temporary key based on the key authorization request and configures it to the unit to be diagnosed in the vehicle, receive a key authorization response sent by the key management system; the diagnostic unit 1103 may use the temporary key included in the key authorization response to initiate a diagnostic operation on the unit to be diagnosed. The temporary key is independent of the long-term key in the vehicle.

[0631] When the vehicle diagnostic device 1101 is the above-mentioned diagnostic equipment and implements the above-mentioned Figure 8 During the steps performed by the diagnostic device in the vehicle, the transceiver unit 1102 may send a key authorization request to the unit to be diagnosed in the vehicle, and after the unit to be diagnosed generates a temporary key based on the key authorization request, receive a key authorization response sent by the unit to be diagnosed, wherein the key authorization response includes a temporary key; the diagnostic unit 1103 may use the temporary key to initiate a diagnostic operation on the unit to be diagnosed. The temporary key is independent of the long-term key in the vehicle.

[0632] The transceiver unit 1102 may be a sending unit or a transmitter when sending information, and may be a receiving unit or a receiver when receiving information. The transceiver unit 1102 may be a transceiver, and the transceiver, transmitter or receiver may be a radio frequency circuit. When the vehicle diagnostic device 1101 includes a storage unit, the storage unit is used to store computer instructions, and the diagnostic unit 1103 is connected to the storage unit in communication, and the diagnostic unit 1103 executes the computer instructions stored in the storage unit, so that the vehicle diagnostic device 1101 can be used to execute the method executed by the diagnostic device in any of the above-mentioned embodiments 1 to 3. Among them, the diagnostic unit 1103 may be a general-purpose central processing unit (CPU), a microprocessor, or an application specific integrated circuit (ASIC).

[0633] When the vehicle diagnostic device 1101 is a chip, the transceiver unit 1102 may be an input and / or output interface, a pin or a circuit, etc. The diagnostic unit 1103 may execute the computer execution instructions stored in the storage unit, so that the chip in the vehicle diagnostic device 1101 executes the method executed by any one of the first to second embodiments. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip in the vehicle diagnostic device 1101, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0634] For the concepts, explanations, detailed descriptions and other steps involved in the vehicle diagnostic device 1101 and related to the technical solution provided in the embodiment of the present application, please refer to the description of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0635] Based on the above embodiments and the same concept, Fig.12 A schematic diagram of a vehicle diagnostic device provided in an embodiment of the present application, such as Fig.12 As shown, the vehicle diagnostic device 1201 can be a unit to be diagnosed, or a chip or circuit, such as a chip or circuit that can be arranged in the unit to be diagnosed. The unit to be diagnosed can be any ECU in the vehicle.

[0636] The vehicle diagnostic device may correspond to the unit to be diagnosed in the above method. Figures 1 to 8 The vehicle diagnosis device may include an acquisition unit 1202 , a transceiver unit 1203 and a diagnosis unit 1204 .

[0637] When the vehicle diagnostic device 1201 is the above-mentioned unit to be diagnosed, and implements the above-mentioned Figure 3 During the steps to be performed by the diagnostic unit, the acquisition unit 1202 can obtain the temporary key, the transceiver unit 1203 can receive the diagnostic request sent by the diagnostic device, which is encrypted and generated by the temporary key; the diagnostic unit 1204 can use the temporary key to decrypt the diagnostic request to complete the diagnosis. The temporary key is independent of the long-term key in the vehicle.

[0638] The transceiver unit 1203 may be a sending unit or a transmitter when sending information, and may be a receiving unit or a receiver when receiving information. The transceiver unit 1203 may be a transceiver, and the transceiver, transmitter or receiver may be a radio frequency circuit. When the vehicle diagnostic device 1201 includes a storage unit, the storage unit is used to store computer instructions, and the acquisition unit 1202 or the diagnostic unit 1204 may be respectively connected to the storage unit in communication, and the acquisition unit 1202 or the diagnostic unit 1204 executes the computer instructions stored in the storage unit, so that the vehicle diagnostic device 1201 can be used to execute the method executed by the diagnostic unit in any of the above-mentioned embodiments 1 to 2. Among them, the acquisition unit 1202 or the diagnostic unit 1204 may be a general-purpose central processing unit (CPU), a microprocessor, or an application specific integrated circuit (ASIC).

[0639] When the vehicle diagnostic device 1201 is a chip, the transceiver unit 1203 may be an input and / or output interface, a pin or a circuit, etc. The acquisition unit 1202 or the diagnosis unit 1204 may execute the computer execution instructions stored in the storage unit, so that the chip in the vehicle diagnostic device 1201 executes the method executed by the diagnostic unit in any one of the first to second embodiments. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip in the vehicle diagnostic device 1201, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0640] For the concepts, explanations, detailed descriptions and other steps involved in the vehicle diagnostic device 1201 and related to the technical solution provided in the embodiment of the present application, please refer to the description of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0641] Based on the above embodiments and the same concept, Fig.13 A schematic diagram of a vehicle diagnostic device provided in an embodiment of the present application, such as Fig.13 As shown, the vehicle diagnostic device 1301 can be a unit to be diagnosed, or a chip or circuit, such as a chip or circuit that can be arranged in the unit to be diagnosed. The unit to be diagnosed can be any ECU in the vehicle.

[0642] The vehicle diagnostic device may correspond to the unit to be diagnosed in the above method. Figure 8The vehicle diagnosis device may include a transceiver unit 1302 , a generator unit 1303 and a diagnosis unit 1304 .

[0643] When the vehicle diagnostic device 1301 is the above-mentioned unit to be diagnosed, and implements the above-mentioned Figure 8 During the steps performed by the unit to be diagnosed, the transceiver unit 1302 can receive the key authorization request sent by the diagnostic device, the generation unit 1303 can generate a temporary key according to the key authorization request, the transceiver unit 1302 can also send a key authorization response to the diagnostic device, and carry the temporary key in the key authorization response, and the diagnosis unit 1304 can complete the diagnosis based on the temporary key. The temporary key is independent of the long-term key in the vehicle to be diagnosed.

[0644] The transceiver unit 1302 may be a sending unit or a transmitter when sending information, and may be a receiving unit or a receiver when receiving information. The transceiver unit 1302 may be a transceiver, and the transceiver, transmitter or receiver may be a radio frequency circuit. When the vehicle diagnostic device 1301 includes a storage unit, the storage unit is used to store computer instructions, and the generation unit 1303 or the diagnosis unit 1304 may be respectively connected to the storage unit in communication, and the generation unit 1303 or the diagnosis unit 1304 executes the computer instructions stored in the storage unit, so that the vehicle diagnostic device 1301 can be used to execute the method executed by the unit to be diagnosed in the above-mentioned embodiment 3. Among them, the generation unit 1303 or the diagnosis unit 1304 may be a general-purpose central processing unit (CPU), a microprocessor, or an application specific integrated circuit (ASIC).

[0645] When the vehicle diagnostic device 1301 is a chip, the transceiver unit 1302 may be an input and / or output interface, a pin or a circuit, etc. The generation unit 1303 or the diagnosis unit 1304 may execute the computer execution instructions stored in the storage unit, so that the chip in the vehicle diagnostic device 1301 executes the method executed by the unit to be diagnosed in the third embodiment. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip in the vehicle diagnostic device 1301, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0646] For the concepts, explanations, detailed descriptions and other steps involved in the vehicle diagnostic device 1301 and related to the technical solution provided in the embodiment of the present application, please refer to the description of these contents in the aforementioned method or other embodiments, which will not be repeated here.

[0647] It should be understood that the division of the units of the above vehicle diagnostic devices 1001, 1101 and 1201 is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. In the embodiment of the present application, the transceiver unit 1002, the transceiver unit 1102, the transceiver unit 1203 and the transceiver unit 1302 can be composed of the above Fig. 9 The transceiver 903 is implemented, the generating unit 1003, the configuring unit 1004, the diagnosing unit 1103, the acquiring unit 1202, the diagnosing unit 1204, the generating unit 1303 and the diagnosing unit 1304 can be implemented by the above Fig. 9 The processor 902 is implemented.

[0648] According to the method provided in the embodiment of the present application, the present application also provides a computer program product, which includes: a computer program code, when the computer program code is run on a computer, the computer executes Figures 1 to 8 A method according to any one of the embodiments shown.

[0649] According to the method provided in the embodiment of the present application, the present application also provides a computer-readable storage medium, which stores a program code, and when the program code is run on a computer, the computer executes Figures 1 to 8 A method according to any one of the embodiments shown.

[0650] According to the method provided in the embodiment of the present application, the present application also provides a vehicle diagnostic system, which includes at least two of the aforementioned key management system, one or more diagnostic devices, and one or more units to be diagnosed.

[0651] An embodiment of the present application also provides a vehicle, which includes at least one unit to be diagnosed mentioned in the above embodiment of the present application, or the vehicle includes at least one key management system and a unit to be diagnosed mentioned in the above embodiment of the present application.

[0652] The terms "component", "module", "system", etc. used in this specification are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program and / or a computer. By way of illustration, both applications running on a computing device and a computing device can be components. One or more components may reside in a process and / or an execution thread, and a component may be located on a computer and / or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may, for example, communicate through local and / or remote processes based on signals having one or more data packets (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 interacting with other systems through signals).

[0653] Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or in a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0654] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

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

[0656] 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 distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0658] If the functions are implemented in the form of software functional 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 can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks or optical disks.

[0659] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A vehicle diagnostic system, characterized in that: including a key management system and a unit to be diagnosed located in a vehicle; The key management system is used to: receiving a key authorization request sent by a diagnostic device; generating a temporary key according to the key authorization request, the temporary key being independent of a long-term key in the vehicle; Sending a key authorization response to the diagnostic device, wherein the key authorization response includes the temporary key; The temporary key is configured to the unit to be diagnosed in the vehicle, and after the validity period corresponding to the temporary key has expired, the temporary key in the unit to be diagnosed is invalidated, and the configuration is used for the diagnostic device and the unit to be diagnosed to complete the diagnosis based on the temporary key within the validity period corresponding to the temporary key; The unit to be diagnosed is used for: Obtaining the temporary key from the key management system; receiving a diagnosis request sent by the diagnosis device, wherein the diagnosis request includes information to be diagnosed encrypted by the temporary key; decrypting the diagnosis request using the temporary key to obtain the information to be diagnosed; Perform a diagnostic operation according to the information to be diagnosed to obtain a diagnostic result; and The diagnosis result is sent to the diagnosis device.

2. The system according to claim 1, characterized in that The system further comprises the diagnostic device, which is used for: Sending the key authorization request to the key management system; Receiving the key authorization response sent by the key management system; encrypting the information to be diagnosed using the temporary key to generate the diagnosis request; Sending the diagnosis request to the unit to be diagnosed; Receive the diagnosis result sent by the unit to be diagnosed.

3. A vehicle diagnostic method, characterized in that: The method comprises: A key management system in the vehicle receives a key authorization request sent by the diagnostic device; The key management system generates a temporary key according to the key authorization request, wherein the temporary key is independent of a long-term key in the vehicle; The key management system sends a key authorization response to the diagnostic device, wherein the key authorization response includes the temporary key; The key management system configures the temporary key to the unit to be diagnosed in the vehicle, and invalidates the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has expired; the configuration is used for the diagnostic device and the unit to be diagnosed to complete the diagnosis based on the temporary key within the validity period corresponding to the temporary key.

4. The method according to claim 3, characterized in that The key management system invalidates the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has expired, including: If the key management system determines that the security heartbeat message sent by the diagnostic device is not received within a preset period, the temporary key in the unit to be diagnosed is invalidated; The security heartbeat message is sent by the diagnostic device to the key management system in a periodic manner within the validity period corresponding to the temporary key.

5. The method according to claim 4, characterized in that The security heartbeat message includes first verification information, where the first verification information is generated by at least one feature information used when generating the temporary key; The method further comprises: If the key management system determines that the security heartbeat message sent by the diagnostic device is received within a preset period, the key management system generates second verification information according to the at least one feature information used when generating the temporary key; When the key management system determines that the second verification information matches the first verification information, continuing to validate the temporary key; Among them, the at least one item of characteristic information includes at least one of a preset initial key, a characteristic identifier, a first random value or a second random value; the characteristic identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device.

6. The method according to any one of claims 3 to 5, characterized in that The validity period corresponding to the temporary key is preconfigured, or is indicated by the key authorization request, or corresponds to the period between the start and end of the diagnosis.

7. The method according to any one of claims 3 to 5, characterized in that The unit to be diagnosed is pre-configured or indicated by the key authorization request.

8. The method according to any one of claims 3 to 5, characterized in that The key authorization request includes at least one feature information; the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device; Before the key management system sends a key authorization response to the diagnostic device, the key management system further includes: The key management system encrypts the at least one feature information using a first symmetric key to generate a transmission security key; The key management system encrypts the temporary key using the transport security key to generate a ciphertext; The key management system generates the key authorization response according to the ciphertext; The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain the temporary key.

9. A vehicle diagnostic method, characterized in that: The method comprises: The diagnostic device sends a key authorization request to the key management system in the vehicle; the key authorization request is used by the key management system to generate a temporary key and configure it to the unit to be diagnosed in the vehicle, the temporary key is independent of the long-term key in the vehicle, and the temporary key in the unit to be diagnosed is invalidated by the key management system after the corresponding validity period. The diagnostic device receives a key authorization response sent by the key management system, wherein the key authorization response includes the temporary key; The diagnostic device initiates a diagnostic operation on the unit to be diagnosed using the temporary key.

10. The method according to claim 9, characterized in that The diagnostic device initiates a diagnostic operation on the unit to be diagnosed using the temporary key, including: The diagnostic device encrypts the information to be diagnosed using the temporary key to generate a diagnostic request; The diagnostic device sends the diagnostic request to the unit to be diagnosed; the diagnostic request is used for the unit to be diagnosed configured with the temporary key to obtain a diagnostic result according to the information to be diagnosed; The diagnostic device receives the diagnostic result sent by the unit to be diagnosed.

11. The method according to claim 10, characterized in that After the diagnostic device sends a diagnostic request to the unit to be diagnosed and before receiving the diagnostic result sent by the unit to be diagnosed, the method further includes: The diagnostic device sends a security heartbeat message to the key management system according to a preset period within the validity period corresponding to the temporary key, and the security heartbeat message is used by the key management system to continue to validate the temporary key.

12. The method according to claim 11, characterized in that Before the diagnostic device sends a security heartbeat message to the key management system according to a preset period duration within the validity duration corresponding to the temporary key, the diagnostic device further includes: The diagnostic device generates first verification information using at least one feature information used when generating the temporary key, and generates the security heartbeat message according to the first verification information; the first verification information is used by the key management system to verify the security heartbeat message; Among them, the at least one item of characteristic information includes at least one of a preset initial key, a characteristic identifier, a first random value or a second random value; the characteristic identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the key management system, and the second random value is generated by the key management system and sent to the diagnostic device.

13. The method according to claim 11 or 12, characterized in that The validity period corresponding to the temporary key is preconfigured, or is indicated by the key authorization request, or corresponds to the period between the start and end of the diagnosis.

14. The method according to any one of claims 9 to 12, characterized in that The unit to be diagnosed is pre-configured or indicated by the key authorization request.

15. The method according to any one of claims 9 to 12, characterized in that The key authorization response includes a ciphertext, where the ciphertext is obtained by the key management system encrypting the temporary key based on the transmission security key, and the transmission security key is obtained by the key management system encrypting at least one feature information based on the first symmetric key; the at least one feature information is carried in the key authorization request and sent to the key management system, and the at least one feature information includes at least one of a first random value, a feature identifier or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device; After the diagnostic device receives the key authorization response sent by the key management system, the method further includes: The diagnostic device encrypts the at least one feature information using the first symmetric key to generate the transmission security key; The diagnostic device decrypts the ciphertext using the transmission security key to obtain the temporary key.

16. A vehicle diagnostic method, characterized in that: The method comprises: The unit to be diagnosed in the vehicle obtains a temporary key from the key management system in the vehicle, wherein the temporary key is independent of the long-term key in the vehicle and is invalidated by the key management system after a corresponding validity period. The unit to be diagnosed receives a diagnosis request sent by a diagnosis device, wherein the diagnosis request is generated by encrypting the temporary key; The unit to be diagnosed decrypts the diagnosis request using the temporary key to complete the diagnosis.

17. The method according to claim 16, characterized in that The unit to be diagnosed in the vehicle obtains a temporary key from a key management system in the vehicle, including: The unit to be diagnosed receives temporary key validation information sent by the key management system in the vehicle, wherein the temporary key validation information includes the temporary key; The unit to be diagnosed stores the temporary key in a random access memory RAM according to the temporary key validation information.

18. The method according to claim 17, characterized in that After the unit to be diagnosed in the vehicle obtains the temporary key, the method further includes: The unit to be diagnosed receives temporary key expiration information sent by the key management system in the vehicle, wherein the temporary key expiration information includes the temporary key; The unit to be diagnosed deletes the temporary key stored in the RAM according to the temporary key expiration information.

19. A vehicle diagnostic system, characterized in that: The method comprises a diagnostic device and a unit to be diagnosed, wherein the unit to be diagnosed is located in a vehicle, and the diagnostic device is connected to the unit to be diagnosed; The diagnostic device is used for: Sending a key authorization request to the unit to be diagnosed; receiving a key authorization response sent by the unit to be diagnosed, wherein the key authorization response includes a temporary key, and the temporary key is independent of a long-term key in the vehicle; as well as, Initiate a diagnostic operation on the unit to be diagnosed using the temporary key; The unit to be diagnosed is used for: receiving a key authorization request sent by the diagnostic device; Generate the temporary key according to the key authorization request, make the temporary key configuration effective, and invalidate the temporary key in the unit to be diagnosed after the validity period corresponding to the temporary key has expired; sending the key authorization response to the diagnostic device; and, The diagnosis is performed based on the temporary key.

20. The system of claim 19, wherein: The unit to be diagnosed is further used for: A temporary key is generated for other units to be diagnosed in the vehicle and is used for the diagnostic device to diagnose the other units to be diagnosed.

21. A vehicle diagnostic method, characterized in that: The method comprises: The unit to be diagnosed in the vehicle receives a key authorization request sent by the diagnostic device; The unit to be diagnosed generates a temporary key according to the key authorization request, wherein the temporary key is independent of a long-term key in the vehicle; The unit to be diagnosed makes the temporary key configuration effective, and after the validity period corresponding to the temporary key has elapsed, the temporary key in the unit to be diagnosed is invalidated; The unit to be diagnosed sends a key authorization response to the diagnostic device, wherein the key authorization response includes the temporary key; The unit to be diagnosed completes the diagnosis based on the temporary key.

22. The method according to claim 21, characterized in that The method further comprises: The unit to be diagnosed generates a temporary key for other units to be diagnosed in the vehicle, which is used by the diagnostic device to diagnose the other units to be diagnosed.

23. The method according to claim 21 or 22, characterized in that After the unit to be diagnosed sends a key authorization response to the diagnostic device, the method further includes: If the unit to be diagnosed determines that the security heartbeat message sent by the diagnostic device has not been received within a preset period, the temporary key in the unit to be diagnosed is invalidated; The security heartbeat message is sent by the diagnostic device to the unit to be diagnosed in a periodic manner within the validity period corresponding to the temporary key.

24. The method of claim 23, wherein: The security heartbeat message includes first verification information, where the first verification information is generated by at least one feature information used when generating the temporary key; The method further comprises: If the unit to be diagnosed determines that a security heartbeat message sent by the diagnostic device is received within a preset period, the second verification information is generated according to the at least one feature information used when generating the temporary key, and if it is determined that the second verification information matches the first verification information, the temporary key continues to be effective; Among them, the at least one item of characteristic information includes at least one of a preset initial key, a characteristic identifier, a first random value or a second random value; the characteristic identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device.

25. The method according to claim 21 or 22, characterized in that The validity period corresponding to the temporary key is preconfigured, or is indicated by the key authorization request, or corresponds to the period between the start and end of the diagnosis.

26. The method according to claim 21 or 22, characterized in that After the unit to be diagnosed generates a temporary key according to the key authorization request, the method further includes: The unit to be diagnosed stores the temporary key in a random access memory RAM.

27. The method according to claim 21 or 22, characterized in that The key authorization request includes at least one feature information; the at least one feature information includes at least one of a first random value, a feature identifier, or an authorization code, the first random value is generated by the diagnostic device, the feature identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device; Before the unit to be diagnosed sends a key authorization response to the diagnostic device, the method further includes: The unit to be diagnosed encrypts the at least one feature information using a first symmetric key to generate a transmission security key; The unit to be diagnosed encrypts the temporary key using the transmission security key to generate a ciphertext; The unit to be diagnosed generates the key authorization response according to the ciphertext; The ciphertext is used by the diagnostic device to decrypt using the transmission security key to obtain the temporary key.

28. A vehicle diagnostic method, characterized in that: The method comprises: The diagnostic device sends a key authorization request to the unit to be diagnosed in the vehicle, wherein the key authorization request is used for the unit to be diagnosed to generate a temporary key, wherein the temporary key is independent of the long-term key in the vehicle, and the temporary key in the unit to be diagnosed is invalidated by the unit to be diagnosed after the validity period corresponding to the temporary key has expired; The diagnostic device receives a key authorization response sent by the unit to be diagnosed, wherein the key authorization response includes the temporary key; The diagnostic device initiates a diagnostic operation on the unit to be diagnosed using the temporary key.

29. The method of claim 28, wherein: After the diagnostic device sends a diagnostic request to the unit to be diagnosed using the temporary key pair, the method further includes: The diagnostic device sends a security heartbeat message to the unit to be diagnosed within a valid time period corresponding to the temporary key according to a preset period, and the security heartbeat message is used for the unit to be diagnosed to continue to validate the temporary key.

30. The method of claim 29, wherein: Before the diagnostic device sends a security heartbeat message to the unit to be diagnosed according to a preset period duration within the validity duration corresponding to the temporary key, the diagnostic device further includes: The diagnostic device generates first verification information using at least one feature information used when generating the temporary key, and generates the security heartbeat message according to the first verification information; the first verification information is used by the unit to be diagnosed to verify the security heartbeat message; Among them, the at least one item of characteristic information includes at least one of a preset initial key, a characteristic identifier, a first random value or a second random value; the characteristic identifier is used to indicate the unit to be diagnosed; the first random value is generated by the diagnostic device and sent to the unit to be diagnosed, and the second random value is generated by the unit to be diagnosed and sent to the diagnostic device.

31. The method according to any one of claims 28 to 30, characterized in that The validity period corresponding to the temporary key is preconfigured, or is indicated by the key authorization request, or corresponds to the period between the start and end of the diagnosis.

32. The method according to any one of claims 28 to 30, characterized in that The unit to be diagnosed is pre-configured or indicated by the key authorization request.

33. The method according to any one of claims 28 to 30, characterized in that The key authorization response includes a ciphertext, where the ciphertext is obtained by the unit to be diagnosed encrypting the temporary key based on the transmission security key, and the transmission security key is obtained by the unit to be diagnosed encrypting at least one feature information based on the first symmetric key; the at least one feature information is carried in the key authorization request and sent to the unit to be diagnosed, and the at least one feature information includes at least one of a first random value, a characteristic identifier or an authorization code, the first random value is generated by the diagnostic device, the characteristic identifier is used to indicate the unit to be diagnosed, and the authorization code is used to indicate the diagnostic device; After the diagnostic device receives the key authorization response sent by the unit to be diagnosed, the diagnostic device further includes: The diagnostic device encrypts the at least one feature information using the first symmetric key to generate the transmission security key; The diagnostic device decrypts the ciphertext using the transmission security key to obtain the temporary key.

34. A vehicle diagnostic device, characterized in that: include: A transceiver unit, used for receiving a key authorization request sent by a diagnostic device; a generating unit, configured to generate a temporary key according to the key authorization request, wherein the temporary key is independent of a long-term key in the vehicle; The transceiver unit is further used to send a key authorization response to the diagnostic device, wherein the key authorization response includes the temporary key; A configuration unit, configured to configure the temporary key to the unit to be diagnosed in the vehicle, and to invalidate the temporary key in the unit to be diagnosed after a valid time period corresponding to the temporary key has elapsed; The configuration is used for the diagnostic device and the unit to be diagnosed to complete diagnosis based on the temporary key.

35. A vehicle diagnostic device, characterized in that: include: A transceiver unit, used to send a key authorization request to a key management system in the vehicle, wherein the key authorization request is used by the key management system to generate a temporary key and configure it to the unit to be diagnosed in the vehicle, wherein the temporary key is independent of the long-term key in the vehicle, and the temporary key in the unit to be diagnosed is invalidated by the key management system after a corresponding validity period; and, receiving a key authorization response sent by the key management system, wherein the key authorization response includes the temporary key; The diagnosis unit is used to initiate a diagnosis operation on the unit to be diagnosed using the temporary key.

36. A vehicle diagnostic device, characterized in that: include: an acquisition unit, configured to acquire a temporary key, wherein the temporary key is independent of a long-term key in the vehicle; A transceiver unit, configured to receive a diagnostic request sent by a diagnostic device, wherein the diagnostic request is generated by encrypting the temporary key; a diagnosis unit, configured to decrypt the diagnosis request using the temporary key to complete the diagnosis; The temporary key is stored in a random access memory RAM of the vehicle diagnostic device; After the acquisition unit acquires the temporary key: The transceiver unit is further used to: receive temporary key expiration information; The diagnostic unit is further used to delete the temporary key in the RAM according to the temporary key expiration information.

37. A vehicle diagnostic device, characterized in that: include: A transceiver unit, used for receiving a key authorization request sent by a diagnostic device; a generating unit, configured to generate a temporary key according to the key authorization request, wherein the temporary key is independent of a long-term key in the vehicle; The transceiver unit is further used to send a key authorization response to the diagnostic device, wherein the key authorization response includes the temporary key; a diagnosis unit, configured to complete the diagnosis based on the temporary key; After the generating unit generates the temporary key according to the key authorization request, the diagnosing unit is further used for: The temporary key configuration is validated, and after the validity period corresponding to the temporary key has elapsed, the temporary key is invalidated.

38. A vehicle diagnostic device, characterized in that: include: A transceiver unit, configured to send a key authorization request to a unit to be diagnosed in a vehicle, wherein the key authorization request is used for the unit to be diagnosed to generate a temporary key, wherein the temporary key is independent of the long-term key in the vehicle, and the temporary key in the unit to be diagnosed is invalidated after the validity period corresponding to the temporary key has expired; and, receiving a key authorization response sent by the unit to be diagnosed, wherein the key authorization response includes the temporary key; The diagnosis unit is used to initiate a diagnosis operation on the unit to be diagnosed using the temporary key.

39. A vehicle diagnostic device, characterized in that: It includes a processor and a communication interface, wherein the communication interface is used to receive signals from other communication devices other than the vehicle diagnostic device and transmit them to the processor or send signals from the processor to other communication devices other than the vehicle diagnostic device; the processor is used to implement the method as described in any one of claims 3 to 8, or the method as described in any one of claims 9 to 15, or the method as described in any one of claims 16 to 18, or the method as described in any one of claims 21 to 27, or the method as described in any one of claims 28 to 33 through logic circuits or execution of code instructions.

40. A vehicle, characterized in that: The vehicle comprises a key management system and a unit to be diagnosed, wherein the key management system is used to implement the method according to any one of claims 3 to 8, and the unit to be diagnosed is used to implement the method according to any one of claims 16 to 18; or, The vehicle comprises a key management system, a diagnostic device and a unit to be diagnosed, wherein the key management system is used to implement the method according to any one of claims 3 to 8, the diagnostic device is used to implement the method according to any one of claims 9 to 15, and the unit to be diagnosed is used to implement the method according to any one of claims 16 to 18; or, The vehicle comprises a unit to be diagnosed, and the unit to be diagnosed is used to implement the method according to any one of claims 21 to 27; or, The vehicle comprises a unit to be diagnosed and a diagnostic device, the unit to be diagnosed being used to implement the method according to any one of claims 21 to 27, and the diagnostic device being used to implement the method according to any one of claims 28 to 33.

41. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed, implements the method as described in any one of claims 3 to 8, or implements the method as described in any one of claims 9 to 15, or implements the method as described in any one of claims 16 to 18, or implements the method as described in any one of claims 21 to 27, or implements the method as described in any one of claims 28 to 33.

42. A computer program product, characterized in that The computer program product includes a computer program or instructions, which, when executed by a communication device, implements the method as described in any one of claims 3 to 8, or implements the method as described in any one of claims 9 to 15, or implements the method as described in any one of claims 16 to 18, or implements the method as described in any one of claims 21 to 27, or implements the method as described in any one of claims 28 to 33.

Images