Security access method, device and system and vehicle

Abstract

The invention discloses a security access method, device and system and a vehicle, relates to the technical field of security control, and can improve data security and vehicle security in a data access process. In the scheme, when the diagnostic equipment has a demand for accessing a certain vehicle, the diagnostic equipment can send the access request to the first device on the vehicle and carries the first information used for indicating the legal binding relationship between the diagnostic equipment and the vehicle, and the first device can send the access request to the first device after the first device performs security verification based on the first information. A diagnostic device is allowed to access the vehicle. On the basis, the influence on other vehicles when one vehicle has potential safety hazards can be avoided by performing authorization management on diagnosis equipment and vehicle dimensions; besides, the isolation effect provided by the first device enables the key of the ECU in the vehicle to be invisible to the diagnosis equipment, so that the risk of key leakage of the ECU in the target vehicle is avoided, and the influence on the safety of the target vehicle and other vehicles can be avoided.

Description

Technical Field

[0001] The present application relates to the technical field of security control, and particularly to a security access method, device, system and vehicle. Background Art

[0002] Currently, in the field of intelligent vehicles, vehicle problem diagnosis, problem repair, software upgrade, etc. are widely applied through a diagnostic instrument. In this process, it is inevitable to involve reading, writing or modifying vehicle-related data by the diagnostic instrument, which poses certain security risks to the vehicle.

[0003] To improve the security of data in a vehicle, when a diagnostic instrument requests to access vehicle-related data, a security server usually performs security verification on the diagnostic instrument and allows it to access relevant data in the vehicle after the verification passes. However, based on this security verification mechanism, once the diagnostic instrument passes the verification, it can access any data in the vehicle. As we know, the diagnostic instrument usually has relatively large permissions, such as functions of querying the status of various vehicle components, reading and writing configuration words, querying and clearing fault codes, modifying codes, software flashing, etc. Therefore, the conventional security verification mechanism still poses great risks to the vehicle. Summary of the Invention

[0004] The present application provides a security access method, device, system and vehicle, which can improve data security and vehicle security during the data access process.

[0005] To achieve the above object, the present application adopts the following technical solutions:

[0006] In a first aspect, a security access method is provided. The method can be applied to a first device on a first vehicle. The method includes:

[0007] First, the first device receives a first access request from a first diagnostic device for requesting access to the first vehicle. The first access request carries first information, and the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle. As an example, the first diagnostic device is such as a diagnostic instrument; the legal binding relationship between the first diagnostic device and the first vehicle means that based on the first information, it can be determined that the first diagnostic device is allowed to access the first vehicle. As an example, the first information can be obtained by the first diagnostic device from a server, and the first information can be for one vehicle.

[0008] Then, the first device performs a first security verification on the access permission of the first diagnostic device to access the first vehicle based on the first information.

[0009] Finally, when the first security verification is passed, the first device sends a first feedback message to the first diagnostic device, where the first feedback message is used to indicate that the first diagnostic device is allowed to access the first vehicle. As an example, when the first security verification is passed, the first device can unlock the vehicle or one or more electronic control units (ECUs) in the vehicle and send the first feedback message to the first diagnostic device.

[0010] In some examples, when the first security verification fails, the first device can send a second feedback message to the first diagnostic device, where the second feedback message is used to indicate that the first vehicle does not allow the first diagnostic device to access the first vehicle.

[0011] As an example, the first access request is used to request one or more of the following: reading data in the first vehicle, modifying data in the first vehicle, writing data to the first vehicle.

[0012] In the solution provided in the first aspect above, when a diagnostic device needs to access a certain vehicle (such as the first vehicle), it can send an access request to the first device on the vehicle and carry the first information indicating the legal binding relationship between the diagnostic device and the vehicle. In this way, the first device can allow the diagnostic device to access the vehicle after the security verification of the diagnostic device's permission to access the first vehicle based on the first information. Based on this, through the authorization management of the legal binding relationship between the diagnostic device and a vehicle, the impact on other vehicles when a vehicle has a security hazard can be avoided; for example, even if the first information used to access the target vehicle is obtained by a third party, since the first information indicates the legal binding relationship between the diagnostic device and the target vehicle, and cannot indicate the legal binding relationship between the diagnostic device and other vehicles, nor can it indicate the legal binding relationship between other diagnostic devices and the first vehicle or other vehicles, the third party cannot access the first vehicle and other vehicles based on this, and thus will not affect the security of the vehicles. In addition, the isolation function provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle, that is, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device, so the risk of leakage of the key of the ECU in the target vehicle will not occur, and thus the security of the target vehicle and other vehicles can be prevented from being affected.

[0013] As a possible implementation, the first device has the key of the ECU on the first vehicle, and the first diagnostic device does not store the key of the ECU on the first vehicle. Based on this, through the isolation function of the first device, the impact of the diagnostic device obtaining the key of the ECU on the vehicle on the security of the ECU can be avoided.

[0014] As a possible implementation, the first information is the information encrypted based on the first encryption method. The first information is used to indicate the temporary key. The first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information, including: the first device decrypts the first information according to the first decryption method corresponding to the first encryption method indicated by the server to obtain the temporary key; the first device verifies the temporary key based on the symmetric key authentication algorithm to perform the first security verification. It can be understood that the temporary key usually has a valid duration. Therefore, when the diagnostic device needs to access the first ECU on the first vehicle, it can send the temporary key indicating the legal binding relationship between the diagnostic device and the vehicle to the first device, which can improve the data security and vehicle security during the data access process, and reduce the impact on the security of the first vehicle after the temporary key is obtained by a third party. For example, when a third party maliciously accesses the first vehicle using the obtained temporary key, the temporary key is likely to have expired, so it will not affect the security of the first vehicle. In addition, since the first information is the encrypted temporary key, it can also improve the security during the transmission of the temporary key from the first diagnostic device to the first device.

[0015] Among them, in this implementation, the fact that the temporary key is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the temporary key. For example, the key saved in the first device is the same as the temporary key, or the key saved in the first device and the temporary key are a public-private key pair.

[0016] As a possible implementation, the above temporary key is encrypted using the encryption method indicated by the server. The first device decrypts the first information to obtain the temporary key, including: the first device decrypts the first information according to the decryption method indicated by the server to obtain the temporary key. As an example, the encryption method indicated by the server may include, but is not limited to, the Prek encryption method. Based on this, the security during the transmission of the temporary key from the first diagnostic device to the first device can be improved.

[0017] As a possible implementation, the first access request is used to request access to the first ECU on the first vehicle. The above-mentioned temporary key is the 27 service key. The first device verifies the temporary key based on the symmetric key authentication algorithm, including: The first device obtains the 27 service seed from the first ECU and sends the 27 service seed to the first diagnostic device; The first device calculates the first message authentication code (MAC) according to the 27 service key and the 27 service seed; The first device receives the second MAC calculated by the first diagnostic device according to the 27 service key and the 27 service seed; The first device verifies whether the second MAC is the same as the first MAC. For example, if the second MAC is the same as the first MAC, the first device passes the first security verification of the first diagnostic device; if the second MAC is different from the first MAC, the first device passes the first security verification of the first diagnostic device. Based on this, reliable and accurate security verification results can be provided.

[0018] Exemplarily, the symmetric key authentication algorithm may include but is not limited to any one of the following: AES (AES-cipher-based message authentication code, AES-CMAC) algorithm, AES (AES-cipherblock chaining, AES-CBC) algorithm with cipher block chaining, AES (AES-GMAC CTR mode, AES-GCM) algorithm in GMAC CTR mode.

[0019] As a possible implementation, the first information carried in the above-mentioned first access request is the device security certificate. The first device performs the first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information, including: The first device verifies the legality of the device security certificate; When the device security certificate is legal, the first device verifies whether the identification code carried in the device security certificate is consistent with the identification code of the first vehicle (such as the vehicle identification number (VIN)) to perform the first security verification on the first diagnostic device. Exemplarily, the device security certificate may include but is not limited to the 29 service certificate. Based on this, reliable and accurate security verification results can be provided.

[0020] Among them, in this implementation, the device security certificate is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the device security certificate. For example, there is a preset corresponding relationship between the root certificate saved in the first device and the device security certificate, such as a preset corresponding relationship between the identification information of the root certificate saved in the first device and the identification information of the device security certificate.

[0021] In some examples, the device security certificate carried in the first access request may correspond to a vehicle. For example, the device security certificate carries an identification code, and this identification code is the identification code of the first vehicle. In some examples, the device security certificate carried in the first access request may correspond to multiple vehicles. For example, the device security certificate carries multiple identification codes, and these multiple identification codes are the identification codes of multiple different vehicles, and these multiple identification codes include the identification code of the first vehicle. Based on this, a flexible security control mechanism can be provided to authorize the device security certificate to the diagnostic device according to actual needs. For example, authorize the device security certificate that can only access one vehicle or authorize the device security certificate that can access multiple vehicles to the diagnostic device according to actual needs, while improving the data security and vehicle security during the data access process, and flexibly controlling the permission scope of the diagnostic device.

[0022] In some examples, the first device may verify the legitimacy of the device security certificate and the identification code carried therein based on an asymmetric key authentication algorithm. Exemplarily, the asymmetric key verification algorithm may include but is not limited to any one of the following: RSA algorithm, digital signature arithmetic (DSA), elliptic curve cryptography (ECC) algorithm, etc., without specific limitation.

[0023] As a possible implementation, the first access request also carries the identification of the first ECU, and the first access request is used to request access to the first ECU on the first vehicle. The above method further includes: the first device requests the first ECU to perform a second security verification for the first device to access the first ECU according to the identification of the first ECU carried in the first access request, where the second security verification is based on the key of the first ECU, and the key of the first ECU is invisible to the first diagnostic device. Combining the first security verification of the first device for the first diagnostic device, in this implementation, the first security verification of the first device for the first diagnostic device can be understood as an out-of-vehicle security verification, and based on the first security verification, the permission of the first diagnostic device to access the first vehicle can be verified. The second security verification of the first ECU for the first device to access the first ECU can be understood as an in-vehicle security verification, and based on the second security verification, the permission of the first device to proxy access the first ECU can be verified. Based on this, through the out-of-vehicle and in-vehicle security verification isolation mechanism of the first device, not only can more effective security verification be performed on the diagnostic device to access the target ECU, but also the leakage of the ECU key can be avoided. For example, due to the isolation of the first device, the first diagnostic device cannot obtain the key of the ECU in the first vehicle, so the risk of leakage of the key of the ECU in the vehicle will not occur, thereby avoiding the security impact on the ECU.

[0024] As a possible implementation, the method further includes: the first device obtains a third MAC, wherein the third MAC is calculated based on a stored key of the first ECU (such as the first ECU KEY) and a service seed corresponding to the first ECU, and the service seed corresponding to the first ECU is obtained from the first ECU; the first device sends the third MAC to the first ECU to request the first ECU to perform a second security verification. Based on this, a reliable and accurate in-vehicle security verification result can be provided.

[0025] As an example, when both the first security verification and the second security verification are passed, the first device may send the above-mentioned first feedback message to the first diagnostic device, or when the first security verification is passed but the second security verification is not passed, the first device may send a third feedback message to the first diagnostic device to indicate that the first vehicle does not allow the first diagnostic device to access the first ECU.

[0026] As an example, an ECU on the first vehicle corresponds to an ECU KEY, and the service seed (such as 27 service seeds) corresponding to the first ECU can be a randomly generated temporary service seed. As an example, the number of bits of the ECU KEY can be the same as the number of bits of the service seed corresponding to the first ECU, such as 128 bits, etc., without specific limitation.

[0027] It should be noted that the solution provided in this application can be applicable to a variety of different equipment / product types.

[0028] For example, in some examples, the first device may have a diagnostic proxy service and a key management service. In this case, the first device may call the key management service to obtain the stored key of the first ECU, and calculate the third MAC based on the key of the first ECU and the service seed corresponding to the first ECU. Exemplarily, the first device may be a chip having a diagnostic proxy service and a key management service.

[0029] For another example, in some examples, the first device does not have a key management service. In this case, the first device can send the service seed corresponding to the first ECU to a module for providing key management services, such as a key management module, etc. The key management module can obtain the stored key of the first ECU, and calculate the third MAC based on the key of the first ECU and the service seed corresponding to the first ECU and send it to the first device. Exemplarily, the first device can be a chip with a diagnostic agent service, and the key management module can be a chip with a key management service.

[0030] As a possible implementation, the above method further includes: First, the first device receives a second access request from the first diagnostic device, where the second access request carries second information and the identifier of the second ECU. The second access request is used to request access to the second ECU on the first vehicle, and the second information is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle. Then, the first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the second information. After that, when the first security verification passes, the first device requests the second ECU to perform a second security verification for the first device to access the second ECU based on the key of the second ECU, where the key of the second ECU is invisible to the first diagnostic device. Finally, when the second security verification passes, the first device sends a feedback message to the first diagnostic device to indicate that the first diagnostic device is allowed to access the second ECU. Exemplarily, the second ECU is different from the first ECU, and the second information is the same as the first information. Based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access a vehicle, more strict security control can be provided when the diagnostic device accesses the vehicle, while improving the data security and vehicle security during the data access process, and avoiding the impact on the security of other vehicles after the first information of one vehicle is obtained by a third party; or, the second ECU is different from the first ECU, and the second information is different from the first information. Based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access an ECU in a vehicle, more strict security control can be provided when the diagnostic device accesses the ECU in the vehicle, while improving the data security and vehicle security during the data access process, and avoiding the impact on the security of other ECUs after the first information of one ECU is obtained by a third party.

[0031] As a possible implementation, the above method further includes: First, the first device receives a third access request from the second diagnostic device, where the third access request carries third information and the identifier of the third ECU. The third access request is used to request access to the third ECU on the first vehicle, and the third information is used to indicate the legal binding relationship between the second diagnostic device and the first vehicle. Then, the first device performs a first security verification on the permission of the second diagnostic device to access the first vehicle based on the third information. After that, when the first security verification passes, the first device requests the third ECU to perform a second security verification for the first device to access the third ECU based on the key of the third ECU, where the key of the third ECU is invisible to the second diagnostic device. Finally, when the second security verification passes, the first device sends a feedback message to the second diagnostic device to indicate that the second diagnostic device is allowed to access the third ECU. Based on this, through an authorization mechanism that authorizes an information for a diagnostic device to access a vehicle, more stringent security control can be provided when a diagnostic device accesses a vehicle, while improving data security and vehicle security during the data access process, and avoiding the impact on the security of other vehicles when the first information of a vehicle is obtained by a third party.

[0032] In a second aspect, a security access method is provided. This method can be applied to a diagnostic device and includes: The diagnostic device sends a request message for accessing the first vehicle to the server; The diagnostic device receives first information from the server, where the first information is used to indicate the legal binding relationship between the diagnostic device and the first vehicle; The diagnostic device sends a first access request to the first device on the first vehicle, where the first access request is used to request access to the first ECU on the first vehicle, and the first access request carries the first information.

[0033] As an example, the first access request is used to request one or more of the following: Reading data in the first ECU, modifying data in the first ECU, writing data into the first ECU.

[0034] For the solution provided in the second aspect above, when the diagnostic device needs to access a certain ECU (such as the first ECU) on a certain vehicle (such as the first vehicle), it can request the server for the first information used to indicate the legal binding relationship between the diagnostic device and the vehicle, and carry the first information when sending an access request to the first device in the vehicle. Based on this, through the authorization management of the legal binding relationship between the diagnostic device and a vehicle, the impact on other vehicles when one vehicle has potential safety hazards can be avoided. For example, even if the first information used to access the target vehicle is obtained by a third party, since the first information indicates the legal binding relationship between the diagnostic device and the target vehicle, and cannot indicate the legal binding relationship between the diagnostic device and other vehicles, nor can it indicate the legal binding relationship between other diagnostic devices and the first vehicle or other vehicles, the third party cannot access the first vehicle and other vehicles based on this, and thus will not affect the safety of the vehicles. In addition, the isolation function provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle, that is, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device, so the risk of leakage of the key of the ECU in the target vehicle will not occur, and further the safety of the target vehicle and other vehicles can be prevented from being affected.

[0035] As a possible implementation, the first device has the key of the ECU on the first vehicle, and the diagnostic device does not store the key of the ECU on the first vehicle. Based on this, through the isolation function of the first device, the impact on the safety of the ECU caused by the diagnostic device obtaining the key of the ECU on the vehicle can be avoided.

[0036] As a possible implementation, the first access request also carries the identifier of the first ECU, and the first access request is used to request access to the first ECU on the first vehicle. Based on this, targeted access to the ECU on the target vehicle can be achieved, enriching the usage scenarios of this solution and making it applicable to diverse access requirements.

[0037] As a possible implementation manner, the first information carried in the above first access request is used to indicate a temporary key or a device security certificate. Exemplarily, the temporary key is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the temporary key. For example, the key stored in the first device is the same as the temporary key, or the key stored in the first device and the temporary key are a public-private key pair; the device security certificate is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the device security certificate. For example, there is a preset corresponding relationship between the root certificate stored in the first device and the device security certificate, such as a preset corresponding relationship between the identification information of the root certificate stored in the first device and the identification information of the device security certificate. Based on this, the diagnostic device can request to access the first vehicle from the first device through different forms of the first information, so that the first device can perform reliable and accurate security verification.

[0038] As a possible implementation manner, the first information is information encrypted based on a first encryption method. The above method further includes: the diagnostic device receives fourth information from the server, where the fourth information is a temporary key encrypted based on a second encryption method; the diagnostic device decrypts the fourth information according to the second decryption method corresponding to the second encryption method indicated by the server to obtain the temporary key therein; the diagnostic device participates in the first security verification of the first device for the permission of the diagnostic device to access the first vehicle based on the temporary key obtained by decrypting the fourth information. Based on this, the security of the transmission of the temporary key from the server to the diagnostic device can be improved.

[0039] As a possible implementation manner, the above first information is used to indicate a 27 service key. The above participation of the temporary key obtained by decrypting the fourth information in the first security verification of the first device for the permission of the first diagnostic device to access the first vehicle includes: the diagnostic device requests a 27 service seed of the first ECU from the first device; the diagnostic device receives the 27 service seed of the first ECU from the first device; the diagnostic device calculates a second MAC according to the 27 service key and the 27 service seed; the diagnostic device sends the second MAC to the first device, and the second MAC is used for the first device to perform the first security verification. Based on this, it is convenient for the first device to perform reliable and accurate first security verification on the diagnostic device by comparing the first MAC and the second MAC.

[0040] In some examples, the device security certificate carried in the first access request may correspond to a vehicle. For example, the device security certificate carries an identification code, and this identification code is the identification code of the first vehicle. In some examples, the device security certificate carried in the first access request may correspond to multiple vehicles. For example, the device security certificate carries multiple identification codes, and these multiple identification codes are the identification codes of multiple different vehicles, and these multiple identification codes include the identification code of the first vehicle. Based on this, a flexible security control mechanism can be provided to authorize the device security certificate to the diagnostic device according to actual needs, such as authorizing the diagnostic device to access the device security certificate of only one vehicle or authorizing the diagnostic device to access the device security certificates of multiple vehicles according to actual needs, while improving the data security and vehicle security during the data access process and flexibly controlling the permission scope of the diagnostic device.

[0041] As a possible implementation manner, the above method further includes: the diagnostic device sends a second access request to the first device, where the second access request is used to request access to the second ECU on the first vehicle, and the second access request carries the second information and the identifier of the second ECU. Exemplarily, the first ECU is different from the second ECU, and the second information is different from the first information. Exemplarily, the second ECU is different from the first ECU, and the second information is the same as the first information; based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access a vehicle, more stringent security control can be provided when the diagnostic device accesses the vehicle, while improving the data security and vehicle security during the data access process and avoiding the impact on the security of other vehicles after the first information of one vehicle is obtained by a third party; or, the second ECU is different from the first ECU, and the second information is different from the first information; based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access an ECU of a vehicle, more stringent security control can be provided when the diagnostic device accesses the ECU in the vehicle, while improving the data security and vehicle security during the data access process and avoiding the impact on the security of other ECUs after the first information of one ECU is obtained by a third party.

[0042] As a possible implementation, the above method further includes: the diagnostic device sending a request message for accessing a second vehicle to the server; the diagnostic device receiving fifth information from the server, where the fifth information is used to indicate a legal binding relationship between the diagnostic device and the second vehicle, and the fifth information is different from the first information; the diagnostic device sending a third access request to a second device on the second vehicle, where the third access request is used to request access to the second vehicle, and the fifth information is carried in the third access request. Based on this, through an authorization mechanism that authorizes one piece of information for a diagnostic device to access one vehicle, more stringent security control can be provided when the diagnostic device accesses the vehicle. While improving data security and vehicle security during the data access process, it can avoid the impact on the security of other vehicles after the first information for one vehicle is obtained by a third party.

[0043] In a third aspect, a security access method is provided. This method can be applied to a server and includes: the server receiving a request message for accessing a first vehicle from a first diagnostic device; the server sending first information to the first diagnostic device, where the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle.

[0044] For the solution provided in the above third aspect, when the diagnostic device needs to access a certain ECU (such as the first ECU) on a certain vehicle (such as the first vehicle), the server can send the first information indicating the legal binding relationship between the diagnostic device and the vehicle to the diagnostic device, so that the diagnostic device can carry the first information when sending an access request to the first device in the vehicle. Based on this, it can facilitate the first device to perform more targeted security verification on the diagnostic device's access to the ECU, and can improve data security and vehicle security during the data access process. In addition, since the first information is used to indicate the legal binding relationship between the diagnostic device and the first vehicle, even if the first information is obtained by a third party, the third party's use of the first information to access other vehicles will not be verified and passed, so it will not pose a security risk to other vehicles.

[0045] As a possible implementation manner, the above first information is the information encrypted based on the first encryption method, and the first information is directly carried when the first diagnostic device sends an access request to the first vehicle; the method further includes: the server sends a first decryption method to the first device on the first vehicle, where the first decryption method corresponds to the first encryption method, and the first decryption method is used for the first device to decrypt the first information when receiving the first information encrypted based on the first encryption method; the server sends fourth information to the first diagnostic device, where the fourth information is a temporary key encrypted based on the second encryption method; the server sends a second decryption method to the first diagnostic device, where the second decryption method corresponds to the second encryption method, and the second decryption method is used for the first diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method to obtain the temporary key therein, where the temporary key obtained by decrypting the fourth information is used to participate in the security verification when the first diagnostic device accesses the first vehicle. Based on this, the security during the transmission of the temporary key from the server to the diagnostic device and the security during the transmission of the temporary key to the first device can be improved.

[0046] As a possible implementation manner, the first information carried in the above first access request is used to indicate a temporary key or a device security certificate. Exemplarily, the temporary key is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the temporary key. For example, the key saved in the first device is the same as the temporary key, or the key saved in the first device and the temporary key are a public-private key pair; the device security certificate is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the device security certificate. For example, the root certificate saved in the first device has a preset corresponding relationship with the device security certificate, such as the identification information of the root certificate saved in the first device has a preset corresponding relationship with the identification information of the device security certificate. Based on this, the diagnostic device can request to access the first vehicle from the first device through different forms of the first information, so that the first device can perform reliable and accurate security verification.

[0047] In some examples, the device security certificate carried in the first access request may correspond to a vehicle. For example, the device security certificate carries an identification code, and this identification code is the identification code of the first vehicle. In some examples, the device security certificate carried in the first access request may correspond to multiple vehicles. For example, the device security certificate carries multiple identification codes, and these multiple identification codes are the identification codes of multiple different vehicles, and these multiple identification codes include the identification code of the first vehicle. Based on this, a flexible security control mechanism can be provided to authorize the device security certificate to the diagnostic device according to actual needs. For example, authorize the device security certificate that can only access one vehicle or authorize the device security certificate that can access multiple vehicles to the diagnostic device according to actual needs, while improving data security and vehicle security during the data access process, and flexibly controlling the permission scope of the diagnostic device.

[0048] As a possible implementation manner, the above method further includes: the server receives a request message for accessing a second vehicle from a second diagnostic device; the server sends third information to the second diagnostic device, where the third information is used to indicate a legal binding relationship between the second diagnostic device and the second vehicle, and the third information is different from the first information. Exemplarily, the second vehicle is different from the first vehicle, and the second diagnostic device and the first diagnostic device are the same device or different devices. Based on this, through the authorization mechanism of authorizing one piece of information for a diagnostic device to access a vehicle, more stringent security control can be provided when the diagnostic device accesses the vehicle. While improving data security and vehicle security during the data access process, the impact on the security of other vehicles caused by the first information for one vehicle being obtained by a third party can be avoided.

[0049] In a fourth aspect, a security access method is provided. This method can be applied to a first device on a first vehicle. The method includes: the first device sends a fourth access request to a first ECU according to an instruction of a first diagnostic device. The fourth access request is used to request a second security verification for the first device to access the first ECU, where a third MAC is carried in the access request, and the second security verification is based on the key of the first ECU; when the second security verification passes, a first feedback message is sent to the first diagnostic device, where the first feedback message is used to indicate that the first diagnostic device is allowed to access the first ECU.

[0050] As an example, the access request sent by the first device to the first ECU is used to request one or more of the following: reading data in the first ECU, modifying data in the first ECU, and writing data into the first ECU.

[0051] In the solution provided in the fourth aspect above, through the security isolation of the first device, it is possible to prevent the diagnostic device from obtaining the key of the ECU in the vehicle, thereby avoiding the leakage of the key of a single ECU. For example, due to the isolation function of the first device, the first diagnostic device cannot obtain the key of the ECU in the first vehicle, so the risk of key leakage of the ECU in the vehicle will not occur, thereby avoiding the security impact on the ECU. Moreover, based on this solution, effective security verification can be performed on the diagnostic device's access to the target ECU, improving data security and vehicle security during the data access process.

[0052] As a possible implementation, the first device has the key of the ECU on the first vehicle, and the diagnostic device does not store the key of the ECU on the first vehicle. Based on this, through the isolation function of the first device, it is possible to avoid the impact of the diagnostic device obtaining the key of the ECU on the vehicle on the security of the ECU.

[0053] As a possible implementation, the above method further includes: the first device obtains a third MAC, where the third MAC is calculated based on the key of the first ECU (such as the first ECU KEY) and the service seed corresponding to the first ECU, and the service seed corresponding to the first ECU is obtained from the first ECU. Based on this, reliable and accurate in-vehicle security verification results can be provided.

[0054] As an example, when the second security verification passes, the first device can send a feedback message to the first diagnostic device indicating that the first diagnostic device is allowed to access the first ECU, or when the second security verification fails, the first device can send a feedback message to the first diagnostic device indicating that the first vehicle does not allow the first diagnostic device to access the first ECU.

[0055] As an example, the service seed corresponding to the above first ECU is obtained by the first device from the first ECU.

[0056] As an example, one ECU on the first vehicle corresponds to one ECU KEY, and the service seed corresponding to the first ECU (such as the 27 service seed) can be a randomly generated temporary service seed.

[0057] It should be noted that the solution provided in this application can be applied to a variety of different device / product forms.

[0058] For example, in some examples, the first device can have a diagnostic proxy service and a key management service. In this case, the first device can call the key management service to obtain the stored key of the first ECU, and calculate the third MAC based on the key of the first ECU and the service seed corresponding to the first ECU. Exemplarily, the first device can be a chip with a diagnostic proxy service and a key management service.

[0059] For another example, in some examples, the first device does not have a key management service. In this case, the first device can send the service seed corresponding to the first ECU to a module for providing a key management service, such as a key management module, etc. The key management module can obtain the stored key of the first ECU and calculate a third MAC based on the key of the first ECU and the service seed corresponding to the first ECU, and then send it to the first device. Exemplarily, the first device can be a chip with a diagnostic proxy service, and the key management module can be a chip with a key management service.

[0060] As a possible implementation manner, before the first device sends a fourth access request to the first ECU, the above method further includes: the first device receives a first access request from a first diagnostic device for requesting to access the first ECU on the first vehicle, where the first access request carries first information and an identifier of the first ECU, and the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; the first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information. Based on this, through the in-vehicle and out-of-vehicle security verification isolation mechanism of the first device, not only can more effective security verification be performed on the diagnostic device to access the target ECU, but also the leakage of the key of a single ECU can be avoided. For example, due to the isolation function of the first device, the first diagnostic device cannot obtain the key of the ECU in the first vehicle, so the risk of leakage of the key of the ECU in the vehicle will not occur, thereby avoiding the security impact on the ECU.

[0061] As an example, when both the first security verification and the second security verification are passed, the first device can unlock the first ECU and send a feedback message to the first diagnostic device to indicate that the first diagnostic device is allowed to access the first ECU.

[0062] In some examples, when the first security verification fails, the first device can send a feedback message to the first diagnostic device to indicate that the first vehicle does not allow the first diagnostic device to access the first ECU.

[0063] As a possible implementation, the above first information is the information encrypted based on the first encryption method. The above first information is used to indicate the temporary key. The above first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information, including: the first device decrypts the first information according to the first decryption method to obtain the temporary key, where the first decryption method is indicated by the server and the first decryption method corresponds to the first encryption method; the first device verifies the temporary key based on the symmetric key authentication algorithm to perform the first security verification on the first diagnostic device. It can be understood that the temporary key usually has a valid duration. Therefore, when the diagnostic device needs to access the first ECU on the first vehicle, it can send the temporary key indicating the legal binding relationship between the diagnostic device and the vehicle to the first device, which can improve the data security and vehicle security during the data access process while reducing the impact on the security of the first vehicle after the temporary key is obtained by a third party. For example, when a third party maliciously accesses the first vehicle using the obtained temporary key, the temporary key is very likely to have expired, so it will not affect the security of the first vehicle. In addition, since the first information is the encrypted temporary key, it can also improve the security during the transmission of the temporary key from the first diagnostic device to the first device.

[0064] Among them, in this implementation, the fact that the temporary key is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the temporary key. For example, the key saved in the first device is the same as the temporary key, or the key saved in the first device and the temporary key are a public-private key pair.

[0065] As an example, the encryption method indicated by the above server may include, but is not limited to, the Prek encryption method.

[0066] As a possible implementation, the above temporary key is the 27 service key. The first device verifies the temporary key based on the symmetric key authentication algorithm, including: the first device obtains the 27 service seed from the first ECU according to the 27 service key and sends the 27 service seed to the first diagnostic device; the first device calculates the first MAC according to the 27 service key and the 27 service seed; the first device receives the second MAC calculated by the first diagnostic device according to the 27 service key and the 27 service seed; the first device verifies whether the second MAC is the same as the first MAC. For example, if the second MAC is the same as the first MAC, the first device passes the first security verification on the first diagnostic device; if the second MAC is different from the first MAC, the first device passes the first security verification on the first diagnostic device. Based on this, reliable and accurate security verification results can be provided.

[0067] As a possible implementation, the first information carried in the above first access request is a device security certificate, and the first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information, including: the first device verifies the legality of the device security certificate; when the device security certificate is legal, the first device verifies whether the identification code carried in the device security certificate is consistent with the identification code of the first vehicle (such as the vehicle identification number (VIN)) to perform the first security verification on the first diagnostic device. Exemplarily, the device security certificate may include, but is not limited to, a 29 service certificate. Based on this, reliable and accurate security verification results can be provided.

[0068] Among them, in this implementation, the device security certificate is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine to allow the first diagnostic device to access the first vehicle based on the device security certificate. For example, there is a preset correspondence between the root certificate saved in the first device and the device security certificate, such as a preset correspondence between the identification information of the root certificate saved in the first device and the identification information of the device security certificate.

[0069] In some examples, the device security certificate carried in the first access request may correspond to one vehicle. For example, the device security certificate carries one identification code, and this one identification code is the identification code of the first vehicle. In some examples, the device security certificate carried in the first access request may correspond to multiple vehicles. For example, the device security certificate carries multiple identification codes, and these multiple identification codes are the identification codes of multiple different vehicles, and these multiple identification codes include the identification code of the first vehicle. Based on this, a flexible security control mechanism can be provided to authorize the device security certificate to the diagnostic device according to actual needs, such as authorizing the diagnostic device with a device security certificate that can only access one vehicle or authorizing a device security certificate that can access multiple vehicles according to actual needs, while improving data security and vehicle security during the data access process and flexibly controlling the permission range of the diagnostic device.

[0070] As a possible implementation, the above method further includes: First, the first device receives a second access request from the first diagnostic device, where the second access request carries second information and an identifier of the second ECU. The second access request is used to request access to the second ECU on the first vehicle, and the second information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle. Then, the first device performs a first security verification on the permission of the first diagnostic device to access the first vehicle based on the second information. After that, when the first security verification passes, the first device requests the second ECU to perform a second security verification for the first device to access the second ECU based on the key of the second ECU, where the key of the second ECU is invisible to the first diagnostic device. Finally, when the second security verification passes, the first device sends a feedback message to the first diagnostic device to indicate that the first diagnostic device is allowed to access the second ECU. Exemplarily, the second ECU is different from the first ECU, and the second information is the same as the first information. Based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access a vehicle, more strict security control can be provided when the diagnostic device accesses the vehicle, while improving data security and vehicle security during the data access process, and avoiding the impact on the security of other vehicles after the first information of a vehicle is obtained by a third party; or, the second ECU is different from the first ECU, and the second information is different from the first information. Based on this, through the authorization mechanism of authorizing an information for a diagnostic device to access an ECU in a vehicle, more strict security control can be provided when the diagnostic device accesses the ECU in the vehicle, while improving data security and vehicle security during the data access process, and avoiding the impact on the security of other ECUs after the first information of an ECU is obtained by a third party.

[0071] As a possible implementation, the above method further includes: First, the first device receives a third access request from a second diagnostic device, where the third access request carries third information and an identifier of a third ECU. The third access request is used to request access to the third ECU on the first vehicle, and the third information is used to indicate a legal binding relationship between the second diagnostic device and the first vehicle. Then, the first device performs a first security verification on the permission of the second diagnostic device to access the first vehicle based on the third information. After that, when the first security verification passes, the first device requests the third ECU to perform a second security verification for the first device to access the third ECU based on the key of the third ECU, where the key of the third ECU is invisible to the second diagnostic device. Finally, when the second security verification passes, the first device sends a feedback message to the second diagnostic device to indicate that the second diagnostic device is allowed to access the third ECU. Based on this, through an authorization mechanism that authorizes a piece of information for a diagnostic device to access a vehicle, more stringent security control can be provided when a diagnostic device accesses a vehicle. While improving data security and vehicle security during the data access process, it can avoid the impact on the security of other vehicles when the first information of a vehicle is obtained by a third party.

[0072] In a fifth aspect, a device is provided. The device includes: a memory for storing computer program instructions and data; a processor for executing the computer program instructions to support the device in implementing the method described in any possible implementation manner of the first aspect or the fourth aspect.

[0073] In a sixth aspect, a diagnostic device is provided. The diagnostic device includes: a memory for storing computer program instructions and data; a processor for executing the computer program instructions to support the diagnostic device in implementing the method described in any possible implementation manner of the second aspect.

[0074] In a seventh aspect, a server is provided. The server includes: a memory for storing computer program instructions and data; a processor for executing the computer program instructions to support the server in implementing the method described in any possible implementation manner of the third aspect.

[0075] In an eighth aspect, a security verification system is provided. The security verification system includes the device described in the fifth aspect and the server described in the seventh aspect.

[0076] In a ninth aspect, a vehicle, or another means of transportation, may include the device described in the fifth aspect and one or more ECUs to implement the method described in any possible implementation manner of the first aspect or the third aspect.

[0077] In a tenth aspect, there is provided a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method in any possible implementation manner of the first aspect, the second aspect, the third aspect or the fourth aspect is implemented.

[0078] In an eleventh aspect, there is provided a computer program product containing instructions. When the computer program product runs on a computer, the computer is enabled to implement the method in any possible implementation manner of the first aspect, the second aspect, the third aspect or the fourth aspect.

[0079] In a twelfth aspect, there is provided a chip system, which includes a processing circuit and a storage medium. Computer program instructions are stored in the storage medium; when the computer program instructions are executed by the processor, the method in any possible implementation manner of the first aspect, the second aspect, the third aspect or the fourth aspect is implemented. The chip system may be composed of chips, or may include chips and other discrete devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Figure 1 It is a schematic diagram of a conventional security verification method;

[0081] Figure 2 It is a schematic diagram of a security verification method in another conventional security access process;

[0082] Figure 3 It is a schematic diagram of the result of a conventional diagnostic device obtaining a key;

[0083] Figure 4 It is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0084] Figure 5 It is a schematic diagram of a security access process provided by an embodiment of the present application Figure 1 ;

[0085] Figure 6 It is a schematic diagram of a security access process provided by an embodiment of the present application Figure 2 ;

[0086] Figure 7 It is a schematic diagram of a security access process provided by an embodiment of the present application Figure 3 ;

[0087] Figure 8 It is a flowchart of a security access method provided by an embodiment of the present application Figure 1 ;

[0088] Figure 9 It is a schematic diagram of the security access effect of a diagnostic device provided by an embodiment of the present application Figure 1 ;

[0089] Figure 10 Example of the secure access process provided by the embodiments of the present application Figure 1 ;

[0090] Figure 11 Schematic diagram of the secure access effect of the diagnostic device provided by the embodiments of the present application Figure 2 ;

[0091] Figure 12 Interaction during the secure access process provided by the embodiments of the present application Figure 1 ;

[0092] Figure 13 Example of the secure access process provided by the embodiments of the present application Figure 2 ;

[0093] Figure 14 Schematic diagram of the secure access effect of the diagnostic device provided by the embodiments of the present application Figure 3 ;

[0094] Figure 15 Interaction during the secure access process provided by the embodiments of the present application Figure 2 ;

[0095] Figure 16 Schematic diagram of the secure access process provided by the embodiments of the present application Figure 4 ;

[0096] Figure 17 Flow chart of the secure access method provided by the embodiments of the present application Figure 2 ;

[0097] Figure 18 Interaction during the secure access process provided by the embodiments of the present application Figure 3 ;

[0098] Figure 19 Interaction during the secure access process provided by the embodiments of the present application Figure 4 ;

[0099] Figure 20 Schematic diagram of the secure access process provided by the embodiments of the present application Figure 5 ;

[0100] Figure 21 Flow chart of the secure access method provided by the embodiments of the present application Figure 3 ;

[0101] Figure 22 Interaction during the secure access process provided by the embodiments of the present application Figure 5 ;

[0102] Figure 23 Block diagram of a diagnostic device / server / first device provided by the embodiments of the present application. Specific Embodiments

[0103] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B may mean A or B. The "and / or" herein is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality of" means two or more than two.

[0104] Hereinafter, terms such as "first" and "second" are only used to distinguish different described objects, and do not limit the position, order, priority, quantity, or content of the described objects. For example, if the described object is "field", the ordinal numbers before "field" in "the first field" and "the second field" do not limit the position or order between the "fields". "First" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of "the first field" and "the second field". For another example, if the described object is "level", the ordinal numbers before "level" in "the first level" and "the second level" do not limit the priority between the "levels". For another example, the quantity of the described object is not limited by the ordinal number and can be one or more. Taking "the first device" as an example, the quantity of "device" can be one or more. In addition, the objects modified by different prefixes can be the same or different. For example, if the described object is "device", "the first device" and "the second device" can be devices of the same type or different types. For another example, if the described object is "information", "the first information" and "the second information" can be information of the same content or different content. In short, the use of ordinal numbers and other prefixes for distinguishing described objects in the embodiments of the present application does not constitute a limitation on the described objects. The statements of the described objects refer to the description in the claims or the context of the embodiments, and should not constitute an unnecessary limitation due to the use of such prefixes.

[0105] In addition, in the embodiments of the present application, "connection" can be a direct connection or an indirect connection; in addition, it can refer to an electrical connection or a communication connection. For example, when two electrical components A and B are connected, it can mean that A is directly connected to B, or it can mean that A and B are indirectly connected through other electrical components or connection media, or it can mean that A and B are indirectly connected through other communication devices or communication media, as long as communication can be carried out between A and B.

[0106] As we know, in the field of intelligent vehicles, whether before the vehicle leaves the factory or during the vehicle owner's use of the vehicle after it leaves the factory, diagnostic devices (such as diagnostic instruments) can perform operations such as reading, writing, or modifying in-vehicle components through diagnostic interfaces such as on-board diagnostics (OBD), and are widely used for vehicle problem diagnosis, problem repair, software upgrade, etc. As one of the only few externally exposed interfaces of the vehicle, OBD usually has relatively high privileges because it carries high-level functions such as querying the status of vehicle components, reading and writing configuration words, querying and clearing fault codes, code modification, and software flashing. Moreover, since there is an authentication mechanism set among the various ECUs inside the vehicle, and this authentication mechanism requires the various ECUs to interact based on keys, a large number of keys are usually encapsulated in the vehicle. These keys may not only involve the keys pre-set by the chip manufacturer, device supplier, and original equipment manufacturer before the vehicle leaves the factory, but also the owner keys set by the vehicle owner in the vehicle during the use of the vehicle. To sum up, once the OBD is maliciously breached, it will pose a great security risk to the vehicle. For example, after the OBD is maliciously breached by a third party, the third party can access each ECU based on the keys of each ECU encapsulated in the vehicle, or since the keys of the same type of ECU are usually the same, the third party can obtain the keys of the ECUs encapsulated in the vehicle and access the same type of ECUs in other vehicles based on these keys. All in all, the conventional authentication mechanism will pose security hazards not only to the vehicle to be accessed but also to other vehicles.

[0107] To improve the data security and vehicle security during the process of the diagnostic device accessing the vehicle, in some embodiments, the vehicle can perform security verification on the diagnostic device based on security protocols such as the transport layer security (TLS) protocol, such as performing security verification between the vehicle and the diagnostic device, and between the vehicle and the security service platform. Among them, as Figure 1 shown, the TLS protocol mainly stipulates the authentication and key negotiation required for establishing or resuming a secure session, and the encryption of information (including but not limited to symmetric encryption, asymmetric encryption, etc.). In some embodiments, the TLS protocol can also stipulate the integrity protection of information (such as hash algorithm integrity protection, etc.) and integrity verification, etc. When establishing a secure session, the TLS protocol will manage the following contents: key negotiation, authentication of the server and the client, exchange of session key information, etc. Among them, key negotiation refers to the negotiation between the server and the client of the key used during the entire message interaction process, the authentication of the server and the client such as the server proving its identity to the client, and the exchange of session key information such as the client and the server exchanging random numbers and a special number called the pre-master key.

[0108] However, in this embodiment, only based on the TLS protocol, there is no protection mechanism for the secure access control of the in-vehicle ECU.

[0109] In some other embodiments, the vehicle can perform a security verification on an off-vehicle diagnostic device based on the 27 security access service, and allow it to access the target ECU when the security verification is passed. Among them, the 27 security access service is a service that provides a protection mechanism through a 27 service seed and a key. For example, as Figure 2 shown, when the diagnostic device wants to access the target ECU, the diagnostic device can request a 27 service seed from the target ECU. The target ECU can generate a 27 service seed (such as based on an algorithm such as a random generation algorithm) and send it to the diagnostic device; afterwards, the diagnostic device and the target ECU can respectively calculate a key based on the security algorithm according to the 27 service seed. The target ECU can perform a security verification on the access request of the diagnostic device by comparing the key (such as key B) calculated by it with the key (such as key A) calculated by the diagnostic device. For example, when the two are the same, the security verification of the diagnostic device is passed, and when the two are different, the security verification of the diagnostic device fails.

[0110] However, in this embodiment, as Figure 3 shown, the diagnostic device stores the keys of all ECUs it has accessed. The keys of the same type of ECU in a vehicle model (such as the 27 service key) are usually the same. Therefore, if the 27 service seed or key (such as Figure 3 shown TBOX_KEY, MDC_KEY, VDC_KEY, VIU_KEY, CDC_KEY...) of the target ECU in a vehicle model obtained by the diagnostic device is leaked, it may affect the entire vehicle model; in addition, in this embodiment, the diagnostic device has the 27 service seeds or keys of various types of ECUs in various vehicle models. Therefore, once the 27 service seed or key of a vehicle model is leaked, it may affect all vehicle models, and the scope of influence is very large; and, since the diagnostic device is usually used in after-sales service shops across the country, the management difficulty is very high and it is more vulnerable to malicious attacks.

[0111] To solve the above problems existing in the security verification mechanism when a conventional diagnostic device accesses an ECU, and to improve the data security and vehicle security during the process of a diagnostic device accessing a vehicle, the embodiments of the present application provide a security access method. In some embodiments, when a diagnostic device has a need to access a certain vehicle (denoted as the "target vehicle"), it can send an access request to the vehicle and carry a temporary key or a device security certificate, etc., which is used to indicate the legal binding relationship between the diagnostic device and the target vehicle, in the access request. The target vehicle can allow the diagnostic device to access the target vehicle after the security verification of the diagnostic device's access permission to the vehicle based on the temporary key or the device security certificate passes. Based on this, through the authorization management and security verification in the dimensions of the diagnostic device and the vehicle, the impact on other vehicles when one vehicle has a security hazard can be avoided.

[0112] In some embodiments, a module or device (denoted as the "first device") for isolating the diagnostic device from the ECU can be provided in the vehicle. When the diagnostic device has a need to access a certain ECU (denoted as the "target ECU") in the target vehicle, it can send an access request to the first device on the target vehicle. The first device can initiate a security verification request to the target ECU according to the indication of the diagnostic device, and allow the diagnostic device to access the target ECU on the target vehicle when the security verification of the first device by the target ECU passes, and participate in the subsequent data transmission between the diagnostic device and the target ECU as an intermediate device. Based on this, since the security verification of accessing the ECU is performed inside the vehicle, the isolation function provided by the first device can make the key of the ECU in the vehicle invisible to the diagnostic device. Therefore, the leakage of the key of the ECU in the vehicle can be avoided, and further the impact on the security of the target vehicle and other vehicles can be avoided.

[0113] In some embodiments, when the diagnostic device has a need to access the target ECU on the target vehicle, it can send an access request to the vehicle and carry a temporary key or a device security certificate, etc., which is used to indicate the legal binding relationship between the diagnostic device and the target vehicle, in the access request. The target vehicle can initiate a security verification request to the target ECU after the security verification of the diagnostic device's access permission to the vehicle based on the temporary key or the device security certificate passes, and allow the diagnostic device to access the target ECU on the target vehicle when the security verification of the first device by the target ECU passes, and participate in the subsequent data transmission between the diagnostic device and the target ECU as an intermediate device. Based on this, on the one hand, through the authorization management and the first security verification in the dimensions of the diagnostic device and the vehicle, the impact on other vehicles when one vehicle has a security hazard can be avoided; on the other hand, the isolation function provided by the first device makes the key of the ECU in the vehicle invisible to the diagnostic device. Therefore, the leakage of the key of the ECU in the vehicle can be avoided, and further the impact on the security of the target vehicle and other vehicles can be avoided.

[0114] As a possible example, please refer to Figure 4 , Figure 4 which shows a schematic diagram of a system architecture provided by an embodiment of the present application. As Figure 4 shown, the security verification system may include a diagnostic device, a security server (hereinafter referred to as "server") and a vehicle to be diagnosed (i.e., the target vehicle).

[0115] As an example, Figure 4 the diagnostic device shown may be a diagnostic instrument, a diagnostic server, or a diagnostic server cluster, etc., and the embodiments of the present application do not make specific limitations. In the embodiments of the present application, the diagnostic device may initiate a request to access the target ECU in the vehicle to be diagnosed in response to a triggered operation to access the target ECU in the vehicle to be diagnosed.

[0116] Among them, the timing for the diagnostic device to initiate a request to access the target ECU in the vehicle to be diagnosed may include but is not limited to the following stages: development stage, experimental stage, component production stage, vehicle assembly stage, end of line (EOL) stage, and after-sales stage. Among the above-mentioned stages, the after-sales stage is the stage after the vehicle leaves the factory, and the other stages are all stages before the vehicle leaves the factory. The embodiments of the present application do not limit the specific stage at which the diagnostic device initiates a request to access the target ECU in the vehicle to be diagnosed. In addition, the embodiments of the present application do not limit the specific purpose of the diagnostic device to initiate a request to access the target ECU in the vehicle to be diagnosed. For example, its purpose may include but is not limited to one or more of the following: problem diagnosis, problem repair, or software upgrade. Exemplarily, problem diagnosis such as the ability to obtain fault codes, input / output control ability diagnosis, security access function diagnosis, data acquisition function diagnosis, program control function diagnosis, and refresh function diagnosis, ECU initialization diagnosis, fault self-diagnosis when the ECU is turned off, continuous fault self-diagnosis when the ECU is turned off, etc.; problem repair such as the repair of the problems diagnosed; software upgrade such as system upgrade or function upgrade, etc., without specific limitations

[0117] Figure 4 The server shown is used to manage security authorization files, such as including but not limited to vehicle-cloud signature, authorization expiration time (such as the validity period of a temporary key or device security certificate), authorized vehicle VIN code (such as the VIN in the device security certificate), relevant function switch states, etc.

[0118] In some embodiments of the present application, the server may also be used for temporary key issuance and management. For example, the server may provide a temporary key (such as a temporary symmetric key) for accessing the vehicle to be diagnosed to the diagnostic device.

[0119] In some embodiments of the present application, the server can also be used to issue and manage device security certificates. For example, the server can provide a device security certificate for accessing the vehicle to be diagnosed to the diagnostic device.

[0120] Figure 4 One or more ECUs can be included in the vehicle to be diagnosed ( Figure 4 taking the vehicle to be diagnosed including ECU1, ECU2, and ECU3 as an example). The ECU includes, but is not limited to, one or more of the following: in-vehicle sensors, in-vehicle cameras, pre-installed intelligent gateways (such as telematics boxes (T-Boxes)), in-vehicle gateways, power distribution units (such as power distribution units (PDUs)), battery management systems (such as battery management systems (BMS)), thermal management systems, domain controllers, etc. Among them, the domain controller can be divided into several domains (also called "functional domains") according to the functions of each part of the vehicle, such as the intelligent driving domain, the cockpit domain, the chassis domain, the power domain, the body domain, etc. Based on this, the in-vehicle domain controller can include, but is not limited to, any one or more of the following: intelligent driving domain controller, cockpit domain controller, chassis domain controller, power domain controller, body domain controller, etc. The target ECU described in the embodiments of the present application can be any of the above ECUs, without specific limitation.

[0121] In the embodiments of the present application, Figure 4 the vehicle to be diagnosed can be a vehicle with a key verification function. For example, as Figure 4 shown, a module or device for providing diagnostic proxy services and key management services can be provided on the vehicle to be diagnosed, Figure 4 taking the first device providing diagnostic proxy services and key management services as an example. The diagnostic proxy services can include, but are not limited to, services such as authorization file processing services, temporary key storage and calculation services, and 27 service key proxy services. The key management services can include, but are not limited to, in-vehicle key storage and calculation services, such as storage and MAC calculation and other related calculations of keys of in-vehicle ECUs; authorization file processing services such as signature verification, authorization time verification, VIN code verification, switch execution, temporary key decryption and storage; 27 service key proxy services such as 0x27 diagnostic service filtering, symmetric key verification, in-vehicle key verification, component unlocking, etc.

[0122] In some embodiments of the present application, the first device may be connected to one or more ECUs based on the Transmission Control Protocol / Internet Protocol (TCP / IP) protocol. For example, it may communicate with one or more ECUs through DoIP (Diagnostic over IP) messages to support relevant processes such as ECU diagnosis.

[0123] In some embodiments of the present application, the first device may be connected to one or more ECUs based on the Controller Area Network (CAN) bus. For example, it may communicate with one or more ECUs through DoCAN (Diagnostic over CAN) messages to support relevant processes such as ECU diagnosis.

[0124] It should be noted that Figure 4 The architecture shown is only an example. In practical applications, the embodiments of the present application do not limit the specific modules that provide the diagnostic proxy service and the key management service. For example, the diagnostic proxy service and the key management service may also be provided by different modules. For instance, a vehicle may include a diagnostic proxy module (i.e., the first device) and a key management module, where the diagnostic proxy module is used to provide the diagnostic proxy service and the key management module is used to provide the key management service. Another example is that the diagnostic proxy service or the key management service may be provided by other modules different from the diagnostic proxy module, and no specific limitations are made.

[0125] In addition, in practical applications, the embodiments of the present application do not limit the specific structure of the modules that provide the diagnostic proxy service and the key management service. For example, the modules that provide the diagnostic proxy service and the key management service may be a hardware module, a component, or a device, or may also be a chip, etc.

[0126] In an embodiment of the present application, the diagnostic agent module may initiate a request to access a target ECU in a vehicle to be diagnosed based on a wired connection (such as a diagnostic line) or a wireless connection with the diagnostic interface of the vehicle to be diagnosed. The diagnostic interface may be a unified diagnostic services (UDS) interface, an onboard diagnostics (OBD) interface, or other interfaces capable of implementing command transmission functions, without limitation. When vehicle diagnosis is implemented wirelessly, the diagnostic device and the vehicle to be diagnosed may have near-field communication functions such as Bluetooth or a wireless local area network (WLAN). The diagnostician may 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 a diagnostic command on the diagnostic device so that the diagnostic command is transmitted to the vehicle to be diagnosed wirelessly. In some examples, a display screen may also be provided on the diagnostic device. After obtaining the diagnostic result, the diagnostic device may also display the diagnostic result to the diagnostician through the display screen to facilitate reminding the diagnostician to view the diagnostic result in a timely manner, thereby quickly identifying the location and cause of the fault, etc.

[0127] It should be understood that this application Figure 4 Only as an example, 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 may only interact with one vehicle to be diagnosed, or may interact with multiple vehicles to be diagnosed. Moreover, one vehicle to be diagnosed may interact with multiple diagnostic devices. And, in the system architecture applicable to the embodiment of the present application, in addition to including Figure 4 the vehicle to be diagnosed, the diagnostic device, and the server shown, other devices may also be included, such as supplier devices, manufacturer devices, production line devices, and sales devices, etc., and the embodiment of the present application also does not limit this. And, the diagnostic device described in the embodiment of the present application may integrate all functions on an independent physical device, or may distribute the functions on multiple independent physical devices, and the embodiment of the present application also does not limit this.

[0128] It should be noted that the secure access method described in the embodiments of the present application can be applied to the intelligent driving field, such as vehicle-to-everything (V2X), long term evolution-vehicle (LTE-V), vehicle-to-vehicle (V2V), etc. For example, it can be applied to vehicles with key verification functions, or other devices with key verification functions in vehicles, such as in-vehicle terminals, in-vehicle controllers, in-vehicle modules, in-vehicle components, in-vehicle chips, in-vehicle units, in-vehicle radars, or in-vehicle cameras and other sensors. Of course, the secure access method in the embodiments of the present application can also be used for other intelligent terminals with key verification functions other than vehicles, or be set in other intelligent terminals with key verification functions other than vehicles, or be set in the components of the intelligent terminal. The intelligent terminal may include, but is not limited to, intelligent transportation devices, smart home devices, robots, etc. For example, it includes, but is not limited to, intelligent terminals or other sensors such as controllers, chips, radars, or cameras in the intelligent terminal, as well as other components. The following embodiments will take the intelligent driving field as an example for relevant introduction.

[0129] The following will take three specific embodiments (such as Embodiment 1, Embodiment 2, and Embodiment 3) as examples, with the first device for providing diagnostic proxy services included in the target vehicle, to specifically introduce a secure access method provided by the embodiments of the present application.

[0130] Embodiment 1:

[0131] In Embodiment 1, when receiving an access request from a diagnostic device to access a target ECU in a target vehicle, the first device on the target vehicle performs a first security verification between the first device and the diagnostic device according to the first information carried in the access request. After the first security verification passes, it requests the target ECU to perform a second security verification between the target ECU and the first device. When the second security verification passes, it allows the diagnostic device to access the target ECU on the target vehicle and participates in the subsequent data transmission between the diagnostic device and the target ECU as an intermediate device. Among them, the first information can be used to indicate the legal binding relationship between the diagnostic device and the target vehicle. For example, the first information may include, but is not limited to, a temporary key and a device security certificate. As an example, the first information is information obtained by the diagnostic device from the server for security verification.

[0132] As an example, please refer to Figure 5 , Figure 5 Taking Figure 4 the diagnostic device in the intelligent driving field under the shown system architecture accessing the target ECU in the vehicle as an example, a schematic diagram of a secure access process provided by the embodiments of the present application is shown. AsFigure 5 As shown, when the diagnostic device needs to access the target ECU in the vehicle, the first device on the vehicle can perform the first security verification between the first device and the diagnostic device, and the first security verification can be performed based on the first information sent by the server to the diagnostic device during this process; after the first security verification passes, the target ECU can perform the second security verification between the target ECU and the first device; after the second security verification passes, the first device can unlock the target ECU; after that, the diagnostic device can successfully access the target ECU.

[0133] In some embodiments, when the first device performs the first security verification between the first device and the diagnostic device, the first device can be based on Figure 6 the symmetric key authentication algorithm shown to perform the above-mentioned first security verification, or can be based on Figure 7 the asymmetric key authentication algorithm shown to perform the above-mentioned first security verification, or can also be based on other security authentication algorithms to perform the above-mentioned first security verification, which is not specifically limited in the embodiments of the present application.

[0134] In some embodiments, when the target ECU performs the second security verification between the target ECU and the first device, the target ECU can be based on Figure 6 or Figure 7 the symmetric key authentication algorithm shown to perform the above-mentioned second security verification, or can also be based on other security authentication algorithms to perform the above-mentioned second security verification, which is not specifically limited in the embodiments of the present application.

[0135] Among them, the symmetric key authentication algorithm means using the same key for decryption as for encryption, and both the sender and the receiver know the key and the encryption and decryption algorithms in advance and the key is the same. The asymmetric key authentication algorithm means using a different key for decryption than for encryption, such as two keys, a public key and a private key, can be used in combination for encryption and decryption; for example, the sender and the receiver can negotiate a set of keys in advance and send their respective public keys to each other. When the sender sends data to the receiver, the data can be encrypted using the receiver's public key and then sent to the receiver. Correspondingly, the receiver uses its own private key to decrypt the data encrypted with the public key received to obtain the data.

[0136] Please refer to Figure 8 , Figure 8 which shows a flowchart of a security access method provided by the embodiments of the present application. As Figure 8 shown, a security access method provided by the embodiments of the present application can be implemented based on Figure 8 S801-S808 shown as follows:

[0137] S801: The diagnostic device responds to a trigger event for accessing the target ECU in the target vehicle and sends a request message to the server.

[0138] Exemplarily, the request message sent by the diagnostic device (such as the first diagnostic device) to the server may be a request message for accessing the vehicle (i.e., the target vehicle, such as the first vehicle) where the target ECU (such as the first ECU) is located.

[0139] As an example, the triggering event for accessing the target ECU may be an operation triggered manually, such as an operation triggered by a diagnostician, or an event automatically triggered by the diagnostic device when a preset triggering condition is met. The embodiments of the present application do not make specific limitations.

[0140] Among them, in the embodiments of the present application, the diagnostic device may be a device outside the vehicle. For example, it may be other devices independent of the original equipment manufacturer (OEM) and supplier devices, or it may be a part of the OEM device or a part of the supplier device. Specific limitations are not made.

[0141] As an example, the timing when the diagnostic device described in the embodiments of the present application sends a request message to the server in response to the triggering event for accessing the target ECU may be before the vehicle leaves the factory or after the vehicle leaves the factory. Specific limitations are not made.

[0142] As an example, the purpose of accessing the target ECU may be used for but not limited to problem diagnosis, problem repair, or software upgrade of the target ECU. For example, the diagnostic device may perform problem diagnosis on the target ECU by reading the data in the target ECU in response to the operation of accessing the target ECU, and perform problem repair or software upgrade on the target ECU by modifying the data in the target ECU and / or writing data to the target ECU.

[0143] As an example, the problem diagnosis described in the embodiments of the present application may include but not limited to ability diagnosis for obtaining fault codes, input / output control ability diagnosis, security access function diagnosis, data acquisition function diagnosis, program control function diagnosis, and refresh function diagnosis, initialization diagnosis of the ECU, fault self-diagnosis when the ECU is turned off, continuous fault self-diagnosis when the ECU is turned off, etc.; problem repair may include but not limited to repair of the problems diagnosed; software upgrade may include but not limited to system upgrade or function upgrade, etc. Specific limitations are not made.

[0144] S802: The server sends the first information to the diagnostic device according to the request message.

[0145] In the embodiments of the present application, the first information is used for the target vehicle to perform security verification on the diagnostic device. For example, when the diagnostic device requests to access the target ECU, the first device on the target vehicle performs the first security verification between the first device and the diagnostic device. The essence of the first security verification is an off-vehicle security verification. Through the first security verification, it can be determined whether the diagnostic device can legally access the target vehicle.

[0146] As an example, the first information can be used to indicate the legal binding relationship between the diagnostic device and the target vehicle. For example, based on the first information, the first device can determine to allow the diagnostic device to access the target vehicle.

[0147] In some embodiments, the first information can be used to indicate a temporary key, such as a temporary symmetric key. It can be understood that compared with conventional security keys such as long-term keys, due to the temporariness of the temporary key (such as it will expire after a certain period of time), the security impact caused by the leakage of conventional security keys such as long-term keys to the control module can be solved. Based on this, considering the risk of key leakage, the server can improve the data security and vehicle security during the process of the diagnostic device accessing the control module by allocating a temporary key to the diagnostic device.

[0148] As an example, the temporary key can correspond to an applicable range and a valid duration. For example, the applicable range corresponding to the temporary key can be configured by the server according to the target ECU to be accessed by the diagnostic device. For example, the applicable range of the temporary key can be the target ECU or the target vehicle where the target ECU is located. The valid duration corresponding to the temporary key can be configured by the server according to actual situations such as the security control level and priority. For example, the valid duration can be 12 hours, 24 hours, etc., without specific limitation.

[0149] As an example, the first information can be a 27 service key. Of course, the embodiments of the present application do not make specific limitations on the specific key type of the temporary key.

[0150] In some embodiments, the first information can be a device security certificate. It can be understood that compared with conventional security keys such as long-term keys, the method of presetting the root certificate of the diagnostic device can facilitate the server to manage the permissions of a group of diagnostic devices to access the ECU / vehicle, so as to provide more fine-grained security control during the data access process. Therefore, the security risks caused by the leakage of conventional security keys such as long-term keys can be solved. In addition, the solution of the server managing the permissions of the diagnostic device to access the ECU / vehicle by presetting the root certificate of the diagnostic device can also achieve faster and more secure authorization information distribution, and can be applied to a wider range of scenarios, such as low-end devices or components without a symmetric system such as BMS and electric power steering (EPS) systems, and applicable to 29 authentication service standards, etc.

[0151] As an example, the device security certificate may correspond to a scope of application and a valid duration. For example, the scope of application corresponding to the device security certificate may be configured by the server according to the target ECU to be accessed by the diagnostic device. For example, the scope of adaptation of the device security certificate may be the target ECU or the target vehicle where the target ECU is located. The valid duration corresponding to the device security certificate may be configured by the server according to actual situations such as the security control level and priority. For example, the valid duration may be 12 hours, 24 hours, etc., without specific limitation.

[0152] Of course, the first information may also be other information for security verification provided by the server to the diagnostic device, and the embodiments of the present application do not make specific limitations.

[0153] In some embodiments, the first information sent by the server to the diagnostic device may be the first information encrypted, such as the first information encrypted by the first encryption method. The first information encrypted by the first encryption method is used to be directly carried in the access request when the diagnostic device sends an access request to the target vehicle, so as to prevent the temporary key or device security certificate indicated by the first information from being maliciously tampered with. At the same time, the server sends the first decryption method to the target vehicle, where the first decryption method corresponds to the first encryption method, and the first decryption method is used for the target vehicle to decrypt the first information when receiving the first information encrypted based on the first encryption method; and, the server sends the fourth information encrypted based on the second encryption method to the diagnostic device, and sends the second decryption method corresponding to the second encryption method to the diagnostic device, which is used for the diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method, where the information obtained by decrypting the fourth information (such as the temporary key) is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle.

[0154] Exemplarily, the first encryption method is, for example, the Prek encryption method, and the second encryption method is, for example, the PK encryption method.

[0155] S803: The diagnostic device sends an access request to the first device on the target vehicle, and the access request carries the first information.

[0156] Among them, the access request carries the identifier of the target ECU on the target vehicle, and the access request is used to request access to the target ECU on the target vehicle; the purpose of the diagnostic device requesting to access the target ECU may include but is not limited to reading data in the target ECU, modifying data in the target ECU, writing data into the target ECU, etc.

[0157] In some embodiments, the first information received by the diagnostic device from the server is encrypted first information, such as the first information encrypted by the first encryption method. The diagnostic device can carry the first information encrypted by the first encryption method in the access request and send it to the first device. Generally, if the first information received by the diagnostic device from the server is the first information encrypted by the first encryption method, the diagnostic device will also receive the fourth information from the server, where the fourth information is the same as the information indicated by the first information (such as the temporary key). The fourth information is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle. The difference between the fourth information and the first information is that the first information is encrypted by the first encryption method.

[0158] In some embodiments, the fourth information received by the diagnostic device from the server is encrypted, such as encrypted by the second encryption method. For this case, the diagnostic device can decrypt the fourth information according to the second decryption method corresponding to the second encryption method indicated by the server to obtain the information therein, such as the temporary key.

[0159] S804: The first device performs the first security verification between the first device and the diagnostic device based on the first information.

[0160] Among them, the first security verification is a preliminary verification of the permissions of the diagnostic device, such as verifying the permissions of the diagnostic device to access the target vehicle. By passing the first security verification, it can be determined whether the diagnostic device can legally access the target vehicle.

[0161] In some embodiments, the first device can perform the first security verification between the first device and the diagnostic device based on the first information according to the symmetric key authentication algorithm. For example, assume that the first information carried in the access request is a temporary symmetric key, such as the 27 service key. Then the first device can verify the temporary symmetric key according to the symmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0162] As an example, the symmetric key authentication algorithm described in the embodiments of the present application may include, but is not limited to, any one of the following: Advanced Encryption Standard (AES) algorithm, Data Encryption Standard (DES) algorithm, Triple DES (3DES) algorithm, etc. Exemplarily, the AES algorithm includes, for example, AES-Cipher-based Message Authentication Code (AES-CMAC) algorithm, AES-Cipher Block Chaining (AES-CBC) algorithm, AES-GMAC CTR mode (AES-GCM) algorithm, etc.

[0163] In some embodiments, the access request is used to access a target ECU in a target vehicle. For this case, when verifying the temporary symmetric key according to the symmetric key authentication algorithm, as a possible implementation, the first device may obtain a service seed (such as a 27 service seed) from the target ECU according to the identifier of the target ECU carried in the access request, and send the service seed to the diagnostic device; then, the first device may calculate a first MAC according to the service key and the service seed, and receive a second MAC calculated by the diagnostic device according to the service key and the service seed; finally, the first device verifies the temporary symmetric key by verifying whether the second MAC is the same as the first MAC.

[0164] As an example, the service seed (such as a 27 service seed) may be a temporary service seed randomly generated by the target ECU, such as a temporary service seed generated based on an algorithm such as a random generation algorithm.

[0165] In some embodiments, the first device may perform a first security verification between the first device and the diagnostic device based on the first information according to the asymmetric key authentication algorithm. For example, assuming that the first information carried in the access request is a device security certificate, such as a 29 service certificate, the first device may verify the device security certificate according to the asymmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0166] As an example, the asymmetric key authentication algorithm described in the embodiments of the present application may include, but is not limited to, any one of the following: RSA algorithm, Digital Signature Arithmetic (DSA), Elliptic Curve Cryptography (ECC) algorithm, etc.

[0167] When verifying the device security certificate according to the asymmetric key authentication algorithm, as a possible implementation, the first device may first verify the legitimacy of the device security certificate (such as the 29 service certificate). When the legitimacy verification passes (such as the device security certificate is legitimate), it verifies whether the identification code carried in the device security certificate is consistent with the vehicle identification code in the root certificate saved in the first device. For example, when the identification code (such as VIN) carried in the device security certificate includes the vehicle identification code (such as VIN) in the root certificate, the first device may determine that the device security certificate verification passes, that is, the first security verification passes; when the identification code carried in the device security certificate does not include the vehicle identification code in the root certificate, the first device may determine that the device security certificate verification fails, that is, the first security verification fails.

[0168] S805: When the first security verification passes, the first device obtains the third MAC calculated based on the service seed corresponding to the target ECU and the key of the stored target ECU.

[0169] In some embodiments, the first device may provide a diagnostic proxy service and a key management service. For this case, the first device may call the key management service to obtain the key of the stored target ECU (such as the target ECU KEY), and then calculate the third MAC according to the key of the target ECU and the service seed corresponding to the target ECU (such as the 27 service seed).

[0170] In other embodiments, the first device does not provide a key management service, and the key management service is provided by other modules or devices, such as provided by a key management module. For this case, the first device may send the service seed corresponding to the target ECU to the key management module and request the key management module to perform MAC calculation; the key management module may call the key management service to obtain the key of the stored target ECU (such as the target ECU KEY), calculate the third MAC according to the key of the target ECU and the service seed corresponding to the target ECU (such as the 27 service seed), and then send the third MAC to the first device.

[0171] Among them, the key management service can be used for storing in-vehicle keys (such as keys of ECUs, etc.) and related calculations (such as MAC calculation). For example, an ECU on the vehicle corresponds to an ECU KEY. It should be noted that the in-vehicle keys (such as keys of ECUs, etc.) described in the embodiments of the present application are invisible to the diagnostic device. Based on this, the risk of leakage of the keys of the ECUs in the target vehicle will not occur. That is to say, the diagnostic device cannot obtain and save the keys of the ECUs on the vehicle, thereby avoiding affecting the security of the target vehicle and other vehicles.

[0172] In some embodiments, the service seed corresponding to the target ECU may be obtained by the first device from the target ECU before the first security verification. For example, when the first device receives a temporary symmetric key (such as a 27 service key) from a diagnostic device, the first device may obtain the service seed (such as a 27 service seed) from the target ECU according to the identifier of the target ECU carried in the access request.

[0173] In some embodiments, the service seed corresponding to the target ECU may be obtained by the first device from the target ECU after the first security verification is passed. For example, after the first device performs the first security verification on the diagnostic device based on the asymmetric key authentication algorithm and the device security certificate from the diagnostic device and the verification is passed, the first device may obtain the service seed (such as a 27 service seed) from the target ECU according to the identifier of the target ECU carried in the access request.

[0174] In some embodiments, if the first security verification fails, the first device may reject the access request of the diagnostic device. For example, assuming that the first information indicates that there is no legal binding relationship between the diagnostic device and the target vehicle, the first device may consider that the target vehicle does not allow the diagnostic device to access. In this case, the first device may send a feedback message to the diagnostic device indicating that the target vehicle does not allow the diagnostic device to access the target ECU.

[0175] S806: The first device sends the third MAC to the target ECU.

[0176] As an example, the first device may send the third MAC to the target ECU according to the identifier of the target ECU carried in the access request.

[0177] S807: The target ECU verifies the third MAC to perform the second security verification between the first device and the target ECU.

[0178] Among them, the second security verification is the verification of the authority of the first device, such as verifying the authority of the first device to unlock the target ECU. By passing the second security verification, it can be determined whether the first device can legally unlock the target ECU.

[0179] In some embodiments, the first control module may perform the second security verification according to the symmetric key authentication algorithm. When performing the second security verification according to the symmetric key authentication algorithm, as an example, the target ECU may calculate the fourth MAC according to the key of the target ECU and the service seed corresponding to the target ECU (such as a 27 service seed), and then verify whether the fourth MAC is the same as the third MAC. For example, when the fourth MAC is the same as the third MAC, the target ECU may determine that the second security verification is passed; when the fourth MAC is different from the third MAC, the target ECU may determine that the second security verification fails.

[0180] S808: After the second security verification passes, the target ECU executes the operation indicated by the access request.

[0181] As an example, after the second security verification passes, the first device can unlock the target ECU so that the diagnostic device can access the target ECU smoothly.

[0182] As an example, the operation that the target ECU executes according to the access request may include, but is not limited to, one or more of the following: sending the target data in the target ECU to the diagnostic device, accepting the modification of the data in the target ECU by the diagnostic device, and accepting the writing of data to the target ECU by the diagnostic device.

[0183] Among them, when sending the target data in the target ECU to the diagnostic device, the target ECU can directly send the target data to the diagnostic device or indirectly send the target data to the diagnostic device through the first device, without specific limitation. Similarly, when accepting the modification of the data in the target ECU by the diagnostic device or accepting the writing of data to the target ECU by the diagnostic device, the diagnostic device can directly modify / write data to the target ECU or indirectly modify / write data to the target ECU through the first device, without specific limitation.

[0184] In some embodiments, if the second security verification fails, the first device can reject the access request of the diagnostic device. For example, the first device can send a feedback message to the diagnostic device indicating that the target vehicle does not allow the diagnostic device to access the target ECU.

[0185] and Figure 8The process shown is similar. When a diagnostic device (such as the first diagnostic device) needs to access other ECUs (such as the second ECU, which is different from the first ECU) in a target vehicle (such as the first vehicle), a similar method can be adopted. First, a first security verification is performed between the first device and the first diagnostic device, and then a second security verification is performed between the first device and the second ECU. When both the first security verification and the second security verification are passed, the diagnostic device is allowed to access the second ECU. Exemplarily, when the diagnostic device needs to access the second ECU in the first vehicle, it can request the server to obtain the second information for performing the first security verification, and send an access request (such as the second access request) carrying the second information to the first device to request access to the second ECU. When receiving the second access request from the first diagnostic device, the first device performs the first security verification between the first device and the first diagnostic device according to the second information carried in the second access request (such as the second information indicating the legal binding relationship between the first diagnostic device and the first vehicle). For example, the first security verification is performed according to the symmetric key authentication algorithm or the asymmetric key authentication algorithm, depending on the specific content of the second information. Exemplarily, the second information can be a temporary key or a device security certificate, etc. After the first security verification is passed, the first device can request the second ECU to perform the second security verification between the second ECU and the first device, such as performing the second security verification according to the symmetric key authentication algorithm. Further, when the second security verification is passed, the first device allows the first diagnostic device to access the second ECU on the target vehicle and participates as an intermediate device in the subsequent data transmission between the first diagnostic device and the second ECU.

[0186] In some embodiments, the second information is the same as the first information. That is to say, the first information allocated by the server to the first diagnostic device is used when the first diagnostic device accesses the first vehicle. Based on this, the first diagnostic device cannot pass the first security verification of other vehicles to the first diagnostic device, so the first diagnostic device cannot successfully access other vehicles based on this. Or, even if a third party obtains this first information, based on this, it cannot pass the first security verification of the first vehicle or other vehicles to the third party, so the third party cannot successfully access the first vehicle or other vehicles based on this. Among them, in this embodiment, the first information and the second information can be a temporary key or a device security certificate.

[0187] In some embodiments, the second information is different from the first information. That is to say, the first information allocated by the server to the first diagnostic device is used when the first diagnostic device accesses the first ECU on the first vehicle. If the first diagnostic device requests to access other ECUs on the first vehicle based on this, it cannot pass the first security verification of the first vehicle for the first diagnostic device. Therefore, the first diagnostic device cannot successfully access other ECUs on the first vehicle based on this; or, if the first diagnostic device requests to access the ECUs on other vehicles based on this, it also cannot pass the first security verification of other vehicles for the first diagnostic device. Therefore, the first diagnostic device cannot successfully access the ECUs on other vehicles based on this. Or, even if a third party obtains the first information, it cannot pass the first security verification of the first vehicle or other vehicles for the third party based on this. Therefore, the third party cannot successfully access the ECUs on the first vehicle or other vehicles based on this. Among them, in this embodiment, the first information and the second information may be temporary keys.

[0188] Or, when other diagnostic devices (such as the second diagnostic device, and the second diagnostic device is different from the first diagnostic device) have a need to access a certain ECU (such as the third ECU, and the third ECU may be the same as or different from the first ECU) in the target vehicle (such as the first vehicle), a similar method can be adopted to first perform the first security verification between the first device and the second diagnostic device, and then perform the second security verification between the first device and the third ECU. When both the first security verification and the second security verification are passed, the diagnostic device is allowed to access the third ECU. Exemplarily, when the second diagnostic device has a need to access the third ECU in the first vehicle, it can request the server to obtain the third information for performing the first security verification, and send an access request (such as the third access request) carrying the third information and used to request access to the third ECU to the first device. When receiving the third access request from the second diagnostic device, the first device performs the first security verification between the first device and the second diagnostic device according to the third information carried in the third access request (such as the third information indicating the legal binding relationship between the second diagnostic device and the first vehicle), such as performing the first security verification according to the symmetric key authentication algorithm or the asymmetric key authentication algorithm, depending on the specific content of the third information. Exemplarily, the third information may be a temporary key or a device security certificate, etc. After the first security verification is passed, the first device can request the third ECU to perform the second security verification between the third ECU and the first device, such as performing the second security verification according to the symmetric key authentication algorithm. Further, when the second security verification is passed, the first device allows the second diagnostic device to access the third ECU on the target vehicle and participates in the subsequent data transmission between the diagnostic device and the third ECU as an intermediate device.

[0189] Among them, in this embodiment, the third information is different from the first information. That is to say, the first information allocated by the server to the first diagnostic device is used for the first diagnostic device to access the first vehicle, and the third information allocated to the second diagnostic device is used for the second diagnostic device to access the first vehicle. The second diagnostic device cannot pass the first security verification of the first diagnostic device by the vehicle based on the first information. Therefore, the first diagnostic device cannot successfully access the vehicle based on the first information. Similarly, the first diagnostic device cannot pass the first security verification of the first diagnostic device by the vehicle based on the third information. Therefore, the first diagnostic device cannot successfully access the vehicle based on the third information. Among them, in this embodiment, the first information and the second information can be a temporary key or a device security certificate.

[0190] Based on the security access method provided in Embodiment 1 of the present application, the first device can provide a diagnostic proxy isolation service. When a diagnostic device wants to access a target ECU on a certain target vehicle, it can perform a first security verification between the first device and the diagnostic device to preliminarily verify whether the diagnostic device can legally access the target vehicle. After the first verification passes, the first device can request the target ECU to perform a further second security verification between the first device and the target ECU to verify whether the first device can legally unlock the target ECU.

[0191] It can be understood that in this solution, on the one hand, through authorization management in the dimension of the diagnostic device and the vehicle (such as between a diagnostic device and a vehicle), such as Figure 9 as shown, Diagnostic Device 1 uses Temporary Key 1 to access Vehicle 1, Diagnostic Device 2 uses Temporary Key 2 to access Vehicle 2, Diagnostic Device 3 uses Temporary Key 2 to access Vehicle 3, Diagnostic Device 4 uses Temporary Key 4 to access Vehicle 4, Diagnostic Device 1 uses Temporary Key 5 to access Vehicle 2, Diagnostic Device 1 uses Temporary Key 6 to access Vehicle 3, Diagnostic Device 1 uses Temporary Key 7 to access Vehicle 4... one-to-one authorization, and the one-to-one first security verification of the vehicle for the diagnostic device's permission to access the vehicle can avoid the impact on other vehicles when one vehicle has a security risk. For example, even if the temporary key or device security certificate used to access the target vehicle is obtained by a third party, since the temporary key or device security certificate indicates the legal binding relationship between the diagnostic device and the target vehicle, the third party cannot access other vehicles based on this, and thus will not affect the security of other vehicles.

[0192] On the other hand, the isolation function provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle. That is to say, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device. Therefore, the risk of leakage of the key of the ECU in the target vehicle will not occur, and thus the security of the target vehicle and other vehicles can be prevented from being affected.

[0193] In addition, since the first information such as the temporary key / device security certificate usually has a valid duration, even if a third party obtains the temporary key / device security certificate, when the third party maliciously accesses the target vehicle based on the first information, the temporary key / device security certificate is very likely to have expired, so it will not cause any security impact on the target vehicle. To take a step back, even if the temporary key / device security certificate has not expired, since the temporary key / device security certificate is issued by the server for the diagnostic device to access the target vehicle, the third party cannot successfully access other vehicles based on this, so it will not affect the security of other vehicles either.

[0194] As described above, the first information in the embodiments of the present application may be a temporary key or a device security certificate. Hereinafter, taking the first information being a temporary key or a device security certificate as an example, the security access method described in Embodiment 1 will be specifically introduced.

[0195] Please refer to Figure 10 , Figure 10 Taking Figure 4 the system architecture shown as an example, a schematic diagram of a security access process provided by the embodiments of the present application is shown. Among them, Figure 10 the diagnostic device shown may be Figure 8 the diagnostic device shown, Figure 10 the diagnostic proxy service shown may be Figure 8 the service provided by the first device shown, Figure 10 the key management service shown may be Figure 8 the service provided by the first device shown or the service provided by other modules or devices in the vehicle (in the following example, it is taken as an example that both the diagnostic proxy service and the key management service are provided by the first device), Figure 8 the target ECU shown may be Figure 10 the remote communication module (telematics box, T-BOX), mobile data center (mobile data center, MDC), vehicle domain controller (vehicle domain controller, VDC), vehicle integration unit (vehicle integration unit, VIU), cockpit domain controller (cockpit domain controller, CDC) and other ECUs shown.

[0196] As Figure 10 shown, when the diagnostic device has a need to access the target ECU in the target vehicle, it can apply to the server for a temporary key (such as Figure 10 the serial number 1 shown), and after receiving the temporary key allocated by the server for it (such as Figure 10When the serial number 2) is shown, the diagnostic device can store the temporary key (such as Figure 10 shown in serial number 3) and send the temporary key to the target vehicle (such as Figure 10 shown in serial number 4), such as sending it to the diagnostic proxy service on the target vehicle. When receiving the temporary key, the diagnostic proxy service can store the temporary key in the temporary key storage computing service (such as Figure 10 shown in serial number 5). When receiving an access request from the diagnostic device (such as accessing the target ECU) (such as Figure 10 shown in serial number 6), the diagnostic proxy service can call the temporary key storage computing service (such as Figure 10 shown in serial number 7) to perform the first off-vehicle security verification on the permission of the diagnostic device to access the target vehicle based on the temporary key (such as Figure 10 shown in serial number 8). When the first security verification passes, the diagnostic proxy service can call the key management service (such as Figure 10 shown in serial number 9) to obtain the ECU key and use the ECU key to perform MAC calculation to request the second in-vehicle security verification based on the MAC from the target ECU (such as Figure 10 shown in serial number 10). When the second security verification of the diagnostic proxy service's permission to access the target ECU by the target ECU passes, the diagnostic proxy service can unlock the target ECU (such as Figure 10 shown in serial number 11). After that, the diagnostic device can successfully access the target ECU.

[0197] It should be noted that the embodiments of the present application do not limit Figure 10 the relationship between the temporary key storage computing service and the diagnostic proxy service shown. In some examples, the temporary key storage computing service can be a part of the diagnostic proxy service; in other examples, the temporary key storage computing service can be independent of the diagnostic proxy service and can accept calls from the diagnostic proxy service.

[0198] It can be understood that based on Figure 10 the security access process shown, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and holds the corresponding temporary keys, such as Figure 11 shown as MDC_KEY temporary 1, MDC_KEY temporary 2, MDC_KEY temporary 3, TBOX_KEY temporary 1, TBOX_KEY temporary 2, TBOX_KEY temporary 3..., where Figure 11The MDC_KEY temporary 1 shown is a temporary key allocated by the server to the diagnostic device for accessing the MDC in vehicle 1, the MDC_KEY temporary 2 is a temporary key allocated by the server to the diagnostic device for accessing the MDC in vehicle 2, the MDC_KEY temporary 3 is a temporary key allocated by the server to the diagnostic device for accessing the MDC in vehicle 3, the TBOX_KEY temporary 1 is a temporary key allocated by the server to the diagnostic device for accessing the TBOX in vehicle 1, the TBOX_KEY temporary 2 is a temporary key allocated by the server to the diagnostic device for accessing the TBOX in vehicle 2, and the TBOX_KEY temporary 3 is a temporary key allocated by the server to the diagnostic device for accessing the TBOX in vehicle 3. Since each temporary key is only used to access a specific vehicle or to perform the corresponding first off-vehicle security verification when accessing a specific ECU on a specific vehicle, even if a third party obtains a certain temporary key, it cannot successfully access other ECUs of that vehicle and other vehicles based on that temporary key. Therefore, it will not have any impact on the security of other ECUs on that vehicle and other vehicles. Additionally, since the temporary key usually has a valid duration, even if a third party obtains the temporary key corresponding to a certain vehicle, when the third party maliciously accesses that vehicle based on this, the temporary key is very likely to have expired, so it will not have any security impact on the security of that vehicle.

[0199] Please refer to Figure 12 , Figure 12 Taking the first information as the 27 service key as an example, a flowchart of a security access method provided by an embodiment of the present application is shown.

[0200] As Figure 12 shown, S801 may specifically include: the diagnostic device applying to the server for a temporary 27 service key.

[0201] As Figure 12 shown, S802 may specifically include: the server sending the 27 service key encrypted based on PK and the 27 service key encrypted based on Prek to the diagnostic device.

[0202] Among them, the 27 service key encrypted based on PK is used for the diagnostic device to parse out the 27 service key therefrom. For example, the diagnostic device can decrypt the 27 service key encrypted with PK based on the SK corresponding to PK saved locally, and obtain and store the obtained 27 service key. The diagnostic device obtains the 27 service key for subsequent security verification (such as the first security verification) when the diagnostic device accesses the target vehicle. Among them, PK and SK are the public-private key pair generated by the diagnostic device. After generating the public-private key pair (PK, SK), the diagnostic device can send the public key PK to the server, such as carrying the public key PK when applying for a diagnostic device certificate from the server. Based on this, the server can use PK to encrypt the information when sending it to the diagnostic device subsequently to ensure the security during the information transmission process. The 27 service key encrypted based on Prek is carried by the diagnostic device when sending an access request to the target vehicle. The server can also send the Prek encryption method to the diagnostic proxy service in the target vehicle so that the diagnostic proxy service can preset the corresponding decryption method for subsequent parsing of the information encrypted with Prek.

[0203] As Figure 12 shown, S803 may specifically include: The diagnostic device sends the 27 service key encrypted with Prek and the identifier of the target ECU to the diagnostic proxy service in the target vehicle.

[0204] As Figure 12 shown, S804 may specifically include: First, the diagnostic proxy service decrypts the 27 service key encrypted with Prek based on Prek, obtains and stores the 27 service key; the diagnostic proxy service requests the corresponding 27 service seed from the target ECU according to the request of the diagnostic device (such as according to the identifier of the target ECU carried therein), stores the 27 service seed sent by the target ECU and sends the obtained 27 service seed to the diagnostic device. Then, the diagnostic proxy service calculates the first MAC based on the 27 service key and 27 service seed it saves, and receives the second MAC calculated by the diagnostic device based on the 27 service key it saves and the 27 service seed received from the diagnostic proxy service. Finally, the diagnostic proxy service performs the first security verification between the diagnostic proxy service and the diagnostic device by comparing whether the second MAC is consistent with the first MAC.

[0205] As Figure 12 shown, S805 may specifically include: When the first security verification passes, the diagnostic proxy service requests the key management service to perform 27 service calculation; correspondingly, the key management service can calculate the third MAC based on the key of the target ECU stored and the 27 service seed obtained from the diagnostic proxy service and send it to the diagnostic proxy service.

[0206] As Figure 12As shown, S806 may specifically include: the diagnostic proxy service sends the third MAC to the target ECU to request the target ECU to perform the second security verification between the diagnostic proxy service and the target ECU.

[0207] As Figure 12 shown, S807 may specifically include: the target ECU calculates the fourth MAC based on the key of the target ECU and the 27 service seeds, and then performs the second security verification between the diagnostic proxy service and the target ECU by comparing whether the fourth MAC is consistent with the third MAC. Among them, when the second security verification passes, the target ECU can be unlocked and feedback a message of successful unlocking to the diagnostic proxy service, so that the diagnostic proxy can feedback a message of successful unlocking to the diagnostic device, and then perform the subsequent step S808.

[0208] Please refer to Figure 13 , Figure 13 Taking Figure 4 the system architecture shown as an example, another schematic diagram of the security access process provided by the embodiments of the present application is shown. Among them, Figure 13 the diagnostic device shown may be Figure 8 the diagnostic device shown, Figure 13 the diagnostic proxy service shown may be Figure 8 the service provided by the first device shown, Figure 13 the key management service shown may be Figure 8 the service provided by the first device shown or the service provided by other modules or devices in the vehicle (in the following examples, it is taken as an example that both the diagnostic proxy service and the key management service are provided by the first device), Figure 3 the target ECU shown may be Figure 10 the ECU such as T-BOX, MDC, VDC, VIU, CDC shown.

[0209] As Figure 13 shown, when the diagnostic device obtains authorization to access the target vehicle from the server, the server may send a root certificate to the target vehicle (such as Figure 13 the serial number 1 shown), where the root certificate includes the identifier of the diagnostic device that has the right to access the target vehicle, and the root certificate can be used for the diagnostic proxy service to perform a legality check on the access request. After receiving the root certificate, the diagnostic proxy service on the target vehicle can preset the root certificate (such as Figure 13 the serial number 2 shown). When the diagnostic device needs to access the target ECU in the target vehicle, it can apply to the server for a device security certificate (such as Figure 13 the serial number 3 shown). When receiving the device security certificate issued by the server for it (such as Figure 13 the serial number 4 shown), the diagnostic device can store the device security certificate (such as Figure 13as shown in serial number 5). When receiving an access request from a diagnostic device (such as accessing a target ECU) (such as Figure 13 as shown in serial number 6), the diagnostic proxy service can perform a first off-vehicle security verification on the permission of the diagnostic device to access the target vehicle based on the device security certificate carried in the access request and the preset root certificate (such as Figure 13 as shown in serial number 7). When the first security verification passes, the diagnostic proxy service can call the key management service (such as Figure 13 as shown in serial number 8) to obtain the ECU key, and use this ECU key to perform MAC calculation to request a second in-vehicle security verification based on this MAC from the target ECU (such as Figure 13 as shown in serial number 9). When the second security verification by the target ECU on the permission of the diagnostic proxy service to access the target ECU passes, the diagnostic proxy service can unlock the target ECU (such as Figure 13 as shown in serial number 10). After that, the diagnostic device can successfully access the target ECU.

[0210] It can be understood that based on Figure 13 the security access process shown, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and saved the corresponding device security certificates, such as Figure 14 the device security certificate 1 saved by diagnostic device 1 for accessing vehicle 1, the device security certificate 2 saved by diagnostic device 2 for accessing vehicle 1, the device security certificate 3 saved by diagnostic device 3 for accessing vehicle 1, and the device security certificate 4 saved by diagnostic device 4 for accessing vehicle 1 shown, since each device security certificate is only used for the corresponding first off-vehicle security verification when accessing a specific vehicle, even if a third party obtains a certain device security certificate, it cannot successfully access that vehicle or other vehicles based on this device security certificate, so it will not have any impact on the security of that vehicle and other vehicles.

[0211] In addition, the solution of the server managing the permission of the diagnostic device to access the vehicle by presetting the diagnostic device root certificate can also achieve faster and more secure authorization information distribution, and can be applied to a wider range of scenarios, such as being applicable to low-end devices or components without a symmetric system, being applicable to 29 authentication service standards, etc.

[0212] Moreover, the solution of the server managing the permission of the diagnostic device to access the vehicle by presetting the diagnostic device root certificate can also flexibly control the permission range of the diagnostic device according to actual needs. For example, the server can achieve strict one-to-one access of the diagnostic device to the vehicle by indicating a vehicle VIN in a device security certificate, or can achieve one-to-many access of the diagnostic device to the vehicle by indicating multiple vehicle VINs in a device security certificate.

[0213] Please refer to Figure 15 ,Figure 15 Taking the first piece of information as the device security certificate as an example, an interaction process of secure access provided by an embodiment of the present application is shown.

[0214] As Figure 15 shown, S801 may specifically include: the diagnostic device applying to the server for a device security certificate.

[0215] As Figure 15 shown, S802 may specifically include: the server issuing a device security certificate to the diagnostic device, where the device security certificate carries the VIN of the vehicle that the diagnostic device can access. In some embodiments, the device security certificate may carry one VIN, indicating that the diagnostic device is authorized to access only one vehicle; in other embodiments, the device security certificate may carry multiple VINs, indicating that the diagnostic device is authorized to access multiple vehicles.

[0216] As Figure 15 shown, S803 may specifically include: the diagnostic device sending the device security certificate and the identifier of the target ECU to the diagnostic proxy service in the target vehicle.

[0217] As Figure 15 shown, S804 may specifically include: the diagnostic proxy service verifying the device security certificate. For example, the diagnostic proxy service may respectively verify the legitimacy of the device security certificate and whether the VIN carried in the device security certificate matches the VIN of the target vehicle based on a preset root certificate. Among them, the root certificate preset by the diagnostic proxy service is obtained from the server.

[0218] As Figure 15 shown, S805 may specifically include: when the first security verification passes, the diagnostic proxy service obtains a 27 service seed from the target ECU, such as obtaining a 27 service seed from the target ECU according to the identifier of the target ECU, storing the 27 service seed and then requesting the key management service to perform 27 service calculation; correspondingly, the key management service may calculate the third MAC based on the stored key of the target ECU and the 27 service seed obtained from the diagnostic proxy service and send it to the diagnostic proxy service.

[0219] As Figure 15 shown, S806 may specifically include: the diagnostic proxy service sending the third MAC to the target ECU to request the target ECU to perform the second security verification between the diagnostic proxy service and the target ECU.

[0220] As Figure 15As shown in the figure, S807 may specifically include: the target ECU calculates the fourth MAC based on the key of the target ECU and the 27 service seeds, and then performs the second security verification between the diagnostic proxy service and the target ECU by comparing whether the fourth MAC is consistent with the third MAC. Among them, when the second security verification passes, the target ECU can be unlocked and feedback a message of successful unlocking to the diagnostic proxy service, so that the diagnostic proxy can feedback a message of successful unlocking to the diagnostic device, and then perform the subsequent step S808.

[0221] Embodiment 2:

[0222] In Embodiment 2, when receiving an access request from a diagnostic device to access the target ECU in a target vehicle, the first device on the target vehicle performs the first security verification between the first device and the diagnostic device according to the first information carried in the access request, and allows the diagnostic device to access the target vehicle when the first security verification passes, and participates in the subsequent data transmission between the diagnostic device and the vehicle as an intermediate device. Among them, the first information can be used to indicate the legal binding relationship between the diagnostic device and the target vehicle. For example, the first information may include, but is not limited to, a temporary key and a device security certificate. As an example, the first information is information obtained by the diagnostic device from the server for security verification.

[0223] As an example, please refer to Figure 16 , Figure 16 Taking Figure 4 the diagnostic device in the intelligent driving field accessing the vehicle under the system architecture shown as an example, a schematic diagram of a security access process provided by an embodiment of the present application is shown. As Figure 16 shown, when the diagnostic device has a need to access the vehicle, the first device on the vehicle can perform the first security verification between the first device and the diagnostic device, and this process can be based on the first information sent by the server to the diagnostic device for the first security verification; after the first security verification passes, the first device can unlock the ECU in the vehicle; then, the diagnostic device can successfully access the ECU in the vehicle.

[0224] In some embodiments, when the first device performs the first security verification between the first device and the diagnostic device, as Figure 16 shown, the first device can perform the above first security verification based on a symmetric key authentication algorithm, or can perform the above first security verification based on an asymmetric key authentication algorithm, or can also perform the above first security verification based on other security authentication algorithms, and the embodiments of the present application do not make specific limitations.

[0225] Please refer to Figure 17 , Figure 17 which shows a flowchart of a security access method provided by an embodiment of the present application. As Figure 17As shown, a security access method provided by an embodiment of the present application can be based on Figure 17 shown in S1701 - S1705 below:

[0226] S1701: In response to a trigger event for accessing a target vehicle, the diagnostic device sends a request message to the server.

[0227] Exemplarily, the request message sent by the diagnostic device (such as the first diagnostic device) to the server can be a request message for accessing a target vehicle (such as the first vehicle).

[0228] As an example, the trigger event for accessing the target vehicle can be an operation triggered manually, such as an operation triggered by a diagnostician, or an event automatically triggered by the diagnostic device when preset trigger conditions are met. The embodiments of the present application do not make specific limitations.

[0229] As an example, the timing at which the diagnostic device according to the embodiments of the present application sends a request message to the server in response to a trigger event for accessing the target vehicle can be before the vehicle leaves the factory or after the vehicle leaves the factory, without specific limitations.

[0230] As an example, the purpose of accessing the target vehicle can be used for, but not limited to, problem diagnosis, problem repair, or software upgrade of one or more ECUs in the target vehicle. For example, the diagnostic device can, in response to an operation of accessing the target vehicle, diagnose problems with the ECU by reading data in one or more ECUs in the target vehicle, and repair problems or upgrade software for the target vehicle by modifying data in the ECU and / or writing data into the ECU.

[0231] S1702: The server sends the first information to the diagnostic device according to the request message.

[0232] In the embodiments of the present application, the first information is used for the security verification of the target vehicle for the diagnostic device, such as for the first device on the target vehicle to perform the first security verification between the first device and the diagnostic device when the diagnostic device requests to access the target vehicle. The essence of the first security verification is an off - vehicle security verification, and through the first security verification, it can be determined whether the diagnostic device can legally access the target vehicle.

[0233] As an example, the first information can be used to indicate a legal binding relationship between the diagnostic device and the target vehicle. For example, based on the first information, the first device can determine that the diagnostic device is allowed to access the target vehicle.

[0234] In some embodiments, the first information can be used to indicate a temporary key, such as a temporary symmetric key. As an example, the temporary key can correspond to a scope of application and a validity period. As an example, the first information can be a 27 - service key.

[0235] In some embodiments, the first information may be a device security certificate. As an example, the device security certificate may correspond to a scope of application and a validity period.

[0236] Of course, the first information may also be other information for security verification provided by the server to the diagnostic device, and the embodiments of the present application do not make specific limitations.

[0237] In some embodiments, the first information sent by the server to the diagnostic device may be the first information encrypted, such as the first information encrypted by the first encryption method. The first information encrypted by the first encryption method is used to be directly carried in the access request when the diagnostic device sends an access request to the target vehicle, so as to prevent the temporary key or device security certificate indicated by the first information from being maliciously tampered with. At the same time, the server sends the first decryption method to the target vehicle, where the first decryption method corresponds to the first encryption method, and the first decryption method is used for the target vehicle to decrypt the first information when receiving the first information encrypted based on the first encryption method; and, the server sends the fourth information encrypted based on the second encryption method to the diagnostic device, and sends the second decryption method corresponding to the second encryption method to the diagnostic device, which is used for the diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method, where the information obtained by decrypting the fourth information (such as the temporary key) is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle.

[0238] Exemplarily, the first encryption method is, for example, the Prek encryption method, and the second encryption method is, for example, the PK encryption method.

[0239] S1703: The diagnostic device sends an access request to the first device on the target vehicle, and the access request carries the first information.

[0240] Among them, the access request is used to request access to the target vehicle; the purpose of the diagnostic device requesting access to the target vehicle may include but is not limited to reading data in one or more ECUs in the target vehicle, modifying data in one or more ECUs in the target vehicle, writing data into one or more ECUs in the target vehicle, etc.

[0241] In some embodiments, the first information received by the diagnostic device from the server is encrypted first information, such as the first information encrypted by the first encryption method. The diagnostic device can carry the first information encrypted by the first encryption method in the access request and send it to the first device. Generally, if the first information received by the diagnostic device from the server is the first information encrypted by the first encryption method, the diagnostic device will also receive the fourth information from the server, where the fourth information is the same as the information indicated by the first information (such as the temporary key), and the fourth information is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle. The difference between the fourth information and the first information is that the first information is encrypted by the first encryption method.

[0242] In some embodiments, the fourth information received by the diagnostic device from the server is encrypted, such as encrypted by the second encryption method. In this case, the diagnostic device can decrypt the fourth information according to the second decryption method corresponding to the second encryption method indicated by the server to obtain the information therein, such as the temporary key.

[0243] S1704: The first device performs the first security verification between the first device and the diagnostic device based on the first information.

[0244] Among them, the first security verification is to verify the permission of the diagnostic device to access the target vehicle. Through the first security verification, it can be determined whether the diagnostic device can legally access the target vehicle.

[0245] In some embodiments, the first device can perform the first security verification between the first device and the diagnostic device based on the first information according to the symmetric key authentication algorithm. For example, assume that the first information carried in the access request is a temporary symmetric key, such as the 27 service key. Then the first device can verify the temporary symmetric key according to the symmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0246] In some embodiments, the access request is used to access the target ECU in the target vehicle, and the access request carries the identifier of the target ECU. For this case, as a possible implementation manner when verifying the temporary symmetric key according to the symmetric key authentication algorithm, the first device can obtain the service seed (such as the 27 service seed) from the target ECU according to the identifier of the target ECU carried in the access request and send the service seed to the diagnostic device; then, the first device can calculate the first MAC according to the service key and the service seed and receive the second MAC calculated by the diagnostic device according to the service key and the service seed; finally, the first device verifies the temporary symmetric key by verifying whether the second MAC is the same as the first MAC.

[0247] As an example, a service seed (such as the 27 service seed) can be a temporary service seed randomly generated by the target ECU, such as a temporary service seed generated based on algorithms such as a random generation algorithm.

[0248] In some embodiments, the first device can perform a first security verification between the first device and the diagnostic device based on the first information according to an asymmetric key authentication algorithm. For example, assuming that the first information carried in the access request is a device security certificate, such as the 29 service certificate, the first device can verify the device security certificate according to the asymmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0249] When verifying the device security certificate according to the asymmetric key authentication algorithm, as a possible implementation, the first device can first verify the legitimacy of the device security certificate (such as the 29 service certificate), and when the legitimacy verification passes (such as the device security certificate is legal), verify whether the identification code carried in the device security certificate is consistent with the vehicle identification code in the root certificate saved in the first device. For example, when the VIN carried in the device security certificate includes the VIN in the root certificate, the first device can determine that the device security certificate verification passes, that is, the first security verification passes; when the VIN carried in the device security certificate does not include the VIN in the root certificate, the first device can determine that the device security certificate verification fails, that is, the first security verification fails.

[0250] S1705: When the first security verification passes, the first device performs the operation indicated by the access request.

[0251] As an example, after the first security verification passes, the first device can unlock the target vehicle so that the diagnostic device can successfully access the target vehicle. Alternatively, after the first security verification passes, the first device can unlock one or more ECUs in the target vehicle so that the diagnostic device can successfully access the ECUs in the target vehicle.

[0252] As an example, the operation performed by the first device according to the access request may include, but is not limited to, one or more of the following: sending target data of one or more ECUs in the target vehicle to the diagnostic device, accepting the modification of the data in one or more ECUs in the target vehicle by the diagnostic device, and accepting the writing of data to one or more ECUs in the target vehicle by the diagnostic device.

[0253] In some embodiments, the access request is used to access a target ECU in the target vehicle. For this case, the operation performed by the first device according to the access request may include, but is not limited to, one or more of the following: sending target data in the target ECU to the diagnostic device, accepting the modification of the data in the target ECU by the diagnostic device, and accepting the writing of data to the target ECU by the diagnostic device.

[0254] For the specific relevant introduction of S1701 - S1705, reference can be made to the introduction of S801 - S804 and S808 in the above text respectively, which will not be repeated here.

[0255] In some embodiments, if the second security verification fails, the first device may reject the access request of the diagnostic device. For example, the first device may send a feedback message to the diagnostic device to indicate that the target vehicle does not allow the diagnostic device to access the target vehicle or does not allow the diagnostic device to access the target ECU.

[0256] And Figure 17 Similar to the process shown, when other diagnostic devices (such as a second diagnostic device, which is different from the first diagnostic device) have a need to access the target vehicle (such as a first vehicle), a similar method can also be used for the first security verification between the first device and the second diagnostic device. When the first security verification passes, the diagnostic device is allowed to access the first vehicle. Exemplarily, the second diagnostic device may request from the server the third information for performing the first security verification when there is a need to access the first vehicle, and send an access request (such as a third access request) carrying the third information to the first device. When receiving the third access request from the second diagnostic device, the first device performs the first security verification between the first device and the second diagnostic device according to the third information carried in the third access request (such as the third information indicating the legal binding relationship between the second diagnostic device and the first vehicle). For example, the first security verification is performed according to the symmetric key authentication algorithm or the asymmetric key authentication algorithm, depending on the specific content of the third information. Exemplarily, the third information may be a temporary key or a device security certificate, etc. After the first security verification passes, the first device may allow the second diagnostic device to access the first vehicle and participate as an intermediate device in the subsequent data transmission between the diagnostic device and the first vehicle.

[0257] Among them, in this embodiment, the third information is different from the first information. That is to say, the first information allocated by the server to the first diagnostic device is used when the first diagnostic device accesses the first vehicle, and the third information allocated to the second diagnostic device is used when the second diagnostic device accesses the first vehicle. The second diagnostic device cannot pass the first security verification of the vehicle for the first diagnostic device based on the first information, so the first diagnostic device cannot successfully access the vehicle based on the first information either; similarly, the first diagnostic device cannot pass the first security verification of the vehicle for the first diagnostic device based on the third information, so the first diagnostic device cannot successfully access the vehicle based on the third information either. Among them, in this embodiment, the first information and the second information may be a temporary key or a device security certificate.

[0258] It can be understood that based on the security access method provided in Embodiment 2 of the present application, on the one hand, through the authorization management of the diagnostic device and the vehicle dimension (such as between a diagnostic device and a vehicle), such as Figure 9 as shown, the diagnostic device 1 uses the temporary key 1 to access the vehicle 1, the diagnostic device 2 uses the temporary key 2 to access the vehicle 2, the diagnostic device 3 uses the temporary key 2 to access the vehicle 3, the diagnostic device 4 uses the temporary key 4 to access the vehicle 4, the diagnostic device 1 uses the temporary key 5 to access the vehicle 2, the diagnostic device 1 uses the temporary key 6 to access the vehicle 3, the diagnostic device 1 uses the temporary key 7 to access the vehicle 4... one-to-one authorization, and the vehicle performs one-to-one first security verification on the diagnostic device's permission to access the vehicle, which can avoid the impact on other vehicles when one vehicle has security risks; for example, even if the temporary key or device security certificate used to access the target vehicle is obtained by a third party, since the temporary key or device security certificate indicates the legal binding relationship between the diagnostic device and the target vehicle, the third party cannot access other vehicles based on this, so it will not affect the security of other vehicles.

[0259] On the other hand, the isolation function provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle, that is, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device, so the risk of leakage of the key of the ECU in the target vehicle will not occur, and thus the security of the target vehicle and other vehicles can be avoided from being affected.

[0260] In addition, since the first information such as the temporary key / device security certificate usually has a valid duration, even if a third party obtains the temporary key / device security certificate, when the third party maliciously accesses the target vehicle based on the first information, the temporary key / device security certificate is very likely to have expired, so it will not cause any security impact on the target vehicle. Further, even if the temporary key / device security certificate has not expired, since the temporary key / device security certificate is issued by the server for the diagnostic device to access the target vehicle, the third party cannot successfully access other vehicles based on this, so it will not affect the security of other vehicles.

[0261] As described above, the first information in the embodiments of the present application may be a temporary key or a device security certificate.

[0262] Taking the first information as the 27 service key and the access request for accessing the target ECU in the target vehicle as an example, Figure 18 shows a flowchart of a security access method provided by the embodiments of the present application. As Figure 18 shown, the method may include S1701 - S1705. For the relevant introduction of S1701 - S1705, reference can be made to the above description of Figure 12The introductions of S801 - S804 and S808 in [Chinese text] will not be repeated here.

[0263] It can be understood that based on Figure 18 the shown secure access process, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and stores the corresponding temporary keys. Since each temporary key is only used for accessing a specific vehicle or for performing the corresponding first off - vehicle security verification when accessing a specific ECU on a specific vehicle, even if a third party obtains a certain temporary key, it cannot successfully access other ECUs of the vehicle or other vehicles based on this temporary key. Therefore, it will not cause any impact on the security of other ECUs on this vehicle and other vehicles. Additionally, since the temporary key usually has a valid duration, even if a third party obtains the temporary key corresponding to a certain vehicle, when the third party maliciously accesses the vehicle based on this, the temporary key is very likely to have expired. Therefore, it will not cause any security impact on the security of this vehicle.

[0264] Taking the first information as the device security certificate and the access request being used to access the target ECU in the target vehicle as an example, Figure 19 the flowchart of a secure access method provided by an embodiment of the present application is shown. As Figure 19 shown, this method may include S1901 - S1905. For the relevant introductions of S1901 - S1905, reference can be made to the introductions of S801 - S804 and S808 in [Chinese text] above respectively, which will not be repeated here. Figure 15 The introductions of S801 - S804 and S808 in [Chinese text] will not be repeated here.

[0265] It can be understood that based on Figure 19 the shown secure access process, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and stores the corresponding device security certificates. Since each device security certificate is only used for performing the corresponding first off - vehicle security verification when accessing a specific vehicle, even if a third party obtains a certain device security certificate, it cannot successfully access this vehicle or other vehicles based on this device security certificate. Therefore, it will not cause any impact on the security of this vehicle and other vehicles.

[0266] In addition, the solution where the server manages the access permissions of the diagnostic device to the vehicle by pre - setting the diagnostic device root certificate can also achieve faster and more secure authorization information distribution, and can be applicable to a wider range of scenarios, such as being applicable to low - end devices or components without a symmetric system, being applicable to the 29 - authentication service standard, etc.

[0267] In addition, the solution in which the server manages the access permission of the diagnostic device to the vehicle by pre-setting the diagnostic device root certificate can also flexibly control the permission range of the diagnostic device according to actual needs. For example, the server can achieve strict one-to-one access of the diagnostic device to the vehicle by indicating a vehicle VIN in a device security certificate, or can achieve one-to-many access of the diagnostic device to the vehicle by indicating multiple vehicle VINs in a device security certificate.

[0268] Embodiment 3:

[0269] In Embodiment 3, when receiving an access request from a diagnostic device to access a target ECU in a target vehicle, a first device on the target vehicle requests the target ECU to perform a second security verification between the target ECU and the first device. When the second security verification passes, the diagnostic device is allowed to access the target ECU on the target vehicle and participates in the subsequent data transmission between the diagnostic device and the target ECU as an intermediate device.

[0270] As an example, please refer to Figure 20 , Figure 20 to Figure 4 Taking the diagnostic device in the intelligent driving field under the system architecture shown in Figure 20 as an example to access the target ECU in the vehicle, a schematic diagram of a secure access process provided by an embodiment of the present application is shown. As shown in

[0271] In some embodiments, when the target ECU performs the second security verification between the target ECU and the first device, the target ECU can perform the above second security verification based on the Figure 20 shown symmetric key authentication algorithm, or can perform the above second security verification based on other security authentication algorithms. The embodiments of the present application do not make specific limitations.

[0272] Please refer to Figure 21 , Figure 21 which shows a flowchart of a secure access method provided by an embodiment of the present application. As shown in Figure 21 shown, a secure access method provided by an embodiment of the present application can be implemented based on Figure 21 shown S2101 - S2105:

[0273] S2101: The first device receives an access request from the diagnostic device.

[0274] Among them, the access request carries the identifier of the target ECU, and the access request is used to request access to the target ECU on the target vehicle; the purpose of the diagnostic device requesting access to the target ECU may include, but is not limited to, reading data in the target ECU, modifying data in the target ECU, writing data into the target ECU, etc.

[0275] S2102: The first device obtains a third MAC calculated based on the service seed corresponding to the target ECU and the key of the target ECU stored.

[0276] Among them, the service seed corresponding to the target ECU may be obtained by the first device from the target ECU according to the identifier of the ECU carried in the access request.

[0277] In some embodiments, the first device may provide a diagnostic proxy service and a key management service. For this case, the first device may call the key management service to obtain the key of the target ECU stored (such as the target ECU KEY), and then calculate the third MAC according to the key of the target ECU and the service seed corresponding to the target ECU (such as the 27 service seed).

[0278] In some other embodiments, the first device does not provide a key management service, and the key management service is provided by other modules or devices, such as provided by a key management module. For this case, the first device may send the service seed corresponding to the target ECU to the key management module and request the key management module to perform MAC calculation; the key management module may call the key management service to obtain the key of the target ECU stored (such as the target ECU KEY), calculate the third MAC according to the key of the target ECU and the service seed corresponding to the target ECU (such as the 27 service seed), and then send the third MAC to the first device.

[0279] Among them, the key management service may be used for storing in-vehicle keys (such as keys of ECUs, etc.) and related calculations (such as MAC calculation). For example, one ECU on the vehicle corresponds to one ECU KEY. It should be noted that the in-vehicle keys (such as keys of ECUs, etc.) described in the embodiments of the present application are invisible to the diagnostic device. Based on this, the risk of leakage of the keys of the ECUs in the target vehicle will not occur, and thus the security of the target vehicle and other vehicles can be avoided from being affected.

[0280] S2103: The first device sends the third MAC to the target ECU.

[0281] As an example, the first device may send the third MAC to the target ECU according to the identifier of the ECU carried in the access request.

[0282] S2104: The target ECU verifies the third MAC for the second security verification between the first device and the target ECU.

[0283] Wherein, the second security verification is to verify the permission of the first device, such as verifying the permission of the first device to unlock the target ECU. Through the second security verification, it can be determined whether the first device can legally unlock the target ECU.

[0284] In some embodiments, the first control module can perform the second security verification according to the symmetric key authentication algorithm. When performing the second security verification according to the symmetric key authentication algorithm, as an example, the target ECU can calculate the fourth MAC based on the key of the target ECU and the service seed corresponding to the target ECU (such as the 27 service seed), and then verify whether the fourth MAC is the same as the third MAC. For example, when the fourth MAC is the same as the third MAC, the target ECU can determine that the second security verification passes; when the fourth MAC is different from the third MAC, the target ECU can determine that the second security verification fails.

[0285] S2105: After the second security verification passes, the target ECU performs the operation indicated by the access request.

[0286] As an example, after the second security verification passes, the first device can unlock the target ECU so that the diagnostic device can successfully access the target ECU.

[0287] As an example, the target ECU performing the operation indicated by the access request may include, but is not limited to, one or more of the following: sending the target data in the target ECU to the diagnostic device, accepting the modification of the data in the target ECU by the diagnostic device, and accepting the writing of data to the target ECU by the diagnostic device.

[0288] Wherein, when sending the target data in the target ECU to the diagnostic device, the target ECU can directly send the target data to the diagnostic device or indirectly send the target data to the diagnostic device through the first device, without specific limitation. Similarly, when accepting the modification of the data in the target ECU by the diagnostic device or accepting the writing of data to the target ECU by the diagnostic device, the diagnostic device can directly modify the data in the target ECU / directly write data to the target ECU, or indirectly modify the data in the target ECU / indirectly write data to the target ECU through the first device, without specific limitation.

[0289] In some embodiments, if the second security verification fails, the first device can reject the access request of the diagnostic device. For example, the first device can send a feedback message to the diagnostic device indicating that the target vehicle does not allow the diagnostic device to access the target ECU.

[0290] For the specific relevant introduction of S2101 - S2105, reference can be made to the introduction of S803, S805 - S808 in the above text respectively, which will not be repeated here.

[0291] Similar to Figure 21 the process shown, when a diagnostic device (such as the first diagnostic device) has a need to access other ECUs (such as the second ECU, where the second ECU is different from the first ECU) in a target vehicle (such as the first vehicle), a similar method can also be used for the second security verification between the first device and the second ECU. When the second security verification passes, the diagnostic device is allowed to access the second ECU. Exemplarily, when the diagnostic device has a need to access the second ECU in the first vehicle, it can send an access request (such as a second access request) to the first device. When receiving the second access request from the first diagnostic device, the first device can request the second ECU to perform the second security verification between the second ECU and the first device, such as performing the second security verification according to the symmetric key authentication algorithm. Further, when the second security verification passes, the first device allows the first diagnostic device to access the second ECU on the target vehicle and participates in the subsequent data transmission between the first diagnostic device and the second ECU as an intermediate device.

[0292] Alternatively, when other diagnostic devices (such as the second diagnostic device, where the second diagnostic device is different from the first diagnostic device) have a need to access a certain ECU (such as the third ECU, where the third ECU may be the same as the first ECU or different from the first ECU) in a target vehicle (such as the first vehicle), a similar method can also be used for the second security verification between the first device and the third ECU. When the first security verification and the second security verification both pass, the diagnostic device is allowed to access the third ECU. Exemplarily, when the second diagnostic device has a need to access the third ECU in the first vehicle, it can send an access request (such as a third access request) to the first device. When receiving the third access request from the second diagnostic device, the first device can request the third ECU to perform the second security verification between the third ECU and the first device, such as performing the second security verification according to the symmetric key authentication algorithm. Further, when the second security verification passes, the first device allows the second diagnostic device to access the third ECU on the target vehicle and participates in the subsequent data transmission between the diagnostic device and the third ECU as an intermediate device.

[0293] As an example, please refer to Figure 22 , Figure 22 which shows a flowchart of a security access method provided by an embodiment of the present application. As Figure 22 shown, the method may include S2101 - S2105. For the relevant introduction of S2101 - S2105, reference can be made to the introduction of Figure 12 S803, S805 - S808 in the above text respectively, which will not be repeated here.

[0294] It can be understood that based on the secure access method provided in Embodiment 3 of the present application, the isolation function provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle. That is to say, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device. Therefore, the risk of leakage of the key of the ECU in the target vehicle will not occur, and thus the safety of the target vehicle and other vehicles can be prevented from being affected.

[0295] Based on the same inventive concept, an embodiment of the present application further provides a diagnostic device / server / first device. For example, as Figure 23 shown, the diagnostic device / server / first device may include a memory, a processor, a network interface, and a communication bus. Among them, the processor, the memory, and the network interface are connected through a double data rate (DDR) bus or other types of buses. The network interface is used to communicate with other devices or apparatuses.

[0296] The processor may be a central processing unit (CPU) or other specific integrated circuits. The processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. In practical applications, the diagnostic device / server / first device may also include multiple processors, and one or more processor cores may be included in the processors.

[0297] The memory is generally used to store computer program executable program codes. Among them, the executable program codes include instructions, and the processor executes various functional applications and data processing of the diagnostic device / server / first device by running the instructions stored in the memory. The memory may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, application programs required for at least one function, etc., and the data storage area may store data created during the use of the diagnostic device / server / first device.

[0298] In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0299] It is understandable that the present application Figure 23 The structures shown do not constitute a specific limitation on the diagnostic device / server / first device. In other embodiments of the present application, the diagnostic device / server / first device may include more or fewer components than those shown in the figures, or combine certain components, or split certain components, or have different component arrangements. The components may be implemented in hardware, software, or a combination of software and hardware.

[0300] It should be understood that the various solutions of the embodiments of the present application can be reasonably combined and used, and the explanations or descriptions of the various terms appearing in the embodiments can be referred to or explained with each other in the various embodiments, and no limitation is made thereto.

[0301] It should also be understood that in various embodiments of the present application, the magnitudes of the serial numbers of the above processes do not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0302] It is understandable that in order to implement the functions of any of the above embodiments, the diagnostic device / server / first device, etc. include the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of the examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain 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 technicians 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 application.

[0303] The embodiments of the present application can divide the diagnostic device / server / first device, etc. into functional modules. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiments of the present application is illustrative, only a logical function division, and there may be other division methods in actual implementation. It should also be understood that the various modules in the diagnostic device / server / first device, etc. can be implemented in the form of software and / or hardware, and no specific limitation is made thereto. In other words, the diagnostic device / server / first device, etc. are presented in the form of functional modules. Here, the "module" may refer to an application-specific integrated circuit ASIC, a circuit, a processor and a memory that execute one or more software or firmware programs, an integrated logic circuit, and / or other devices that can provide the above functions.

[0304] In an alternative manner, when data transmission is implemented using software, it can be implemented in the form of a computer program product, wholly or partially. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are implemented, wholly or partially. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a digital video disk (DVD)), or a semiconductor medium (such as a solid state disk (SSD)).

[0305] The steps of the methods or algorithms described in connection with the embodiments of the present application may be implemented in hardware or by a processor executing software instructions. The software instructions may consist of corresponding software modules, and the software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, hard disk, removable hard disk, compact disc read-only memory (CD-ROM), or any other form of storage medium well-known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium may also be a part of the processor. The processor and the storage medium may be located in an application specific integrated circuit (ASIC). Additionally, the ASIC may be located in a diagnostic device / server / first device, etc. Of course, the processor and the storage medium may also exist as discrete components.

[0306] From the description of the above embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of each functional module is used as an example. In actual applications, the above functions may be allocated to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

Claims

1. A secure access method, characterized in that, A first device applied to a first vehicle, the method comprising: Receiving a first access request from a first diagnostic device, the first access request carrying first information, the first access request being used to request access to the first vehicle, and the first information being used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; Performing a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information; When the first security verification passes, sending a first feedback message to the first diagnostic device, the first feedback message being used to indicate that the first diagnostic device is permitted to access the first vehicle.

2. The method according to claim 1, characterized in that, The first device has the key of the electronic control unit (ECU) on the first vehicle, and the first diagnostic device does not store the key of the ECU on the first vehicle.

3. The method according to claim 1 or 2, characterized in that, The first information is information encrypted based on a first encryption method, the first information being used to indicate a temporary key, and performing the first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information includes: Decrypting the first information according to a first decryption method to obtain the temporary key, the first decryption method being indicated by a server, and the first decryption method corresponding to the first encryption method; Verifying the temporary key based on a symmetric key authentication algorithm to perform the first security verification.

4. The method according to claim 3, characterized in that, The first access request is used to request access to the first ECU on the first vehicle, the temporary key is a 27 service key, and verifying the temporary key based on the symmetric key authentication algorithm includes: Obtaining a 27 service seed from the first ECU and sending the 27 service seed to the first diagnostic device; Calculating a first message authentication code (MAC) according to the 27 service key and the 27 service seed; Receiving a second MAC calculated by the first diagnostic device according to the 27 service key and the 27 service seed; Verifying whether the second MAC is the same as the first MAC; Wherein, the first feedback message is further used to indicate that the first diagnostic device is permitted to access the first ECU.

5. The method according to claim 1 or 2, characterized in that, The first information is a device security certificate, and performing the first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information includes: Verifying the legality of the device security certificate; When the device security certificate is legal, verifying whether the identification code carried in the device security certificate is consistent with the identification code of the first vehicle to perform the first security verification.

6. The method according to claim 5, characterized in that, The device security certificate carries an identification code, and the one identification code is the identification code of the first vehicle; or, The device security certificate carries multiple identification codes, and the multiple identification codes include the identification code of the first vehicle.

7. The method according to any one of claims 1 - 6, characterized in that, The first access request further carries an identifier of the first ECU, the first access request being used to request access to the first ECU on the first vehicle, the method further comprising: Request the first ECU to perform a second security verification for the first device to access the first ECU according to the identification of the first ECU. The second security verification is based on the key of the first ECU, and the key of the first ECU is invisible to the first diagnostic device.

8. The method according to claim 7, characterized in that, The method further includes: Obtain a third MAC, which is calculated based on the stored key of the first ECU and the service seed corresponding to the first ECU. The service seed corresponding to the first ECU is obtained from the first ECU; Send the third MAC to the first ECU to request the first ECU to perform the second security verification.

9. The method according to claim 7 or 8, characterized in that, The sending the first feedback message to the first diagnostic device includes: When the first security verification passes and the second security verification passes, send the first feedback message to the first diagnostic device.

10. The method according to claim 7 or 8, characterized in that, The method further includes: When the second security verification fails, send a third feedback message to the first diagnostic device, where the third feedback message is used to indicate that the first vehicle does not allow the first diagnostic device to access the first ECU.

11. The method according to any one of claims 1 - 10, characterized in that,The method further includes: Receive a second access request from the first diagnostic device. The second access request carries second information and an identification of a second ECU. The second access request is used to request access to the second ECU on the first vehicle, and the second information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; Perform a first security verification on the permission of the first diagnostic device to access the first vehicle based on the second information; When the first security verification passes, request the second ECU to perform a second security verification for the first device to access the second ECU based on the key of the second ECU. The key of the second ECU is invisible to the first diagnostic device; When the second security verification passes, send feedback information to the first diagnostic device indicating that the first diagnostic device is allowed to access the second ECU.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: Receive a third access request from a second diagnostic device. The third access request carries third information and an identification of a third ECU. The third access request is used to request access to the third ECU on the first vehicle, and the third information is used to indicate a legal binding relationship between the second diagnostic device and the first vehicle; Perform a first security verification on the permission of the second diagnostic device to access the first vehicle based on the third information; When the first security verification passes, request the third ECU to perform a second security verification for the first device to access the third ECU based on the key of the third ECU. The key of the third ECU is invisible to the second diagnostic device; When the second security verification passes, send feedback information to the second diagnostic device indicating that the second diagnostic device is allowed to access the third ECU.

13. A secure access method, characterized in that, Applied to a diagnostic device, the method includes: Send a request message to access the first vehicle to the server; Receive first information from the server, where the first information is used to indicate a legal binding relationship between the diagnostic device and the first vehicle; Send a first access request to a first device on the first vehicle, where the first access request is used to request access to the first vehicle, and the first information is carried in the first access request.

14. The method according to claim 13, characterized in that, The first device has the key of the ECU on the first vehicle, and the diagnostic device does not store the key of the ECU on the first vehicle.

15. The method according to claim 13 or 14, characterized in that, The first access request also carries the identifier of the first ECU, and the first access request is used to request access to the first ECU on the first vehicle.

16. The method according to any one of claims 13-15, characterized in that, The first information is information encrypted based on a first encryption method, and the method further includes: Receive fourth information from the server, where the fourth information is a temporary key encrypted based on a second encryption method; Decrypt the fourth information according to a second decryption method to obtain the temporary key, where the second decryption method is indicated by the server and corresponds to the second encryption method; The temporary key obtained based on decrypting the fourth information participates in a first security verification of the permission for the diagnostic device to access the first vehicle by the first device.

17. The method according to claim 16, characterized in that, The temporary key is a 27 service key. The temporary key obtained based on decrypting the fourth information participating in the first security verification of the permission for the first diagnostic device to access the first vehicle by the first device includes: Request the 27 service seed of the first ECU from the first device; Receive the 27 service seed of the first ECU from the first device; Calculate a second MAC based on the 27 service key and the 27 service seed; Send the second MAC to the first device, where the second MAC is used by the first device for the first security verification.

18. The method according to any one of claims 13-15, characterized in that, The first information is a device security certificate; Wherein, the device security certificate carries an identification code, and the identification code is the identification code of the first vehicle; or, The device security certificate carries multiple identification codes, and the multiple identification codes include the identification code of the first vehicle.

19. The method according to any one of claims 13-18, characterized in that, The method further includes: Send a second access request to the first device, where the second access request is used to request access to the second ECU on the first vehicle, and the second information and the identifier of the second ECU are carried in the second access request, and the second information is obtained from the server and is used to indicate a legal binding relationship between the diagnostic device and the second ECU on the first vehicle.

20. The method according to any one of claims 13 - 19, characterized in that, The method further includes: Send a request message to access a second vehicle to the server; Receive fifth information from the server, where the fifth information is used to indicate a legal binding relationship between the diagnostic device and the second vehicle, and the fifth information is different from the first information; Send a third access request to a second device on the second vehicle, where the third access request is used to request access to the second vehicle, and the fifth information is carried in the third access request.

21. A secure access method, characterized in that, Applied to a server, the method includes: Receive a request message from a first diagnostic device to access a first vehicle; Send first information to the first diagnostic device, where the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle.

22. The method according to claim 21, characterized in that, The first information is information encrypted based on a first encryption method, and the first information is directly carried by the first diagnostic device when sending an access request to the first vehicle; the method further includes: Send a first decryption method to a first device on the first vehicle, where the first decryption method corresponds to the first encryption method, and the first decryption method is used for the first device to decrypt the first information when receiving the first information encrypted based on the first encryption method; Send fourth information to the first diagnostic device, where the fourth information is a temporary key encrypted based on a second encryption method; Send a second decryption method to the first diagnostic device, where the second decryption method corresponds to the second encryption method, and the second decryption method is used for the first diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method to obtain the temporary key therein, and the temporary key obtained by decrypting the fourth information is used to participate in the security verification when the first diagnostic device accesses the first vehicle.

23. The method according to claim 21, characterized in that, The first information is a device security certificate; Wherein, an identification code is carried in the device security certificate, and the identification code is the identification code of the first vehicle; or, Multiple identification codes are carried in the device security certificate, and the multiple identification codes include the identification code of the first vehicle.

24. The method according to any one of claims 21 - 23, characterized in that, The method further includes: Receive a request message from a second diagnostic device to access a second vehicle; Send third information to the second diagnostic device, where the third information is used to indicate a legal binding relationship between the second diagnostic device and the second vehicle, and the third information is different from the first information.

25. A secure access method, characterized in that, Applied to a first device on a first vehicle, the method includes: Send a fourth access request to a first ECU on the first vehicle according to an instruction of the first diagnostic device, where the fourth access request is used to request a second security verification for the first device to access the first ECU, and a third MAC is carried in the fourth access request, where the second security verification is based on the key of the first ECU; When the second security verification is passed, send a first feedback message to the first diagnostic device, where the first feedback message is used to indicate that the first diagnostic device is allowed to access the first ECU.

26. The method according to claim 25, characterized in that, The first device has the key of the ECU on the first vehicle, and the first diagnostic device does not store the key of the ECU on the first vehicle.

27. The method according to claim 25 or 26, characterized in that, The method further includes: Obtain the third MAC, where the third MAC is calculated based on the key of the first ECU and a service seed corresponding to the first ECU, and the service seed corresponding to the first ECU is obtained from the first ECU.

28. The method according to any one of claims 25 - 27, characterized in that, Before sending the fourth access request to the first ECU, the method further includes: Receive a first access request from the first diagnostic device for requesting access to the first ECU, where the first access request carries first information and an identifier of the first ECU, and the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; Perform a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information.

29. The method according to claim 28, characterized in that, The first information is information encrypted based on a first encryption method, and the first information is used to indicate a temporary key. The performing a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information includes: Decrypt the first information according to a first decryption method to obtain the temporary key, where the first decryption method is indicated by the server and corresponds to the first encryption method; Verify the temporary key based on a symmetric key authentication algorithm to perform the first security verification.

30. The method according to claim 29, wherein, The temporary key is a 27 service key. The verifying the temporary key based on a symmetric key authentication algorithm includes: Obtain a 27 service seed from the first ECU and send the 27 service seed to the first diagnostic device; Calculate a first MAC according to the 27 service key and the 27 service seed; Receive a second MAC calculated by the first diagnostic device according to the 27 service key and the 27 service seed; Verify whether the second MAC is the same as the first MAC.

31. The method according to claim 28, wherein, The first information is a device security certificate. The performing a first security verification on the permission of the first diagnostic device to access the first vehicle based on the first information includes: Verify the legality of the device security certificate; When the device security certificate is legal, verify whether the identification code carried in the device security certificate is consistent with the identification code of the first vehicle to perform the first security verification.

32. The method according to claim 29, wherein, The device security certificate carries an identification code, and the identification code is the identification code of the first vehicle; or, The device security certificate carries multiple identification codes, and the multiple identification codes include the identification code of the first vehicle.

33. An apparatus, wherein, The apparatus includes: A memory for storing computer program instructions and data; A processor for executing the computer program instructions to support the apparatus in implementing the method according to any one of claims 1-12 or 25-32.

34. A diagnostic device, wherein, The diagnostic device includes: A memory for storing computer program instructions and data; A processor for executing the computer program instructions to support the diagnostic device in implementing the method according to any one of claims 13-20.

35. A server, wherein, The server includes: A memory for storing computer program instructions and data; A processor for executing the computer program instructions to support the server in implementing the method according to any one of claims 21-24.

36. A security verification system, wherein, The security verification system includes the apparatus according to claim 33 and the server according to claim 35.

37. A vehicle, wherein, The vehicle includes the apparatus according to claim 33 and one or more ECUs.

38. A computer-readable storage medium, wherein, Computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processing circuit, the method described in any one of claims 1-12, 13-20, 21-24, or 25-32 is implemented.

39. A computer program product comprising instructions, wherein, When the computer program product runs on a computer, the computer is caused to execute the method described in any one of claims 1-12, 13-20, 21-24, or 25-32.

Images