Secure access method, apparatus and system and vehicle

Abstract

The present application relates to the technical field of security control, and discloses a secure access method, apparatus and system and a vehicle, capable of improving the data security and vehicle safety during data access. In the solution, when there is a need to access a certain vehicle, a diagnostic device can send, to a first apparatus on the vehicle, an access request carrying first information used for indicating a legitimate binding relationship between the diagnostic device and the vehicle, and after successfully completing security verification on the basis of the first information, the first apparatus can allow the diagnostic device to access the vehicle. On this basis, by managing authorization at the dimensions of the diagnostic device and vehicles, the impact of a safety risk in one vehicle on other vehicles can be avoided. In addition, the isolation provided by the first apparatus enables keys of ECUs in the vehicle to be invisible to the diagnostic device, so that there will be no risk of key leakage from ECUs of a target vehicle, thereby avoiding impacts on the safety of the target vehicle and other vehicles.

Description

Security access method, device, system and vehicle

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 11, 2023, with application number 202311702925.6 and application name “Secure Access Method, Device, System and Vehicle”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of security control technology, and in particular to a security access method, device, system and vehicle. Background Art

[0003] Currently, in the field of smart cars, diagnostic instruments are widely used to diagnose vehicle problems, repair problems, or upgrade software. This process inevitably involves the diagnostic instrument reading, writing, or modifying vehicle-related data, which poses certain safety risks to the vehicle.

[0004] To enhance vehicle data security, a security server typically verifies the diagnostic instrument when it requests access to vehicle-related data. Once verified, access is granted. However, this security verification mechanism allows the instrument to access any data in the vehicle once verification is passed. Diagnostic instruments typically have extensive permissions, including capabilities such as querying the status of various vehicle components, reading and writing configuration data, querying and clearing fault codes, modifying code, and flashing software. Therefore, conventional security verification mechanisms still pose significant risks to vehicles. Summary of the Invention

[0005] The present application provides a secure access method, device, system, and vehicle, which can improve data security and vehicle safety during data access.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a secure access method is provided. The method can be applied to a first device on a first vehicle, the method comprising:

[0008] First, a first apparatus receives a first access request from a first diagnostic device requesting access to a first vehicle. The first access request carries first information indicating a valid binding relationship between the first diagnostic device and the first vehicle. For example, the first diagnostic device may be a diagnostic instrument. The valid binding relationship between the first diagnostic device and the first vehicle indicates that, based on the first information, the first diagnostic device is permitted to access the first vehicle. For example, the first information may be obtained by the first diagnostic device from a server and may be specific to a particular vehicle.

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

[0010] Finally, when the first security verification passes, 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 passes, the first device may 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.

[0011] In some examples, when the first security verification fails, the first apparatus may 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.

[0012] 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, and writing data to the first vehicle.

[0013] According to the solution provided by the first aspect above, when the 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 for 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 authority to access the first vehicle based on the first information is passed. Based on this, through the authorized management of the legal binding relationship between the diagnostic device and a vehicle, the impact of a vehicle on other vehicles when there is a safety 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, and cannot 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 therefore will not affect the safety of the vehicle. In addition, the isolation effect provided by the first device in the target vehicle can prevent the diagnostic equipment 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 equipment, so there is no risk of leakage of the key of the ECU in the target vehicle, thereby avoiding affecting the safety of the target vehicle and other vehicles.

[0014] As one possible implementation, the first device contains the key for the first vehicle's ECU, while the first diagnostic device does not. This isolation function of the first device prevents the diagnostic device from obtaining the key for the vehicle's ECU, potentially impacting the security of the ECU.

[0015] In one possible implementation, the first information is encrypted using a first encryption method, and the first information indicates a temporary key. The first device performs a first security verification on the first diagnostic device's access to the first vehicle based on the first information, including: decrypting the first information using a first decryption method corresponding to the first encryption method, as instructed by a server, to obtain the temporary key; and verifying the temporary key using a symmetric key authentication algorithm to perform the first security verification. It is understood that temporary keys typically have a validity period. Therefore, when the diagnostic device needs to access a 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. This improves data security and vehicle security during data access while reducing the impact on the security of the first vehicle if the temporary key is obtained by a third party. For example, if a third party uses the obtained temporary key to maliciously access the first vehicle, the temporary key is likely to have expired, thereby preventing any impact on the security of the first vehicle. Furthermore, since the first information is an encrypted temporary key, the security of the temporary key during transmission from the first diagnostic device to the first device is also improved.

[0016] In this implementation, the temporary key is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, meaning that the first device can determine, based on the temporary key, that the first diagnostic device is permitted to access the first vehicle. 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 form a public-private key pair.

[0017] As one possible implementation, the temporary key is encrypted using an encryption method indicated by the server, and the first device decrypts the first information to obtain the temporary key, including: the first device decrypts the first information using 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. This improves the security of the temporary key during transmission from the first diagnostic device to the first device.

[0018] As a possible implementation, the first access request is used to request access to a first ECU on a first vehicle. The temporary key is a 27-service key. The first device verifies the temporary key based on a symmetric key authentication algorithm, including: the first device obtains a 27-service seed from the first ECU and sends the 27-service seed to the first diagnostic device; the first device calculates a first message authentication code (MAC) based on the 27-service key and the 27-service seed; the first device receives a second MAC calculated by the first diagnostic device based on the 27-service key and the 27-service seed; and the first device verifies whether the second MAC is identical to the first MAC. For example, if the second MAC is identical to 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, a reliable and accurate security verification result can be provided.

[0019] 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-cipher block chaining (AES-CBC) algorithm, and AES-GMAC CTR mode (AES-GMAC CTR mode, AES-GCM) algorithm.

[0020] As a possible implementation, the first information carried in the first access request is a device security certificate. The first device performs a first security verification on the first diagnostic device's access to the first vehicle based on the first information, including: the first device verifies the legitimacy of the device security certificate; if the device security certificate is legitimate, 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)), thereby performing the first security verification of the first diagnostic device. Exemplarily, the device security certificate may include, but is not limited to, a 29 service certificate. Based on this, a reliable and accurate security verification result can be provided.

[0021] In this implementation, the device security certificate is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle, meaning that the first device can determine, based on the device security certificate, that the first diagnostic device is permitted to access the first vehicle. For example, a root certificate stored in the first device and the device security certificate have a preset correspondence, such as a preset correspondence between the identification information of the root certificate stored in the first device and the identification information of the device security certificate.

[0022] 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 an identification code, which 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, which are identification codes of multiple different vehicles, including the identification code of the first vehicle. Based on this, a flexible security management mechanism can be provided to authorize device security certificates to diagnostic equipment according to actual needs, such as authorizing the diagnostic equipment to access only the device security certificate of one vehicle or authorizing access to the device security certificates of multiple vehicles according to actual needs, thereby improving data security and vehicle safety during data access and flexibly managing the scope of authority of the diagnostic equipment.

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

[0024] As a possible implementation, the first access request also carries an identifier of the first ECU, and the first access request is used to request access to the first ECU on the first vehicle. The method further includes: the first device, based on the identifier of the first ECU carried in the first access request, requests the first ECU to perform a second security verification for the first device's access to the first ECU, wherein the second security verification is performed based on a key of the first ECU, which is not visible to the first diagnostic device. In conjunction with the first device's first security verification of the first diagnostic device, in this implementation, the first device's first security verification of the first diagnostic device can be understood as an off-vehicle security verification, based on which the first security verification verifies the first diagnostic device's authority to access the first vehicle. The second ECU's second security verification of the first device's access to the first ECU can be understood as an on-vehicle security verification, based on which the first security verification verifies the first device's authority to proxy access to the first ECU. Therefore, the isolation mechanism of the first device's off-vehicle and on-vehicle security verification not only enables more effective security verification of the diagnostic device's access to the target ECU, but also prevents the leakage of ECU keys. For example, due to the isolation effect of the first device, the first diagnostic device cannot obtain the key of the ECU in the first vehicle, thereby eliminating the risk of key leakage of the vehicle's ECU, thereby minimizing the security impact on the ECU.

[0025] As a possible implementation, the method further includes: obtaining a third MAC by the first device, where the third MAC is calculated based on a stored key of the first ECU (e.g., the first ECU KEY) and a service seed corresponding to the first ECU, the service seed corresponding to the first ECU being obtained from the first ECU; and sending the third MAC to the first ECU to request the first ECU to perform a second security verification. This allows for reliable and accurate in-vehicle security verification results.

[0026] 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.

[0027] As an example, an ECU on a first vehicle corresponds to an ECU KEY. The service seed corresponding to the first ECU (e.g., service seed 27) 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, without specific limitation.

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

[0029] For example, in some examples, the first device may include a diagnostic proxy service and a key management service. In this case, the first device may invoke 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 that includes the diagnostic proxy service and the key management service.

[0030] For another example, in some cases, 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 that provides key management services, such as a key management module. 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 then send it to the first device. For example, the first device can be a chip that has a diagnostic agent service, and the key management module can be a chip that has a key management service.

[0031] As a possible implementation, the above method also includes: first, the first device receives a second access request from the first diagnostic device, wherein 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 the legal binding relationship between the first diagnostic device and the first vehicle; then, the first device performs a first security verification on the first diagnostic device's authority to access the first vehicle based on the second information; thereafter, when the first security verification passes, the first device requests the second ECU to perform a second security verification on the first device's access to the second ECU based on the second ECU's key, wherein the second ECU's key is not visible to the first diagnostic device; finally, when the second security verification passes, the first device sends a feedback message to the first diagnostic device indicating 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, by using an authorization mechanism to authorize one 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 safety during the data access process, avoiding the impact on the safety 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, by using an authorization mechanism to authorize one 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 data security and vehicle safety during the data access process, avoiding the impact on the security of other ECUs after the first information of an ECU is obtained by a third party.

[0032] As a possible implementation, the method further includes: first, the first device receives a third access request from the second diagnostic device, wherein the third access request carries third information and an identifier of a third ECU, the third access request being for access to the third ECU on the first vehicle, and the third information being for indicating a legal binding relationship between the second diagnostic device and the first vehicle; then, the first device performs a first security verification on the second diagnostic device's access authority to the first vehicle based on the third information; thereafter, if the first security verification passes, the first device requests the third ECU to perform a second security verification on the first device's access to the third ECU based on a key of the third ECU, wherein the key of the third ECU is not visible to the second diagnostic device; and finally, if the second security verification passes, the first device sends a feedback message to the second diagnostic device indicating that the second diagnostic device is permitted to access the third ECU. Based on this, by authorizing a diagnostic device to access one piece of information on a vehicle, stricter security control can be provided for diagnostic devices accessing vehicles, improving data security and vehicle safety during data access while preventing the security of other vehicles from being impacted by the first information of a vehicle being obtained by a third party.

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

[0034] 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, and writing data to the first ECU.

[0035] In the solution provided by the second 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), it can request first information indicating the legal binding relationship between the diagnostic device and the vehicle from the server, and carry the first information when sending the access request to the first device in the vehicle. Based on this, through the authorized management of the legal binding relationship between the diagnostic device and a vehicle, the impact of a vehicle on other vehicles when it has a safety hazard can be avoided; for example, even if the first information used to access the target vehicle is obtained by a third party, because the first information indicates the legal binding relationship between the diagnostic device and the target vehicle, but cannot indicate the legal binding relationship between the diagnostic device and other vehicles, or cannot 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 vehicle. In addition, the isolation provided by the first device in the target vehicle can prevent the diagnostic device from obtaining the key of the ECU in the vehicle. In other words, the key of the ECU in the vehicle (including the key of the target ECU) is invisible to the diagnostic device, so there is no risk of the key of the ECU in the target vehicle being leaked, thereby avoiding the impact on the safety of the target vehicle and other vehicles.

[0036] As one possible implementation, the first device contains the key for the first vehicle's ECU, while the diagnostic equipment does not. This isolation function of the first device prevents the diagnostic equipment from obtaining the key for the vehicle's ECU, potentially impacting the security of the ECU.

[0037] As a possible implementation, the first access request also carries the identifier of the first ECU, requesting access to the first ECU on the first vehicle. This allows for targeted access to the ECU on the target vehicle, enriching the solution's use cases and adapting it to diverse access needs.

[0038] As a possible implementation, the first information carried in the above-mentioned first access request is used to indicate a temporary key or a device security certificate. For example, the temporary key 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 that the first diagnostic device is allowed 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 the legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine that the first diagnostic device is allowed to access the first vehicle based on the device security certificate, for example, the root certificate stored in the first device and the device security certificate have a preset corresponding relationship, such as the identification information of the root certificate stored in the first device and the identification information of the device security certificate have a preset corresponding relationship. Based on this, the diagnostic device can request access to the first vehicle from the first device through different forms of first information, so that the first device can perform reliable and accurate security verification.

[0039] In one possible implementation, the first information is encrypted using a first encryption method. The method further includes: the diagnostic device receiving fourth information from the server, where the fourth information is a temporary key encrypted using a second encryption method; the diagnostic device decrypting the fourth information according to the second encryption method corresponding to the second decryption method indicated by the server to obtain the temporary key; and the diagnostic device participating in a first security verification of the diagnostic device's access authority to the first vehicle by the first device based on the temporary key obtained by decrypting the fourth information. This improves the security of the temporary key during transmission from the server to the diagnostic device.

[0040] As one possible implementation, the first information indicates the 27 service key. The temporary key obtained by decrypting the fourth information participates in the first security verification of the first diagnostic device's access to the first vehicle by the first device. This includes: the diagnostic device requests the first device's 27 service seed for the first ECU; the diagnostic device receives the first ECU's 27 service seed from the first device; the diagnostic device calculates a second MAC based on the 27 service key and the 27 service seed; and the diagnostic device sends the second MAC to the first device, where the second MAC is used for the first device's first security verification. This facilitates the first device to reliably and accurately perform the first security verification of the diagnostic device by comparing the first MAC with the second MAC.

[0041] 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 an identification code, which 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, which are identification codes of multiple different vehicles, including the identification code of the first vehicle. Based on this, a flexible security management mechanism can be provided to authorize device security certificates to diagnostic equipment according to actual needs, such as authorizing the diagnostic equipment to access only the device security certificate of one vehicle or authorizing access to the device security certificates of multiple vehicles according to actual needs, thereby improving data security and vehicle safety during data access and flexibly managing the scope of authority of the diagnostic equipment.

[0042] As a possible implementation, the method further includes: the diagnostic device sending a second access request to the first apparatus, wherein the second access request is for accessing a second ECU on the first vehicle, and the second access request carries second information and an 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, by authorizing a diagnostic device to access a single piece of information on a single vehicle, more stringent security control can be provided when the diagnostic device accesses a single piece of information, improving data security and vehicle safety during data access while preventing the security of other vehicles from being compromised by a third party if the first information relating to the single vehicle is obtained. Alternatively, the second ECU is different from the first ECU, and the second information is different from the first information. Based on this, by authorizing a diagnostic device to access a single piece of information on a single ECU on a single vehicle, more stringent security control can be provided when the diagnostic device accesses a single piece of information on a single ECU in the vehicle, improving data security and vehicle safety during data access while preventing the security of other ECUs from being compromised by a third party if the first information relating to the single ECU is obtained.

[0043] As a possible implementation, the method further includes: the diagnostic device sending a request message to a server for access to a second vehicle; the diagnostic device receiving fifth information from the server, wherein 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; and the diagnostic device sending a third access request to a second device on the second vehicle, wherein the third access request is used to request access to the second vehicle, and the third access request carries the fifth information. Based on this, by using an authorization mechanism that authorizes one diagnostic device to access one vehicle, stricter security control can be provided when the diagnostic device accesses a vehicle. This improves data security and vehicle safety during data access while preventing the impact of the first information about one vehicle being obtained by a third party on the safety of other vehicles.

[0044] In a third aspect, a secure access method is provided, which 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, wherein the first information is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle.

[0045] In the solution provided by the third 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), the server can send a 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 be convenient for the first device to perform more targeted security verification on the diagnostic device's access to the ECU, which can improve data security and vehicle safety 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 will not be verified when using the first information to access other vehicles, and therefore will not cause safety hazards to other vehicles.

[0046] In one possible implementation, the first information is encrypted using a first encryption method and is directly carried by the first diagnostic device when sending an access request to the first vehicle. The method further includes: the server sending a first decryption method to a first device on the first vehicle, wherein the first decryption method corresponds to the first encryption method and is used by the first device to decrypt the first information encrypted using the first encryption method upon receiving the first information; the server sending fourth information to the first diagnostic device, wherein the fourth information is a temporary key encrypted using a second encryption method; and the server sending a second decryption method to the first diagnostic device, wherein the second decryption method corresponds to the second encryption method and is used by the first diagnostic device to decrypt the fourth information encrypted using the second encryption method upon receiving the fourth information to obtain the temporary key. The temporary key obtained by decrypting the fourth information is used to participate in security verification for the first diagnostic device to access the first vehicle. This improves the security of the temporary key during transmission from the server to the diagnostic device and during transmission from the first device to the diagnostic device.

[0047] As a possible implementation, the first information carried in the above-mentioned first access request is used to indicate a temporary key or a device security certificate. For example, the temporary key 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 that the first diagnostic device is allowed 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 the legal binding relationship between the first diagnostic device and the first vehicle, which means that the first device can determine that the first diagnostic device is allowed to access the first vehicle based on the device security certificate, for example, the root certificate stored in the first device and the device security certificate have a preset corresponding relationship, such as the identification information of the root certificate stored in the first device and the identification information of the device security certificate have a preset corresponding relationship. Based on this, the diagnostic device can request access to the first vehicle from the first device through different forms of first information, so that the first device can perform reliable and accurate security verification.

[0048] 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 an identification code, which 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, which are identification codes of multiple different vehicles, including the identification code of the first vehicle. Based on this, a flexible security management mechanism can be provided to authorize device security certificates to diagnostic equipment according to actual needs, such as authorizing the diagnostic equipment to access only the device security certificate of one vehicle or authorizing access to the device security certificates of multiple vehicles according to actual needs, thereby improving data security and vehicle safety during data access and flexibly managing the scope of authority of the diagnostic equipment.

[0049] As a possible implementation, the method further includes: the server receives a request message from the second diagnostic device for accessing the second vehicle; the server sends third information to the second diagnostic device, wherein 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, by authorizing a diagnostic device to access a vehicle with one piece of information through an authorization mechanism, stricter security control can be provided when the diagnostic device accesses the vehicle, while improving data security and vehicle safety during the data access process, while avoiding the impact on the safety of other vehicles after the first information of a vehicle is obtained by a third party.

[0050] In a fourth aspect, a security access method is provided, which can be applied to a first device on a first vehicle, and the method includes: the first device sends a fourth access request to the first ECU according to the instructions of the first diagnostic device, and the fourth access request is used to request a second security verification for the first device to access the first ECU, wherein the access request carries a third MAC, and the second security verification is performed 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, wherein the first feedback message is used to indicate that the first diagnostic device is allowed to access the first ECU.

[0051] 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 to the first ECU.

[0052] The solution provided in the fourth aspect, through the secure isolation of the first device, can prevent the diagnostic device from obtaining the key of the vehicle's ECU, thereby preventing the key leakage of a single ECU. For example, due to the isolation effect of the first device, the first diagnostic device cannot obtain the key of the first vehicle's ECU, thereby eliminating the risk of key leakage of the vehicle's ECU and thus minimizing the impact on the security of the ECU. Furthermore, this solution allows for effective security verification of the diagnostic device's access to the target ECU, improving both data security and vehicle safety during data access.

[0053] As one possible implementation, the first device contains the key for the first vehicle's ECU, while the diagnostic equipment does not. This isolation function of the first device prevents the diagnostic equipment from obtaining the key for the vehicle's ECU, potentially impacting the security of the ECU.

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

[0055] As an example, when the second security verification passes, the first device may send a feedback message to the first diagnostic device to indicate that the first diagnostic device is allowed to access the first ECU, or when the second security verification fails, the first device may 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.

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

[0057] 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.

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

[0059] For example, in some examples, the first device may include a diagnostic proxy service and a key management service. In this case, the first device may invoke 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 that includes the diagnostic proxy service and the key management service.

[0060] For another example, in some cases, 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 that provides key management services, such as a key management module. 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 then send it to the first device. For example, the first device can be a chip that has a diagnostic agent service, and the key management module can be a chip that has a key management service.

[0061] As a possible implementation, before the first device sends the fourth access request to the first ECU, the method further includes: the first device receiving a first access request from a first diagnostic device requesting access to a first ECU on a first vehicle, wherein the first access request carries first information and an identifier of the first ECU, the first information being used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; and the first device performing a first security verification of the first diagnostic device's access authority to the first vehicle based on the first information. Based on this, the first device's off-vehicle and on-vehicle security verification isolation mechanism not only enables more effective security verification of the diagnostic device's access to the target ECU, but also prevents key leakage of a single ECU. For example, due to the isolation effect of the first device, the first diagnostic device cannot obtain the key of the ECU in the first vehicle, thereby eliminating the risk of key leakage of the vehicle's ECU, thereby preventing security impacts on the ECU.

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

[0063] In some examples, when the first security verification fails, the first apparatus may 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.

[0064] In one possible implementation, the first information is encrypted using a first encryption method, and the first information indicates a temporary key. The first device performs a first security verification on the first diagnostic device's access to the first vehicle based on the first information, including: decrypting the first information using a first decryption method to obtain the temporary key, wherein the first decryption method is instructed by the server and corresponds to the first encryption method; and verifying the temporary key using a symmetric key authentication algorithm to perform the first security verification on the first diagnostic device. It is understood that temporary keys typically have a validity period. Therefore, when the diagnostic device needs to access a 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. This improves data security and vehicle security during data access while reducing the impact on the security of the first vehicle if the temporary key is obtained by a third party. For example, if a third party uses the obtained temporary key to maliciously access the first vehicle, the temporary key is likely to have expired, thereby preventing any impact on the security of the first vehicle. Furthermore, since the first information is an encrypted temporary key, the security of the temporary key during transmission from the first diagnostic device to the first device is also improved.

[0065] In this implementation, the temporary key is used to indicate a legal binding relationship between the first diagnostic device and the first vehicle, meaning that the first device can determine, based on the temporary key, that the first diagnostic device is permitted to access the first vehicle. 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 form a public-private key pair.

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

[0067] As one possible implementation, the temporary key is a 27-service key, and the first device verifies the temporary key based on a symmetric key authentication algorithm, including: the first device obtains a 27-service seed from the first ECU based on the 27-service key and sends the 27-service seed to the first diagnostic device; the first device calculates a first MAC based on the 27-service key and the 27-service seed; the first device receives a second MAC calculated by the first diagnostic device based on the 27-service key and the 27-service seed; and the first device verifies whether the second MAC is identical to the first MAC. For example, if the second MAC is identical to the first MAC, the first device's first security verification of the first diagnostic device has passed; if the second MAC is different from the first MAC, the first device's first security verification of the first diagnostic device has passed. Based on this, a reliable and accurate security verification result can be provided.

[0068] As a possible implementation, the first information carried in the first access request is a device security certificate. The first device performs a first security verification on the first diagnostic device's access to the first vehicle based on the first information, including: the first device verifies the legitimacy of the device security certificate; if the device security certificate is legitimate, 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)), thereby performing the first security verification of the first diagnostic device. Exemplarily, the device security certificate may include, but is not limited to, a 29 service certificate. Based on this, a reliable and accurate security verification result can be provided.

[0069] In this implementation, the device security certificate is used to indicate the legal binding relationship between the first diagnostic device and the first vehicle, meaning that the first device can determine, based on the device security certificate, that the first diagnostic device is permitted to access the first vehicle. For example, a root certificate stored in the first device and the device security certificate have a preset correspondence, such as a preset correspondence between the identification information of the root certificate stored in the first device and the identification information of the device security certificate.

[0070] 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 an identification code, which 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, which are identification codes of multiple different vehicles, including the identification code of the first vehicle. Based on this, a flexible security management mechanism can be provided to authorize device security certificates to diagnostic equipment according to actual needs, such as authorizing the diagnostic equipment to access only the device security certificate of one vehicle or authorizing access to the device security certificates of multiple vehicles according to actual needs, thereby improving data security and vehicle safety during data access and flexibly managing the scope of authority of the diagnostic equipment.

[0071] As a possible implementation, the above method also includes: first, the first device receives a second access request from the first diagnostic device, wherein 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 the legal binding relationship between the first diagnostic device and the first vehicle; then, the first device performs a first security verification on the first diagnostic device's authority to access the first vehicle based on the second information; thereafter, when the first security verification passes, the first device requests the second ECU to perform a second security verification on the first device's access to the second ECU based on the second ECU's key, wherein the second ECU's key is not visible to the first diagnostic device; finally, when the second security verification passes, the first device sends a feedback message to the first diagnostic device indicating 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, by means of an authorization mechanism for a diagnostic device to access one information on a vehicle, more stringent security control can be provided when the diagnostic device accesses the vehicle, while improving data security and vehicle safety during the data access process, avoiding the impact on the safety 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, by means of an authorization mechanism for a diagnostic device to access one information on an ECU of a vehicle, more stringent security control can be provided when the diagnostic device accesses the ECU in the vehicle, while improving data security and vehicle safety during the data access process, avoiding the impact on the security of other ECUs after the first information of an ECU is obtained by a third party.

[0072] As a possible implementation, the method further includes: first, the first device receives a third access request from the second diagnostic device, wherein the third access request carries third information and an identifier of a third ECU, the third access request being for access to the third ECU on the first vehicle, and the third information being for indicating a legal binding relationship between the second diagnostic device and the first vehicle; then, the first device performs a first security verification on the second diagnostic device's access authority to the first vehicle based on the third information; thereafter, if the first security verification passes, the first device requests the third ECU to perform a second security verification on the first device's access to the third ECU based on a key of the third ECU, wherein the key of the third ECU is not visible to the second diagnostic device; and finally, if the second security verification passes, the first device sends a feedback message to the second diagnostic device indicating that the second diagnostic device is permitted to access the third ECU. Based on this, by authorizing a diagnostic device to access one piece of information on a vehicle, stricter security control can be provided for diagnostic devices accessing vehicles, improving data security and vehicle safety during data access while preventing the security of other vehicles from being impacted by the first information of a vehicle being obtained by a third party.

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

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

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

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

[0077] In the ninth aspect, a vehicle or other means of transport is provided, which may include the device as described in the fifth aspect and one or more ECUs to implement the method described in any possible implementation of the first aspect or the third aspect.

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

[0079] In the eleventh aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to implement a method in any possible implementation of the first aspect, the second aspect, the third aspect or the fourth aspect.

[0080] In a twelfth aspect, a chip system is provided, comprising a processing circuit and a storage medium, wherein the storage medium stores computer program instructions; when the computer program instructions are executed by the processor, the method of any possible implementation of the first, second, third, or fourth aspects is implemented. The chip system may be composed of a chip alone, or may include a chip and other discrete components. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] FIG1 is a schematic diagram of a conventional security verification method;

[0082] FIG2 is a schematic diagram of another conventional security verification method in a security access process;

[0083] FIG3 is a schematic diagram showing the result of obtaining a key using a conventional diagnostic device;

[0084] FIG4 is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0085] FIG5 is a first schematic diagram of a secure access process according to an embodiment of the present application;

[0086] FIG6 is a second schematic diagram of a secure access process provided by an embodiment of the present application;

[0087] FIG7 is a third schematic diagram of a secure access process provided in an embodiment of the present application;

[0088] FIG8 is a flowchart of a secure access method according to an embodiment of the present application;

[0089] FIG9 is a first schematic diagram of a diagnostic device security access effect according to an embodiment of the present application;

[0090] FIG10 is an example diagram of a secure access process according to an embodiment of the present application;

[0091] FIG11 is a second schematic diagram of the security access effect of the diagnostic device provided in an embodiment of the present application;

[0092] FIG12 is an interactive diagram 1 of the secure access process provided by an embodiment of the present application;

[0093] FIG13 is a second example diagram of a secure access process provided by an embodiment of the present application;

[0094] FIG14 is a third schematic diagram of the diagnostic device security access effect provided by an embodiment of the present application;

[0095] FIG15 is a second interactive diagram of the secure access process provided by an embodiment of the present application;

[0096] FIG16 is a fourth schematic diagram of a secure access process provided by an embodiment of the present application;

[0097] FIG17 is a second flowchart of the secure access method provided in an embodiment of the present application;

[0098] FIG18 is a third interactive diagram of the secure access process provided by an embodiment of the present application;

[0099] FIG19 is a fourth interactive diagram of the secure access process provided by an embodiment of the present application;

[0100] FIG20 is a fifth diagram of a secure access process according to an embodiment of the present application;

[0101] FIG21 is a flowchart of a third method for secure access provided by an embodiment of the present application;

[0102] FIG22 is an interactive diagram 5 of the secure access process provided by an embodiment of the present application;

[0103] Figure 23 is a structural block diagram of a diagnostic device / server / first apparatus provided in an embodiment of the present application. DETAILED DESCRIPTION

[0104] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0105] In the following, the terms "first," "second," and so on are used solely to distinguish different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal number preceding the "field" in "first field" and "second field" does not limit the position or order of the "fields." "First" and "second" do not limit whether the modified "fields" are in the same message, nor do they restrict the order of the "first field" and "second field." For another example, if the described object is a "level," the ordinal number preceding the "level" in "first level" and "second level" does not limit the priority of the "levels." For another example, the number of described objects is not limited by the ordinal number and can be one or more. For example, in the case of "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the described object is a "device," the "first device" and "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 "second information" can be information of the same content or different contents. In short, the use of prefixes such as ordinal numbers to distinguish the described objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary restrictions should be constituted due to the use of such prefixes.

[0106] Furthermore, in the embodiments of the present application, "connection" may be a direct connection or an indirect connection; in addition, it may refer to an electrical connection or a communication connection; for example, the connection between two electrical components A and B may refer to a direct connection between A and B, or it may refer to an indirect connection between A and B through other electrical components or connection media, or it may refer to an indirect connection between A and B through other communication devices or communication media, as long as communication between A and B can be achieved.

[0107] As we know, in the smart car sector, diagnostic equipment (such as diagnostic instruments) can read, write, or modify vehicle components through diagnostic interfaces such as on-board diagnostics (OBD), both before and after the vehicle leaves the factory. This allows for extensive applications such as diagnosing vehicle problems, repairing issues, and upgrading software. As one of the few externally exposed interfaces on a vehicle, OBD typically has extensive permissions due to its high-level functions, such as querying the status of various vehicle components, reading and writing configuration words, querying and clearing fault codes, modifying code, and flashing software. Furthermore, due to the authentication mechanisms between the various ECUs within the vehicle, which require them to interact based on secret keys, a large number of secret keys are typically encapsulated within the vehicle. These keys may include pre-installed keys by chip manufacturers, device suppliers, and original equipment manufacturers before the vehicle leaves the factory, as well as owner keys set by the vehicle owner during use. In summary, if the OBD is maliciously compromised, it will pose a significant security risk to the vehicle. For example, if the OBD is compromised by a third party, the third party can access each ECU in the vehicle based on the key of each ECU. Or, because the keys of ECUs of the same type are usually the same, the third party can obtain the key of the ECU encapsulated in the vehicle and use it to access the same ECU in other vehicles. In short, conventional authentication mechanisms not only pose security risks to the vehicle being accessed, but also to other vehicles.

[0108] To improve data security and vehicle safety during diagnostic equipment access to the vehicle, in some embodiments, the vehicle can perform security verification of the diagnostic equipment based on security protocols such as the Transport Layer Security (TLS) protocol, such as between the vehicle and the diagnostic equipment, and between the vehicle and the security service platform. As shown in Figure 1, the TLS protocol primarily specifies the authentication and key negotiation required to establish or resume a secure session, as well as information encryption (including but not limited to symmetric encryption and asymmetric encryption). In some embodiments, the TLS protocol may also specify information integrity protection (such as hash algorithm integrity protection) and integrity verification. When establishing a secure session, the TLS protocol manages the following: key negotiation, server and client authentication, and exchange of session key information. Key negotiation refers to the negotiation between the server and client of the key used throughout the message interaction process, server and client authentication, such as the server proving its identity to the client, and exchange of session key information, such as the client and server exchanging random numbers and a special number called a pre-master key.

[0109] However, in this embodiment, no protection mechanism is provided for secure access control of the ECU inside the vehicle based solely on the TLS protocol.

[0110] In other embodiments, the vehicle can perform security verification on an off-board diagnostic device based on the 27 security access service and allow it to access the target ECU if the security verification passes. The 27 security access service is a service that provides a protection mechanism using a 27 service seed and a key. For example, as shown in FIG2 , 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 (e.g., based on a random generation algorithm) and send it to the diagnostic device. Thereafter, the diagnostic device and the target ECU can each calculate a key based on the 27 service seed using a security algorithm. The target ECU can perform security verification on the diagnostic device's access request by comparing its calculated key (e.g., key B) with the key calculated by the diagnostic device (e.g., key A). If the two are identical, the security verification of the diagnostic device passes; if they are different, the security verification of the diagnostic device fails.

[0111] However, in this embodiment, as shown in Figure 3, the diagnostic device stores the keys for all ECUs it has accessed. The keys (e.g., the 27-service key) for the same type of ECUs in a vehicle model are typically identical. Therefore, if the 27-service seed or key (TBOX_KEY, MDC_KEY, VDC_KEY, VIU_KEY, CDC_KEY, etc.) of a target ECU in a vehicle model obtained by the diagnostic device is leaked, it could affect the entire vehicle model. Furthermore, in this embodiment, the diagnostic device holds the 27-service seeds or keys for various types of ECUs in various vehicle models. Therefore, if the 27-service seed or key for one vehicle model is leaked, it could affect all vehicle models, resulting in a wide range of impact. Furthermore, because diagnostic devices are typically used in after-sales service shops across the country, they are difficult to manage and are more susceptible to malicious attacks.

[0112] In order to solve the above-mentioned problems existing in the security verification mechanism when conventional diagnostic equipment accesses the ECU, and to improve the data security and vehicle safety during the process of diagnostic equipment accessing the vehicle, an embodiment of the present application provides a security access method. In some embodiments, when the diagnostic equipment needs to access a certain vehicle (referred to as a "target vehicle"), it can send an access request to the vehicle and carry a temporary key or device security certificate, etc., in the access request to indicate the legal binding relationship between the diagnostic equipment and the target vehicle. The target vehicle can allow the diagnostic equipment to access the target vehicle after the security verification of the diagnostic equipment's access authority to the vehicle based on the temporary key or device security certificate is passed. Based on this, by performing authorization management and security verification in the diagnostic equipment and vehicle dimensions, the impact of a vehicle with potential safety hazards on other vehicles can be avoided.

[0113] In some embodiments, a vehicle may be provided with a module or device (referred to as a "first device") for isolating a diagnostic device from an ECU. When the diagnostic device needs to access a specific ECU in a target vehicle (referred to as a "target ECU"), it may send an access request to the first device on the target vehicle. The first device may initiate a security verification request to the target ECU based on the diagnostic device's instructions. If the target ECU passes the security verification of the first device, the diagnostic device may access the target ECU on the target vehicle and, acting as an intermediary, participate in subsequent data transmission between the diagnostic device and the target ECU. Because the security verification for accessing the ECU is performed within the vehicle, the isolation provided by the first device renders the vehicle ECU's key invisible to the diagnostic device, thereby preventing leakage of the vehicle ECU's key and, in turn, preventing impacts on the safety of the target vehicle and other vehicles.

[0114] In some embodiments, when a diagnostic device needs to access a target ECU on a target vehicle, it can send an access request to the vehicle and include in the access request a temporary key or device security certificate indicating the legal binding relationship between the diagnostic device and the target vehicle. After the target vehicle passes security verification of the diagnostic device's access rights to the vehicle based on the temporary key or device security certificate, it can initiate a security verification request to the target ECU. If the target ECU passes security verification of the first device, the diagnostic device can be allowed to access the target ECU on the target vehicle and act as an intermediary device to participate in subsequent data transmission between the diagnostic device and the target ECU. Based on this, on the one hand, by performing authorization management and the first security verification at the diagnostic device and vehicle levels, the impact of a vehicle's safety hazard on other vehicles can be avoided. On the other hand, the isolation provided by the first device makes the vehicle ECU's key invisible to the diagnostic device, thereby preventing the leakage of the vehicle ECU's key and, in turn, preventing the safety of the target vehicle and other vehicles.

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

[0116] As an example, the diagnostic device shown in FIG4 can be a diagnostic instrument, a diagnostic server, or a diagnostic server cluster, etc., and is not specifically limited in the embodiments of the present application. In the embodiments of the present application, the diagnostic device can initiate a request to access the target ECU in the vehicle to be diagnosed in response to an operation that triggers access to the target ECU in the vehicle to be diagnosed.

[0117] Among them, the timing when the diagnostic device initiates 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 stages, the after-sales stage is the stage after the vehicle leaves the factory, and the other stages are the stages before the vehicle leaves the factory. The embodiment of the present application does not limit the specific stage when the diagnostic device initiates a request to access the target ECU in the vehicle to be diagnosed. In addition, the embodiment of the present application does not limit the specific purpose of the diagnostic device initiating the 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. For example, problem diagnosis such as the ability to obtain fault codes, input / output control capability diagnosis, security access function diagnosis, data acquisition function diagnosis, program control function diagnosis and refresh function diagnosis, ECU initialization diagnosis, fault self-detection diagnosis when the ECU is turned off, continuous fault self-detection diagnosis when the ECU is turned off, etc.; problem repair such as repair of problems at the diagnosis site; software upgrade such as system upgrade or function upgrade, etc., are not specifically limited.

[0118] The server shown in Figure 4 is used to manage security authorization files, such as but not limited to vehicle-cloud signature, authorization deadline (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), and related function switch status.

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

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

[0121] The vehicle to be diagnosed shown in FIG4 may include one or more ECUs ( FIG4 takes the vehicle to be diagnosed as including ECU1, ECU2 and ECU3 as an example). ECU includes but is not limited to one or more of the following: on-board sensors, on-board cameras, front-mounted intelligent gateways (such as telematics boxes (T-Box)), on-board gateways, power distribution units (such as power distribution units (PDU)), battery management systems (such as (battery management system, BMS)), thermal management systems, domain controllers, etc. Among them, the domain controller can be divided into several areas (also called "functional domains") according to the functions of various parts of the vehicle, such as intelligent driving domain, cockpit domain, chassis domain, power domain, body domain, etc. Based on this, the on-board domain controller may 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 embodiment of the present application may be any of the above-mentioned ECUs without specific limitation.

[0122] In an embodiment of the present application, the vehicle to be diagnosed shown in FIG4 may be a vehicle with a key verification function. For example, as shown in FIG4 , a module or device for providing diagnostic agent services and key management services may be provided on the vehicle to be diagnosed. FIG4 takes the first device providing diagnostic agent services and key management services as an example. Diagnostic agent services may include but are not limited to services such as authorization file processing services, temporary key storage and calculation services, and 27 service key agent services. Key management services may include but are not limited to in-vehicle key storage and calculation services, in-vehicle key storage and calculation services such as storage of in-vehicle ECU keys and MAC calculation and other related calculations; authorization file processing services such as signature verification, authorization time verification, VIN code verification, switch execution, temporary key decryption and storage, etc.; 27 service key agent services such as 0x27 diagnostic service filtering, symmetric key verification, in-vehicle key verification, component unlocking, etc.

[0123] In some embodiments of the present application, the first device can be connected to one or more ECUs based on the transmission control protocol / internet protocol (TCP / IP) protocol, such as communicating with one or more ECUs through DoIP (diagnostic over IP) messages to support ECU diagnosis and other related processes.

[0124] In some embodiments of the present application, the first device can be connected to one or more ECUs based on a controller area network (CAN) bus, such as communicating with one or more ECUs through DoCAN (diagnostic over CAN) messages to support ECU diagnosis and other related processes.

[0125] It should be noted that the architecture shown in Figure 4 is only used as an example. In actual applications, the embodiments of the present application do not limit the specific modules that provide diagnostic proxy services and key management services. For example, the diagnostic proxy service and the key management service can also be provided by different modules. For example, the vehicle may include a diagnostic proxy module (i.e., the first device) and a key management module, wherein 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. For another example, the diagnostic proxy service or the key management service can be provided by other modules different from the diagnostic proxy module, and no specific limitation is made.

[0126] In addition, in actual applications, the embodiments of the present application do not limit the specific structure of the module providing diagnostic agent services and key management services. For example, the module providing diagnostic agent services and key management services can be a hardware module, component or device, or a chip, etc.

[0127] In an embodiment of the present application, the diagnostic agent module can initiate a request to access the target ECU in the 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. Among them, the diagnostic interface can be a unified diagnostic services (UDS) interface, or an on-board diagnostics (OBD) interface, or it can refer to other interfaces that can realize the command transmission function, without limitation. When vehicle diagnosis is realized based on a wireless method, the diagnostic device and the vehicle to be diagnosed can have near-field communication functions such as Bluetooth or a wireless local area network (WLAN). The diagnostician can first connect the diagnostic device and the vehicle to be diagnosed through the near-field communication function of the diagnostic device and the vehicle to be diagnosed, and then enter the diagnostic command on the diagnostic device so that the diagnostic command is transmitted to the vehicle to be diagnosed via wireless means. In some examples, the diagnostic device can also be provided with a display screen. After obtaining the diagnostic results, the diagnostic device can also display the diagnostic results to the diagnostician through the display screen, so as to remind the diagnostician to check the diagnostic results in time and then quickly find out the fault location and cause of the fault.

[0128] It should be understood that Figure 4 of the present application is only used as an example. The embodiments of the present application do not limit the number of vehicles to be diagnosed and the number of diagnostic devices in the system architecture. For example, one diagnostic device can only exchange information with one vehicle to be diagnosed, or it can exchange information with multiple vehicles to be diagnosed, and one vehicle to be diagnosed can exchange information with multiple diagnostic devices. Moreover, in addition to the vehicles to be diagnosed, diagnostic devices and servers shown in Figure 4, the system architecture applicable to the embodiments of the present application may also include other devices, such as supplier equipment, manufacturer equipment, production line equipment and sales equipment, etc., which are not limited by the embodiments of the present application. In addition, the diagnostic device described in the embodiments of the present application can integrate all functions on an independent physical device, or distribute the functions on multiple independent physical devices, which are not limited by the embodiments of the present application.

[0129] It should be noted that the security access method described in the embodiment of the present application can be applied to the field of intelligent driving, such as vehicle to everything (V2X), long-term evolution-vehicle (LTE-V), vehicle to vehicle (V2V) and other fields. For example, it can be applied to vehicles with key verification functions, or other devices in the vehicle with key verification functions, such as vehicle-mounted terminals, vehicle-mounted controllers, vehicle-mounted modules, vehicle-mounted modules, vehicle-mounted components, vehicle-mounted chips, vehicle-mounted units, vehicle-mounted radars or vehicle-mounted cameras and other sensors. Of course, the security access method in the embodiment 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 components of the intelligent terminal. The intelligent terminal may include but is not limited to intelligent transportation equipment, smart home devices, robots, etc. For example, it includes but is not limited to intelligent terminals or controllers, chips, radars or cameras in intelligent terminals, and other sensors, as well as other components. The following embodiments are introduced using the field of intelligent driving as an example.

[0130] The following will combine three specific embodiments (such as Example 1, Example 2 and Example 3), taking the target vehicle including a first device for providing diagnostic agent services as an example, to specifically introduce a secure access method provided by the embodiment of the present application.

[0131] Example 1:

[0132] In Example 1, upon receiving an access request from a diagnostic device to access a target ECU in a target vehicle, a first device on the target vehicle performs a first security verification between the first device and the diagnostic device based on the first information carried in the access request. After the first security verification passes, the first device requests the target ECU to perform a second security verification between the target ECU and the first device. Upon passing the second security verification, the diagnostic device is allowed to access the target ECU on the target vehicle and participates as an intermediary in subsequent data transmission between the diagnostic device and the target ECU. The first information can be used to indicate a legal binding relationship between the diagnostic device and the target vehicle. For example, the first information can 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 a server for security verification.

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

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

[0135] 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-mentioned second security verification based on the symmetric key authentication algorithm shown in Figure 6 or Figure 7, or it can perform the above-mentioned second security verification based on other security authentication algorithms, which is not specifically limited in the embodiments of the present application.

[0136] A symmetric key authentication algorithm uses the same key for decryption as for encryption. Both the sender and receiver know the key and encryption / decryption algorithm in advance, and the key is the same. An asymmetric key authentication algorithm uses a different key for decryption than for encryption. For example, a public key and a private key can be used together for encryption and decryption. For example, the sender and receiver can negotiate a set of keys in advance and send their public keys to each other. When the sender sends data to the receiver, it can encrypt the data using the receiver's public key and send it to the receiver. Correspondingly, the receiver uses its own private key to decrypt the data encrypted with the public key.

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

[0138] S801: The diagnostic device sends a request message to the server in response to a triggering event for accessing a target ECU in a target vehicle.

[0139] 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 a vehicle (ie, a target vehicle, such as the first vehicle) where the target ECU (such as the first ECU) is located.

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

[0141] In the embodiments of the present application, the diagnostic device may be a device outside the vehicle, such as a device independent of the original equipment manufacturer (OEM) and the supplier's equipment, or a part of the OEM equipment or a part of the supplier's equipment, without specific limitation.

[0142] As an example, the timing for the diagnostic device described in the embodiment of the present application to send a request message to the server in response to a trigger event for accessing the target ECU may be before or after the vehicle leaves the factory, without specific limitation.

[0143] As an example, the purpose of accessing the target ECU may be, but is not limited to, diagnosing problems, repairing problems, or upgrading software on the target ECU. For example, in response to accessing the target ECU, the diagnostic device may diagnose problems on the target ECU by reading data from the target ECU, and repair problems or upgrade software on the target ECU by modifying data in the target ECU and / or writing data to the target ECU.

[0144] As an example, the problem diagnosis described in the embodiments of the present application may include but is not limited to the ability to obtain fault codes, input / output control capability diagnosis, security access function diagnosis, data acquisition function diagnosis, program control function diagnosis and refresh function diagnosis, ECU initialization diagnosis, fault self-detection diagnosis when the ECU is turned off, continuous fault self-detection diagnosis when the ECU is turned off, etc.; problem repair may include but is not limited to repairing problems at the diagnosis site; software upgrades may include but are not limited to system upgrades or function upgrades, etc., without specific limitations.

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

[0146] In an embodiment of the present application, the first information is used for security verification of the diagnostic equipment by the target vehicle, such as for performing a first security verification between the first device and the diagnostic equipment by the first device on the target vehicle when the diagnostic equipment requests access to the target ECU, wherein the essence of the first security verification is an off-vehicle security verification, and the first security verification can be used to determine whether the diagnostic equipment can legally access the target vehicle.

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

[0148] In some embodiments, the first information can be used to indicate a temporary key, such as a temporary symmetric key. It is understood that, compared to conventional security keys such as long-term keys, temporary keys, due to their specific temporary nature (e.g., they expire after a certain period of time), can address the security impact of leakage of conventional security keys such as long-term keys on the control module. Based on this, and considering the risk of key leakage, the server can improve data security and vehicle safety during the process of the diagnostic device accessing the control module by allocating a temporary key to the diagnostic device.

[0149] As an example, a temporary key can have an applicable scope and a validity period. For example, the applicable scope of the temporary key can be configured by the server based on the target ECU to be accessed by the diagnostic device. For example, the applicable scope of the temporary key can be the target ECU or the target vehicle where the target ECU is located. The validity period of the temporary key can be configured by the server based on the security control level, priority, and other actual conditions. For example, the validity period can be 12 hours, 24 hours, etc., without specific restrictions.

[0150] As an example, the first information may be a service key 27. Of course, the embodiment of the present application does not specifically limit the specific key type of the temporary key.

[0151] In some embodiments, the first information may be a device security certificate. It is understandable that, compared to conventional security keys such as long-term keys, the method of pre-setting the diagnostic device root certificate 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 in the data access process, thereby solving the security risks caused by the leakage of conventional security keys such as long-term keys. In addition, the solution of the server managing the permissions of the diagnostic device to access the ECU / vehicle by pre-setting 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 low-end devices or components with asymmetric systems such as BMS and electric power steering (EPS) systems, and 29 certification service standards.

[0152] As an example, a device security certificate may have an applicable scope and a validity period. For example, the applicable scope of a device security certificate may be configured by the server based on the target ECU to be accessed by the diagnostic device. For example, the applicable scope of the device security certificate may be the target ECU or the target vehicle where the target ECU is located. The validity period of the device security certificate may be configured by the server based on the security control level, priority, and other specific circumstances. For example, the validity period may be 12 hours, 24 hours, etc., without specific restrictions.

[0153] Of course, the first information may also be other information provided by the server to the diagnostic device for security verification, which is not specifically limited in the embodiment of the present application.

[0154] In some embodiments, the first information sent by the server to the diagnostic device may be encrypted first information, such as first information encrypted by a first encryption method. The first information encrypted by the first encryption method is used by the diagnostic device to be directly carried in the access request when sending an access request to the target vehicle, so as to avoid malicious tampering with the temporary key or device security certificate indicated by the first information. At the same time, the server sends a first decryption method to the target vehicle, wherein the first decryption method corresponds to the first encryption method, and the first decryption method is used by 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 by the diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method, wherein the information obtained by decrypting the fourth information (such as a temporary key) is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle.

[0155] Exemplarily, the first encryption method is a Prek encryption method, and the second encryption method is a PK encryption method.

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

[0157] The access request carries the identifier of the target ECU on the target vehicle, and 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 to the target ECU, etc.

[0158] In some embodiments, the first information received by the diagnostic device from the server is encrypted first information, such as first information encrypted using a first encryption method. The diagnostic device may include the first information encrypted using the first encryption method in an access request and send it to the first device. Typically, if the first information received by the diagnostic device from the server is encrypted using the first encryption method, the diagnostic device will also receive fourth information from the server. The fourth information is the same as the information indicated by the first information (such as a temporary key). The fourth information is used to participate in security verification (such as the first security verification) when the diagnostic device accesses the target vehicle. The fourth information differs from the first information in that the first information is encrypted using the first encryption method.

[0159] 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 information therein, such as a temporary key.

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

[0161] The first security verification is a preliminary verification of the authority of the diagnostic device, such as verifying the authority of the diagnostic device to access the target vehicle. The first security verification can determine whether the diagnostic device can legally access the target vehicle.

[0162] 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 a symmetric key authentication algorithm. For example, assuming that the first information carried in the access request is a temporary symmetric key, such as a 27 service key, the first device may 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.

[0163] As an example, the symmetric key authentication algorithm described in the embodiments of the present application may include, but is not limited to, any of the following: Advanced Encryption Standard (AES) algorithm, Data Encryption Standard (DES) algorithm, Triple DES (3DES) algorithm, etc. Exemplarily, the AES algorithm includes AES-cipher-based message authentication code (AES-CMAC) algorithm, AES-cipher block chaining (AES-CBC) algorithm, AES-GMAC CTR mode (AES-GMAC CTR mode, AES-GCM) algorithm, etc.

[0164] In some embodiments, the access request is used to access a target ECU in a target vehicle. In this case, when verifying the temporary symmetric key according to the symmetric key authentication algorithm, as a possible implementation method, the first device can obtain a service seed (such as 27 service seed) from the target ECU based on 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 a first MAC based on the service key and the service seed, and receive a second MAC calculated by the diagnostic device based on 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.

[0165] As an example, the service seed (such as the 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.

[0166] 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 using an asymmetric key authentication algorithm. For example, assuming 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 using the asymmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0167] As an example, the asymmetric key authentication algorithm described in the embodiment of the present application may include but is not limited to any one of the following: RSA algorithm, digital signature algorithm (digital signature arithmetic, DSA), elliptic curve cryptography (elliptic curve cryptography, ECC) algorithm, etc.

[0168] When verifying the device security certificate according to the asymmetric key authentication algorithm, as a possible implementation method, the first device may 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 stored 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 has passed, that is, the first security verification has passed; 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 has failed, that is, the first security verification has failed.

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

[0170] In some embodiments, the first device may provide a diagnostic agent service and a key management service. In this case, the first device may invoke the key management service to obtain a stored key of the target ECU (e.g., target ECU KEY), and then calculate the third MAC based on the key of the target ECU and a service seed corresponding to the target ECU (e.g., 27 service seed).

[0171] In other embodiments, the first device does not provide a key management service, and the key management service is provided by another module or device, such as a key management module. In this case, the first device can send the service seed corresponding to the target ECU to the key management module and request the key management module to perform a MAC calculation. The key management module can call the key management service to obtain the stored key of the target ECU (such as the target ECU KEY), calculate a third 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 send the third MAC to the first device.

[0172] Among them, the key management service can be used to store in-vehicle keys (such as ECU keys, etc.) and perform related calculations (such as MAC calculations). For example, one ECU on a vehicle corresponds to one ECU KEY. It should be noted that the in-vehicle keys (such as ECU keys, etc.) described in the embodiments of the present application are invisible to the diagnostic equipment. Based on this, there is no risk of leakage of the ECU keys in the target vehicle. In other words, the diagnostic equipment cannot obtain and save the ECU keys on the vehicle, thereby avoiding affecting the safety of the target vehicle and other vehicles.

[0173] In some embodiments, the service seed corresponding to the target ECU may be obtained by the first device from the target ECU before performing the first security verification. For example, when the first device receives a temporary symmetric key (e.g., a 27 service key) from the diagnostic device, the first device may obtain the service seed (e.g., a 27 service seed) from the target ECU based on the target ECU identifier carried in the access request.

[0174] In some embodiments, the service seed corresponding to the target ECU may be obtained by the first device from the target ECU after passing the first security verification. For example, after the first device performs the first security verification on the diagnostic device based on the device security certificate from the diagnostic device using an asymmetric key authentication algorithm and passes the verification, the first device may obtain the service seed (e.g., service seed 27) from the target ECU based on the target ECU identifier carried in the access request.

[0175] In some embodiments, if the first security verification fails, the first device may deny the diagnostic device's access request. For example, if the first information indicates that there is no legal binding relationship between the diagnostic device and the target vehicle, the first device may assume that the target vehicle does not allow the diagnostic device to access the target ECU. 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.

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

[0177] 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.

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

[0179] The second security verification is a verification of the authority of the first device, such as verifying the authority of the first device to unlock the target ECU. The second security verification can determine whether the first device can legally unlock the target ECU.

[0180] In some embodiments, the first control module may perform a second security verification based on a symmetric key authentication algorithm. When performing the second security verification based on the symmetric key authentication algorithm, as an example, the target ECU may calculate a fourth MAC based on the target ECU's key and a service seed (e.g., a 27 service seed) corresponding to the target ECU, and then verify whether the fourth MAC is identical to the third MAC. For example, if the fourth MAC is identical to the third MAC, the target ECU may determine that the second security verification has passed; if the fourth MAC is different from the third MAC, the target ECU may determine that the second security verification has failed.

[0181] S808: After the second security verification is passed, the target ECU executes the operation indicated by the access request.

[0182] As an example, after the second security verification is passed, the first device may unlock the target ECU so that the diagnostic equipment can successfully access the target ECU.

[0183] As an example, the operations indicated by the target ECU executing the access request may include but are not limited to one or more of the following: sending target data in the target ECU to the diagnostic device, accepting modifications to the data in the target ECU by the diagnostic device, and accepting writing data to the target ECU by the diagnostic device.

[0184] When transmitting target data from the target ECU to the diagnostic device, the target ECU may transmit the target data directly or indirectly via the first device, without specific limitations. Similarly, when accepting modifications to data in the target ECU by the diagnostic device or accepting data written to the target ECU by the diagnostic device, the diagnostic device may directly modify the data in the target ECU / write data to the target ECU, or indirectly modify the data in the target ECU / write data to the target ECU via the first device, without specific limitations.

[0185] 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 indicating that the target vehicle does not allow the diagnostic device to access the target ECU.

[0186] Similar to the process shown in FIG8 , when a diagnostic device (e.g., a first diagnostic device) needs to access another ECU (e.g., a second ECU, which is different from the first ECU) in a target vehicle (e.g., the first vehicle), a similar method can be used to first perform a first security verification between the first device and the first diagnostic device, followed by a second security verification between the first device and the second ECU. If both the first and second security verifications pass, the diagnostic device is allowed access to the second ECU. For example, when the diagnostic device needs to access the second ECU in the first vehicle, it can request second information from a server for the first security verification and send an access request (e.g., a second access request) containing the second information to the first device requesting access to the second ECU. Upon 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 based on the second information contained in the second access request (e.g., the second information indicates the legal binding relationship between the first diagnostic device and the first vehicle). The first security verification can be performed using a symmetric key authentication algorithm or an asymmetric key authentication algorithm, depending on the specific content of the second information. For example, the second information can be a temporary key or a device security certificate. After the first security verification passes, the first device can request the second ECU to perform a second security verification between the second ECU and the first device, such as performing the second security verification based on a symmetric key authentication algorithm. Furthermore, if the second security verification passes, the first device allows the first diagnostic device to access the second ECU on the target vehicle and acts as an intermediary device in subsequent data transmission between the first diagnostic device and the second ECU.

[0187] In some embodiments, the second information is the same as the first information. That is, the first information assigned by the server to the first diagnostic device is used by the first diagnostic device to access the first vehicle. Based on this information, the first diagnostic device cannot pass the first security verification of the first diagnostic device by other vehicles, and therefore cannot successfully access other vehicles based on this information. Alternatively, even if a third party obtains the first information, it cannot pass the first security verification of the first vehicle or other vehicles on the third party based on this information, and therefore cannot successfully access the first vehicle or other vehicles based on this information. In this embodiment, the first information and the second information can be temporary keys or device security certificates.

[0188] In some embodiments, the second information is different from the first information. That is, the first information assigned by the server to the first diagnostic device is used by the first diagnostic device to access the first ECU on the first vehicle. If the first diagnostic device requests access to other ECUs on the first vehicle based on this first information, it will not pass the first vehicle's first security verification of the first diagnostic device, and therefore the first diagnostic device will not be able to successfully access other ECUs on the first vehicle. Alternatively, if the first diagnostic device requests access to ECUs on other vehicles based on this first information, it will not pass the other vehicle's first security verification of the first diagnostic device, and therefore the first diagnostic device will not be able to successfully access ECUs on other vehicles based on this first information. Alternatively, even if a third party obtains this first information, it will not be able to pass the first vehicle's or other vehicle's first security verification of the third party based on this first information, and therefore the third party will not be able to successfully access ECUs on the first vehicle or other vehicles based on this first information. In this embodiment, the first information and the second information may be temporary keys.

[0189] Alternatively, when another diagnostic device (e.g., a second diagnostic device, which is different from the first diagnostic device) needs to access a specific ECU (e.g., a third ECU, which may be the same as or different from the first ECU) in a target vehicle (e.g., the first vehicle), a similar method can be employed to first perform a first security verification between the first device and the second diagnostic device, followed by a second security verification between the first device and the third ECU. Upon passing both the first and second security verifications, the diagnostic device is permitted access to the third ECU. For example, when the second diagnostic device needs to access the third ECU in the first vehicle, it can request third information from a server for the first security verification and send an access request (e.g., a third access request) carrying the third information to the first device, requesting access to the third ECU. Upon 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 based on the third information carried in the third access request (e.g., the third information indicates a valid binding relationship between the second diagnostic device and the first vehicle). The first security verification can be performed using a symmetric key authentication algorithm or an asymmetric key authentication algorithm, depending on the specific content of the third information. For example, the third information can be a temporary key or a device security certificate. After the first security verification passes, the first device can request the third ECU to perform a second security verification between the first device and the third ECU, such as performing the second security verification based on a symmetric key authentication algorithm. Furthermore, if the second security verification passes, the first device allows the second diagnostic device to access the third ECU on the target vehicle and acts as an intermediary device in subsequent data transmission between the diagnostic device and the third ECU.

[0190] In this embodiment, the third information is different from the first information. That is, the first information assigned by the server to the first diagnostic device is used by the first diagnostic device to access the first vehicle, and the third information assigned to the second diagnostic device is used by the second diagnostic device to access the first vehicle. The second diagnostic device cannot pass the vehicle's first security verification of the first diagnostic device based on the first information, and therefore cannot successfully access the vehicle based on the first information. Similarly, the first diagnostic device cannot pass the vehicle's first security verification of the first diagnostic device based on the third information, and therefore cannot successfully access the vehicle based on the third information. In this embodiment, the first and second information can be either temporary keys or device security certificates.

[0191] Based on the security access method provided in Example 1 of the present application, the first device can provide a diagnostic agent isolation service. When the diagnostic device wants to access the target ECU on a target vehicle, a first security verification is performed 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 is passed, 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.

[0192] It can be understood that in this solution, on the one hand, by performing authorization management in the diagnostic device and vehicle dimensions (such as between a diagnostic device and a vehicle), as shown in Figure 9, 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 3 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, as well as a one-to-one first security verification of the vehicle's authority for the diagnostic device to access the vehicle, can avoid the impact of a vehicle on other vehicles when it has a safety hazard; 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 therefore will not affect the safety of other vehicles.

[0193] On the other hand, the isolation effect provided by the first device in the target vehicle can prevent the diagnostic equipment 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 equipment, so there is no risk of leakage of the key of the ECU in the target vehicle, thereby avoiding affecting the safety of the target vehicle and other vehicles.

[0194] Furthermore, since the first information, such as the temporary key / device security certificate, is typically valid for a limited period of time, even if a third party obtains the temporary key / device security certificate, by the time the third party maliciously accesses the target vehicle based on the first information, the temporary key / device security certificate is likely to have expired, thus not impacting the target vehicle's security. Furthermore, 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 it, thus not impacting the security of other vehicles.

[0195] As described above, the first information in the embodiment of the present application can be a temporary key or a device security certificate. The following will specifically introduce the secure access method described in Example 1 by taking the first information being a temporary key or a device security certificate as an example.

[0196] Please refer to Figure 10, which uses the system architecture shown in Figure 4 as an example to illustrate a schematic diagram of a secure access process provided by an embodiment of the present application. The diagnostic device shown in Figure 10 may be the diagnostic device shown in Figure 8, the diagnostic proxy service shown in Figure 10 may be a service provided by the first device shown in Figure 8, the key management service shown in Figure 10 may be a service provided by the first device shown in Figure 8 or a service provided by other modules or devices in the vehicle (the following examples take the diagnostic proxy service and key management service both provided by the first device as an example), and the target ECU shown in Figure 8 may be a telematics box (T-BOX), a mobile data center (MDC), a vehicle domain controller (VDC), a vehicle integration unit (VIU), a cockpit domain controller (CDC), or other ECUs shown in Figure 10.

[0197] As shown in Figure 10, when the diagnostic device needs to access the target ECU in the target vehicle, it can apply for a temporary key from the server (as shown in sequence number 1 in Figure 10). When the temporary key assigned by the server is received (as shown in sequence number 2 in Figure 10), the diagnostic device can store the temporary key (as shown in sequence number 3 in Figure 10) and send the temporary key to the target vehicle (as shown in sequence number 4 in Figure 10), such as to the diagnostic agent service on the target vehicle. When receiving the temporary key, the diagnostic agent service can store the temporary key in the temporary key storage and calculation service (as shown in sequence number 5 in Figure 10). When receiving an access request from the diagnostic device (such as access to the target ECU) (as shown in sequence number 6 in Figure 10), the diagnostic agent service can call the temporary key storage and calculation service (as shown in sequence number 7 in Figure 10) and perform a first off-vehicle security verification of the diagnostic device's access to the target vehicle based on the temporary key (as shown in sequence number 8 in Figure 10). If the first security verification passes, the diagnostic proxy service can call the key management service (see Figure 10, number 9) to obtain the ECU key and use it to perform a MAC calculation to request a second in-vehicle security verification from the target ECU based on the MAC (see Figure 10, number 10). If the target ECU passes the second security verification of the diagnostic proxy service's access rights, the diagnostic proxy service can unlock the target ECU (see Figure 10, number 11). The diagnostic device can then successfully access the target ECU.

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

[0199] It can be understood that based on the security access process shown in Figure 10, it is assumed that the diagnostic device has accessed multiple ECUs in multiple vehicles and holds the corresponding temporary keys, as shown in Figure 11: 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 MDC_KEY Temporary 1 shown in Figure 11 is the temporary key assigned by the server to the diagnostic device for accessing the MDC in vehicle 1, MDC_KEY Temporary 2 is the temporary key assigned by the server to the diagnostic device for accessing the MDC in vehicle 2, MDC_KEY Temporary 3 is the temporary key assigned by the server to the diagnostic device for accessing the MDC in vehicle 3, TBOX_ KEY_temp_1 is a temporary key assigned by the server to the diagnostic device for accessing the TBOX in vehicle 1, TBOX_KEY_temp_2 is a temporary key assigned by the server to the diagnostic device for accessing the TBOX in vehicle 2, and TBOX_KEY_temp_3 is a temporary key assigned 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 temporary key, it cannot successfully access other ECUs of the vehicle or other vehicles based on the temporary key, and therefore will not have any impact on the security of other ECUs on the vehicle or other vehicles. In addition, since temporary keys usually have a validity period, even if a third party obtains the temporary key corresponding to a vehicle, when the third party maliciously accesses the vehicle based on this temporary key, the temporary key is likely to have expired, and therefore will not have any security impact on the security of the vehicle.

[0200] Please refer to Figure 12, which takes the first information being 27 service key as an example, and shows a flowchart of a secure access method provided in an embodiment of the present application.

[0201] As shown in FIG. 12 , S801 may specifically include: the diagnostic device applies for a temporary 27 service key from the server.

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

[0203] 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 by PK based on the locally stored SK corresponding to PK, obtain and store the obtained 27 service key, wherein the diagnostic device obtains the 27 service key for subsequent security verification (such as the first security verification) when participating in the diagnostic device access to 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 information when sending it to the diagnostic device in the future to ensure the security of the information transmission process. The 27 service key encrypted based on Prek is used for the diagnostic device to carry when sending an access request to the target vehicle. The server can also send the Prek encryption method to the diagnostic agent service in the target vehicle so that the diagnostic agent service presets the corresponding decryption method for subsequent parsing of the Prek-encrypted information.

[0204] As shown in FIG. 12 , S803 may specifically include: the diagnostic device sends the 27 service key encrypted based on Prek and the identifier of the target ECU to the diagnostic proxy service in the target vehicle.

[0205] As shown in Figure 12, S804 may specifically include: first, the diagnostic proxy service decrypts the 27 service key encrypted by 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 a first MAC based on its stored 27 service key and 27 service seed, and receives a second MAC from the diagnostic device based on its stored 27 service key and the 27 service seed received from the diagnostic proxy service. Finally, the diagnostic proxy service performs a first security verification between the diagnostic proxy service and the diagnostic device by comparing whether the second MAC is consistent with the first MAC.

[0206] As shown in Figure 12, S805 may specifically include: when the first security verification is passed, the diagnostic agent service requests the key management service to perform 27 service calculation; correspondingly, the key management service can calculate the third MAC based on the stored target ECU key and the 27 service seed obtained from the diagnostic agent service and send it to the diagnostic agent service.

[0207] As shown in FIG. 12 , S806 may specifically include: the diagnosis agent service sends the third MAC to the target ECU to request the target ECU to perform a second security verification between the diagnosis agent service and the target ECU.

[0208] As shown in Figure 12, S807 may specifically include: the target ECU calculating a fourth MAC based on the target ECU's secret key and the 27 service seed, and then performing a second security verification between the diagnostic agent service and the target ECU by comparing the fourth MAC with the third MAC to determine whether they are consistent. If the second security verification passes, the target ECU may unlock and send a successful unlock message to the diagnostic agent service, allowing the diagnostic agent to send a successful unlock message to the diagnostic device, and then proceed to step S808.

[0209] Please refer to Figure 13, which uses the system architecture shown in Figure 4 as an example to illustrate another secure access process schematic diagram provided by an embodiment of the present application. The diagnostic device shown in Figure 13 may be the diagnostic device shown in Figure 8, the diagnostic proxy service shown in Figure 13 may be a service provided by the first device shown in Figure 8, the key management service shown in Figure 13 may be a service provided by the first device shown in Figure 8 or a service provided by other modules or devices in the vehicle (the following examples take the diagnostic proxy service and key management service both provided by the first device as an example), and the target ECU shown in Figure 3 may be an ECU such as the T-BOX, MDC, VDC, VIU, or CDC shown in Figure 10.

[0210] As shown in Figure 13, after the diagnostic device obtains authorization to access the target vehicle from the server, the server can send a root certificate (serial number 1 in Figure 13) to the target vehicle. The root certificate includes the identifier of the diagnostic device with access to the target vehicle. The root certificate can be used by the diagnostic agent service to verify the legitimacy of the access request. After receiving the root certificate, the diagnostic agent service on the target vehicle can pre-set the root certificate (serial number 2 in Figure 13). 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 (serial number 3 in Figure 13). Upon receiving the device security certificate issued by the server (serial number 4 in Figure 13), the diagnostic device can store the device security certificate (serial number 5 in Figure 13). Upon receiving an access request from the diagnostic device (such as access to the target ECU) (serial number 6 in Figure 13), the diagnostic agent service can perform a first off-vehicle security verification of the diagnostic device's access authority to the target vehicle based on the device security certificate carried in the access request and the pre-set root certificate (serial number 7 in Figure 13). If the first security verification passes, the diagnostic proxy service can call the key management service (see Figure 13, number 8) to obtain the ECU key and use it to calculate a MAC address (MAC) to request a second in-vehicle security verification from the target ECU based on the MAC address (see Figure 13, number 9). If the target ECU passes the second security verification of the diagnostic proxy service's access rights, the diagnostic proxy service can unlock the target ECU (see Figure 13, number 10). The diagnostic device can then successfully access the target ECU.

[0211] It can be understood that based on the security access process shown in Figure 13, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and saved corresponding device security certificates, as shown in Figure 14, the diagnostic device 1 saves the device security certificate 1 for accessing vehicle 1, the diagnostic device 2 saves the device security certificate 2 for accessing vehicle 1, the diagnostic device 3 saves the device security certificate 3 for accessing vehicle 1, and the diagnostic device 4 saves the device security certificate 4 for accessing vehicle 1. Since each device security certificate is only used to perform 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 the vehicle or other vehicles based on the device security certificate, and therefore will not cause any impact on the safety of the vehicle and other vehicles.

[0212] In addition, the solution of managing the diagnostic device's access to the vehicle by pre-setting 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 low-end devices or components with asymmetric systems, and 29 certification service standards.

[0213] Furthermore, the solution in which the server manages the diagnostic device's access permissions to the vehicle by pre-setting the diagnostic device root certificate can also flexibly control the scope of the diagnostic device's permissions based on actual needs. For example, the server can implement strict one-to-one access from the diagnostic device to the vehicle by indicating a vehicle VIN in a device security certificate, or it can implement one-to-many access from the diagnostic device to the vehicle by indicating multiple vehicle VINs in a device security certificate.

[0214] Please refer to Figure 15, which takes the first information being the device security certificate as an example to illustrate an interactive process of secure access provided by an embodiment of the present application.

[0215] As shown in FIG. 15 , S801 may specifically include: the diagnostic device applies for a device security certificate from the server.

[0216] As shown in Figure 15, S802 may specifically include: the server issuing a device security certificate to the diagnostic device, where the device security certificate carries the Vehicle Identification Number (VIN) of the vehicle that the diagnostic device can access. In some embodiments, the device security certificate may carry a single 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.

[0217] As shown in FIG. 15 , S803 may specifically include: the diagnostic device sends a device security certificate and an identifier of the target ECU to the diagnostic agent service in the target vehicle.

[0218] As shown in Figure 15, S804 may specifically include: the diagnostic proxy service verifying the device security certificate. For example, the diagnostic proxy service may 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 pre-set root certificate. The root certificate pre-set by the diagnostic proxy service is obtained from the server.

[0219] As shown in Figure 15, S805 may specifically include: when the first security verification is passed, the diagnostic proxy service obtains a 27 service seed from the target ECU, such as obtaining the 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 a 27 service calculation; correspondingly, the key management service can calculate a 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.

[0220] As shown in FIG. 15 , S806 may specifically include: the diagnosis agent service sends the third MAC to the target ECU to request the target ECU to perform a second security verification between the diagnosis agent service and the target ECU.

[0221] As shown in Figure 15, S807 may specifically include: the target ECU calculating a fourth MAC based on the target ECU's secret key and the 27 service seed, and then performing a second security verification between the diagnostic agent service and the target ECU by comparing the fourth MAC with the third MAC to determine whether they are consistent. If the second security verification passes, the target ECU may unlock and send a successful unlock message to the diagnostic agent service, allowing the diagnostic agent to send a successful unlock message to the diagnostic device, and then proceed to step S808.

[0222] Example 2:

[0223] In Example 2, upon receiving a request from a diagnostic device to access a target ECU in a target vehicle, a first device on the target vehicle performs a first security verification between the first device and the diagnostic device based on the first information included in the access request. If the first security verification passes, the diagnostic device is allowed to access the target vehicle and acts as an intermediary device to participate in subsequent data transmission between the diagnostic device and the vehicle. The first information may be used to indicate a 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 a server for security verification.

[0224] As an example, please refer to Figure 16, which shows a schematic diagram of a secure access process provided by an embodiment of the present application, taking the diagnostic device in the intelligent driving field accessing a vehicle under the system architecture shown in Figure 4 as an example. As shown in Figure 16, when the diagnostic device needs to access the vehicle, the first device on the vehicle can perform a first security verification between the first device and the diagnostic device. During this process, the first security verification can be performed based on the first information sent by the server to the diagnostic device; after the first security verification is passed, the first device can unlock the ECU in the vehicle; thereafter, the diagnostic device can successfully access the ECU in the vehicle.

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

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

[0227] S1701: The diagnostic device sends a request message to the server in response to a triggering event for accessing a target vehicle.

[0228] 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 a target vehicle (such as the first vehicle).

[0229] As an example, the triggering event for accessing the target vehicle may be a manually triggered operation, such as an operation triggered by a diagnostician, or an event automatically triggered by the diagnostic equipment when a preset triggering condition is met. This embodiment of the present application does not make any specific limitations.

[0230] As an example, the timing for the diagnostic device described in the embodiment of the present application to send a request message to the server in response to a trigger event for accessing the target vehicle may be before the vehicle leaves the factory or after the vehicle leaves the factory, without specific limitation.

[0231] As an example, the purpose of accessing the target vehicle may be, but is not limited to, diagnosing problems, repairing problems, or performing software upgrades on one or more ECUs in the target vehicle. For example, in response to accessing the target vehicle, the diagnostic device may diagnose problems on the ECUs by reading data from one or more ECUs in the target vehicle, and repair problems or perform software upgrades on the target vehicle by modifying and / or writing data to the ECUs.

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

[0233] In an embodiment of the present application, the first information is used for security verification of the diagnostic equipment by the target vehicle, such as when the diagnostic equipment requests access to the target vehicle, a first device on the target vehicle performs a first security verification between the first device and the diagnostic equipment, wherein the essence of the first security verification is an off-vehicle security verification, and the first security verification can be used to determine whether the diagnostic equipment can legally access the target vehicle.

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

[0235] In some embodiments, the first information may be used to indicate a temporary key, such as a temporary symmetric key. As an example, the temporary key may correspond to an applicable scope and a validity period. As an example, the first information may be a 27 service key.

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

[0237] Of course, the first information may also be other information provided by the server to the diagnostic device for security verification, which is not specifically limited in the embodiment of the present application.

[0238] In some embodiments, the first information sent by the server to the diagnostic device may be encrypted first information, such as first information encrypted by a first encryption method. The first information encrypted by the first encryption method is used by the diagnostic device to be directly carried in the access request when sending an access request to the target vehicle, so as to avoid malicious tampering with the temporary key or device security certificate indicated by the first information. At the same time, the server sends a first decryption method to the target vehicle, wherein the first decryption method corresponds to the first encryption method, and the first decryption method is used by 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 by the diagnostic device to decrypt the fourth information when receiving the fourth information encrypted based on the second encryption method, wherein the information obtained by decrypting the fourth information (such as a temporary key) is used to participate in the security verification (such as the first security verification) when the diagnostic device accesses the target vehicle.

[0239] Exemplarily, the first encryption method is a Prek encryption method, and the second encryption method is a PK encryption method.

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

[0241] 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 to one or more ECUs in the target vehicle, etc.

[0242] In some embodiments, the first information received by the diagnostic device from the server is encrypted first information, such as first information encrypted using a first encryption method. The diagnostic device may include the first information encrypted using the first encryption method in an access request and send it to the first device. Typically, if the first information received by the diagnostic device from the server is encrypted using the first encryption method, the diagnostic device will also receive fourth information from the server. The fourth information is the same as the information indicated by the first information (such as a temporary key). The fourth information is used to participate in security verification (such as the first security verification) when the diagnostic device accesses the target vehicle. The fourth information differs from the first information in that the first information is encrypted using the first encryption method.

[0243] 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 information therein, such as a temporary key.

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

[0245] The first security verification is to verify the authority 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.

[0246] 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 a symmetric key authentication algorithm. For example, assuming that the first information carried in the access request is a temporary symmetric key, such as a 27 service key, the first device may 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.

[0247] In some embodiments, an access request is used to access a target ECU in a target vehicle, and the access request carries an identifier of the target ECU. In this case, when verifying a temporary symmetric key according to a symmetric key authentication algorithm, as a possible implementation method, the first device can obtain a service seed (such as 27 service seed) from the target ECU based on 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 a first MAC based on the service key and the service seed, and receive a second MAC calculated by the diagnostic device based on 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.

[0248] As an example, the service seed (such as the 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.

[0249] 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 using an asymmetric key authentication algorithm. For example, assuming 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 using the asymmetric key authentication algorithm to perform the first security verification between the first device and the diagnostic device.

[0250] When verifying the device security certificate according to the asymmetric key authentication algorithm, as a possible implementation method, the first device may first verify the legitimacy of the device security certificate (such as the 29 service certificate). If the legitimacy verification passes (such as the device security certificate is legal), the first device may verify whether the identification code carried in the device security certificate is consistent with the vehicle identification code in the root certificate stored in the first device. For example, if the VIN carried in the device security certificate includes the VIN in the root certificate, the first device may determine that the device security certificate verification has passed, i.e., the first security verification has passed; if the VIN carried in the device security certificate does not include the VIN in the root certificate, the first device may determine that the device security certificate verification has failed, i.e., the first security verification has failed.

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

[0252] As an example, after the first security verification passes, the first device may 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 may unlock one or more ECUs in the target vehicle so that the diagnostic device can successfully access the ECUs in the target vehicle.

[0253] As an example, the operation indicated by the access request performed by the first device 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 diagnostic device's modification of the data in one or more ECUs in the target vehicle, and accepting the diagnostic device's writing of data to one or more ECUs in the target vehicle.

[0254] In some embodiments, the access request is used to access the target ECU in the target vehicle. In this case, the first device may perform the operation indicated by the access request, including but not limited to one or more of the following: sending the target data in the target ECU to the diagnostic device, accepting the diagnostic device's modification of the data in the target ECU, and accepting the diagnostic device's writing of data to the target ECU.

[0255] For detailed introductions to S1701-S1705, please refer to the above introductions to S801-S804 and S808, which will not be repeated here.

[0256] In some embodiments, if the second security verification fails, the first device may reject the access request of the diagnostic device, such as 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 vehicle or does not allow the diagnostic device to access the target ECU.

[0257] Similar to the process shown in FIG. 17 , when another diagnostic device (e.g., a second diagnostic device, which is different from the first diagnostic device) requires access to a target vehicle (e.g., the first vehicle), a similar method can be used to perform a first security verification between the first device and the second diagnostic device. Upon passing the first security verification, the diagnostic device is allowed access to the first vehicle. For example, when the second diagnostic device requires access to the first vehicle, it can request third information from the server for the first security verification and send an access request (e.g., a third access request) containing the third information to the first device. Upon receiving the third access request from the second diagnostic device, the first device performs a first security verification between the first device and the second diagnostic device based on the third information contained in the third access request (e.g., the third information indicates the legal binding relationship between the second diagnostic device and the first vehicle). The first security verification can be performed using a symmetric key authentication algorithm or an asymmetric key authentication algorithm, depending on the specific content of the third information. For example, the third information can be a temporary key or a device security certificate. After passing the first security verification, the first device can allow the second diagnostic device access to the first vehicle and act as an intermediary in subsequent data transmissions between the diagnostic device and the first vehicle.

[0258] In this embodiment, the third information is different from the first information. That is, the first information assigned by the server to the first diagnostic device is used by the first diagnostic device to access the first vehicle, and the third information assigned to the second diagnostic device is used by the second diagnostic device to access the first vehicle. The second diagnostic device cannot pass the vehicle's first security verification of the first diagnostic device based on the first information, and therefore cannot successfully access the vehicle based on the first information. Similarly, the first diagnostic device cannot pass the vehicle's first security verification of the first diagnostic device based on the third information, and therefore cannot successfully access the vehicle based on the third information. In this embodiment, the first and second information can be either temporary keys or device security certificates.

[0259] It can be understood that based on the security access method provided in Example 2 of the present application, on the one hand, by performing authorization management in the diagnostic device and vehicle dimensions (such as between a diagnostic device and a vehicle), as shown in Figure 9, 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 a one-to-one first security verification of the vehicle's authority for the diagnostic device to access the vehicle, can avoid the impact of a vehicle on other vehicles when it has a safety hazard; 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 therefore will not affect the safety of other vehicles.

[0260] On the other hand, the isolation effect provided by the first device in the target vehicle can prevent the diagnostic equipment 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 equipment, so there is no risk of leakage of the key of the ECU in the target vehicle, thereby avoiding affecting the safety of the target vehicle and other vehicles.

[0261] Furthermore, since the first information, such as the temporary key / device security certificate, is typically valid for a limited period of time, even if a third party obtains the temporary key / device security certificate, by the time the third party maliciously accesses the target vehicle based on the first information, the temporary key / device security certificate is likely to have expired, thus not impacting the target vehicle's security. Furthermore, 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 it, thus not impacting the security of other vehicles.

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

[0263] FIG18 illustrates an interaction diagram of a secure access process provided by an embodiment of the present application, using the example of a first information being a 27 service key and an access request being used to access a target ECU in a target vehicle. As shown in FIG18 , the method may include steps S1701-S1705. For an introduction to steps S1701-S1705, refer to the descriptions of steps S801-S804 and S808 in FIG12 above, respectively, and will not be repeated here.

[0264] It can be understood that based on the security access process shown in Figure 18, assuming that the diagnostic device has accessed multiple ECUs in multiple vehicles and holds corresponding temporary keys, since each temporary key is only used to access a specific vehicle, or to perform the corresponding off-vehicle first security verification when accessing a specific ECU on a specific vehicle, even if a third party obtains a temporary key, it cannot successfully access other ECUs of the vehicle or other vehicles based on the temporary key, and therefore will not have any impact on the security of other ECUs on the vehicle or other vehicles. In addition, since temporary keys usually have a validity period, even if a third party obtains the temporary key corresponding to a vehicle, when the third party maliciously accesses the vehicle based on this temporary key, the temporary key is likely to have expired, and therefore will not have any security impact on the security of the vehicle.

[0265] FIG19 illustrates an interaction diagram of a secure access process provided by an embodiment of the present application, using the example of a device security certificate as the first information and an access request for accessing a target ECU in a target vehicle. As shown in FIG19 , the method may include steps S1901-S1905. For an introduction to steps S1901-S1905, refer to the descriptions of steps S801-S804 and S808 in FIG15 above, respectively, and will not be repeated here.

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

[0267] In addition, the solution of managing the diagnostic device's access to the vehicle by pre-setting 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 low-end devices or components with asymmetric systems, and 29 certification service standards.

[0268] Furthermore, the solution in which the server manages the diagnostic device's access permissions to the vehicle by pre-setting the diagnostic device root certificate can also flexibly control the scope of the diagnostic device's permissions based on actual needs. For example, the server can implement strict one-to-one access from the diagnostic device to the vehicle by indicating a vehicle VIN in a device security certificate, or it can implement one-to-many access from the diagnostic device to the vehicle by indicating multiple vehicle VINs in a device security certificate.

[0269] Example 3:

[0270] In Example 3, upon receiving an access request from the diagnostic device to access the target ECU in the target vehicle, the 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 subsequent data transmission between the diagnostic device and the target ECU as an intermediate device.

[0271] As an example, please refer to Figure 20, which illustrates a schematic diagram of a secure access process provided by an embodiment of the present application, using the example of a diagnostic device in the intelligent driving field accessing a target ECU in a vehicle under the system architecture shown in Figure 4. As shown in Figure 20, when the diagnostic device needs to access the target ECU on the vehicle, the first device on the vehicle can act as a proxy device to coordinate with the target ECU to perform a 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.

[0272] 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-mentioned second security verification based on the symmetric key authentication algorithm shown in Figure 20, or it can perform the above-mentioned second security verification based on other security authentication algorithms. The embodiments of this application do not make specific limitations.

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

[0274] S2101: The first device receives an access request from a diagnostic device.

[0275] The access request carries the identifier of the target ECU, and 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 to the target ECU, etc.

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

[0277] 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.

[0278] In some embodiments, the first device may provide a diagnostic agent service and a key management service. In this case, the first device may invoke the key management service to obtain a stored key of the target ECU (e.g., target ECU KEY), and then calculate the third MAC based on the key of the target ECU and a service seed corresponding to the target ECU (e.g., 27 service seed).

[0279] In other embodiments, the first device does not provide a key management service, and the key management service is provided by another module or device, such as a key management module. In this case, the first device can send the service seed corresponding to the target ECU to the key management module and request the key management module to perform a MAC calculation. The key management module can call the key management service to obtain the stored key of the target ECU (such as the target ECU KEY), calculate a third 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 send the third MAC to the first device.

[0280] Among them, the key management service can be used to store in-vehicle keys (such as ECU keys, etc.) and perform related calculations (such as MAC calculations). For example, each ECU on a vehicle corresponds to an ECU KEY. It should be noted that the in-vehicle keys (such as ECU keys, etc.) described in the embodiments of the present application are invisible to the diagnostic equipment. Based on this, there is no risk of leakage of the ECU keys in the target vehicle, thereby avoiding the impact on the safety of the target vehicle and other vehicles.

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

[0282] 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.

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

[0284] The second security verification is a verification of the authority of the first device, such as verifying the authority of the first device to unlock the target ECU. The second security verification can determine whether the first device can legally unlock the target ECU.

[0285] In some embodiments, the first control module may perform a second security verification based on a symmetric key authentication algorithm. When performing the second security verification based on the symmetric key authentication algorithm, as an example, the target ECU may calculate a fourth MAC based on the target ECU's key and a service seed (e.g., a 27 service seed) corresponding to the target ECU, and then verify whether the fourth MAC is identical to the third MAC. For example, if the fourth MAC is identical to the third MAC, the target ECU may determine that the second security verification has passed; if the fourth MAC is different from the third MAC, the target ECU may determine that the second security verification has failed.

[0286] S2105: After the second security verification is passed, the target ECU executes the operation indicated by the access request.

[0287] As an example, after the second security verification is passed, the first device may unlock the target ECU so that the diagnostic equipment can successfully access the target ECU.

[0288] As an example, the operations indicated by the target ECU executing the access request may include but are not limited to one or more of the following: sending target data in the target ECU to the diagnostic device, accepting modifications to the data in the target ECU by the diagnostic device, and accepting writing data to the target ECU by the diagnostic device.

[0289] When transmitting target data from the target ECU to the diagnostic device, the target ECU may transmit the target data directly or indirectly via the first device, without specific limitations. Similarly, when accepting modifications to data in the target ECU by the diagnostic device or accepting data written to the target ECU by the diagnostic device, the diagnostic device may directly modify the data in the target ECU / write data to the target ECU, or indirectly modify the data in the target ECU / write data to the target ECU via the first device, without specific limitations.

[0290] 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 indicating that the target vehicle does not allow the diagnostic device to access the target ECU.

[0291] For the specific introduction of S2101-S2105, please refer to the introduction of S803 and S805-S808 above, which will not be repeated here.

[0292] Similar to the process shown in Figure 21, when the diagnostic device (such as the first diagnostic device) has a need to access other ECUs (such as the second ECU, which is different from the first ECU) in the target vehicle (such as the first vehicle), a similar method can also be used to perform a second security verification between the first device and the second ECU, and the diagnostic device is allowed to access the second ECU when the second security verification is passed. Exemplarily, the diagnostic device can send an access request (such as a second access request) to the first device when there is a need to access the second ECU in the first vehicle. Upon receiving the second access request from the first diagnostic device, the first device can request the second ECU to perform a second security verification between the second ECU and the first device, such as performing a second security verification based on a symmetric key authentication algorithm. Furthermore, 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 in subsequent data transmission between the first diagnostic device and the second ECU as an intermediate device.

[0293] Alternatively, when another diagnostic device (such as a second diagnostic device, which is different from the first diagnostic device) needs to access a certain ECU (such as a third ECU, which may be the same as or different from the first ECU) in a target vehicle (such as the first vehicle), a similar method can be used to perform a second security verification between the first device and the third ECU. When both the first and second security verifications pass, the diagnostic device is allowed to access the third ECU. For example, when the second diagnostic device needs 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. Upon receiving the third access request from the second diagnostic device, the first device can request the third ECU to perform a second security verification between the third ECU and the first device, such as performing a second security verification based on a symmetric key authentication algorithm. Furthermore, 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 subsequent data transmission between the diagnostic device and the third ECU as an intermediary device.

[0294] As an example, please refer to Figure 22, which shows an interaction diagram of a secure access process provided by an embodiment of the present application. As shown in Figure 22, the method may include S2101-S2105. For the relevant introduction of S2101-S2105, please refer to the introduction of S803 and S805-S808 in Figure 12 above, which will not be repeated here.

[0295] It can be understood that based on the secure access method provided in Example 3 of the present application, the isolation effect provided by the first device in the target vehicle can prevent the diagnostic equipment 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 equipment, so there will be no risk of leakage of the key of the ECU in the target vehicle, thereby avoiding affecting the safety of the target vehicle and other vehicles.

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

[0297] The processor may be a central processing unit (CPU) or other specific integrated circuit. The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. In practical applications, the diagnostic device / server / first apparatus may also include multiple processors, each of which may include one or more processor cores.

[0298] Memory is typically used to store executable program code for computer programs. Executable program code includes instructions. The processor executes the instructions stored in the memory to execute various functional applications and data processing functions of the diagnostic device / server / first device. The memory may include a program storage area and a data storage area. The program storage area may store an operating system, at least one application required for a function, and the data storage area may store data generated during use of the diagnostic device / server / first device.

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

[0300] It is understood that the structure shown in FIG. 23 of the present application does not constitute a specific limitation on the diagnostic device / server / first apparatus. In other embodiments of the present application, the diagnostic device / server / first apparatus may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently, and the components may be implemented in hardware, software, or a combination of software and hardware.

[0301] It should be understood that the various schemes 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 referenced or explained with each other in the various embodiments, without limitation to this.

[0302] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order 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.

[0303] It is understandable that, in order to implement the functions of any of the above-mentioned embodiments, the diagnostic equipment / server / first device, etc. includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

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

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

[0306] The steps of the method or algorithm described in conjunction with the embodiments of the present application can be implemented in hardware or by executing software instructions by a processor. The software instructions can be composed of corresponding software modules, which can be stored in 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, mobile hard disk, compact disc read-only memory (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an application specific integrated circuit (ASIC). In addition, the ASIC can be located in a diagnostic device / server / first device, etc. Of course, the processor and storage medium can also exist as discrete components.

[0307] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be 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, 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 authority of the first diagnostic device to access the first vehicle based on the first information; When the first 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 vehicle.

2. The method according to claim 1, characterized in that: The first device has a key of an electronic control unit ECU on the first vehicle, and the first diagnostic equipment 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 is used to indicate a temporary key, and the first security verification of the authority 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, where the first decryption method is indicated by the server, and the first decryption method corresponds to the first encryption method; The temporary key is verified 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 a first ECU on the first vehicle, the temporary key is a 27 service key, and the verification of the temporary key based on a symmetric key authentication algorithm includes: Obtaining 27 a service seed from the first ECU and sending the 27 service seed to the first diagnostic device; A first message authentication code MAC is calculated 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; Verify whether the second MAC is the same as the first MAC; The first feedback message is also used to indicate that the first diagnostic device is allowed 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 the first security verification of the authority of the first diagnostic device to access the first vehicle based on the first information includes: Verifying the legitimacy 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.

6. The method according to claim 5, characterized in that 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.

7. The method according to any one of claims 1 to 6, characterized in that The first access request also carries an identifier of the first ECU, and the first access request is used to request access to the first ECU on the first vehicle. The method further includes: Requesting the first ECU to perform a second security verification of the first device accessing the first ECU according to the identifier of the first ECU, wherein the second security verification is performed based on a 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 comprises: Obtaining a third MAC, where the third MAC is calculated based on a stored key of the first ECU and a service seed corresponding to the first ECU, where the service seed corresponding to the first ECU is obtained from the first ECU; The third MAC is sent 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 a first feedback message to the first diagnostic device includes: When the first security verification passes and the second security verification passes, the first feedback message is sent to the first diagnostic device.

10. The method according to claim 7 or 8, characterized in that: The method further comprises: When the second security verification fails, a third feedback message is sent 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 to 10, characterized in that The method further comprises: receiving a second access request from the first diagnostic device, the second access request carrying second information and an identifier of a second ECU, the second access request being used to request access to the second ECU on the first vehicle, the second 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 authority of the first diagnostic device to access the first vehicle based on the second information; When the first security verification passes, requesting the second ECU to perform a second security verification of the first device accessing the second ECU based on the key of the second ECU, wherein the key of the second ECU is invisible to the first diagnostic device; When the second security verification passes, feedback information indicating that the first diagnostic device is allowed to access the second ECU is sent to the first diagnostic device.

12. The method according to any one of claims 1 to 11, characterized in that The method further comprises: receiving a third access request from a second diagnostic device, the third access request carrying third information and an identifier of a third ECU, the third access request being used to request access to the third ECU on the first vehicle, and the third information being used to indicate a legal binding relationship between the second diagnostic device and the first vehicle; performing a first security verification on the authority of the second diagnostic device to access the first vehicle based on the third information; When the first security verification passes, requesting 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, wherein the key of the third ECU is invisible to the second diagnostic device; When the second security verification passes, feedback information indicating that the second diagnostic device is allowed to access the third ECU is sent to the second diagnostic device.

13. A secure access method, characterized in that: Applied to diagnostic equipment, the method comprises: Sending a request message to the server for accessing the first vehicle; receiving first information from the server, the first information being used to indicate a legal binding relationship between the diagnostic device and the first vehicle; A first access request is sent 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 access request carries the first information.

14. The method according to claim 13, characterized in that The first device has a key of the ECU on the first vehicle, and the diagnostic equipment 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 an identifier of a first ECU, and the first access request is used to request access to a first ECU on the first vehicle.

16. The method according to any one of claims 13 to 15, characterized in that The first information is information encrypted based on a first encryption method, and the method further includes: receiving fourth information from the server, the fourth information being a temporary key encrypted based on the second encryption method; decrypting 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 the second decryption method corresponds to the second encryption method; The temporary key acquired based on decrypting the fourth information participates in a first security verification of the authority of the diagnostic device to access the first vehicle by the first apparatus.

17. The method according to claim 16, characterized in that The temporary key is a 27 service key, and the temporary key obtained based on decrypting the fourth information participates in a first security verification of the first device's authority to access the first vehicle by the first diagnostic equipment, including: requesting the first device for a service seed 27 of the first ECU; receiving 27 a service seed of the first ECU from the first device; Calculate a second MAC according to the 27 service key and the 27 service seed; The second MAC is sent to the first device, where the second MAC is used by the first device to perform the first security verification.

18. The method according to any one of claims 13 to 15, characterized in that: The first information is a device security certificate; 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 to 18, characterized in that: The method further comprises: A second access request is sent to the first device, where the second access request is used to request access to a second ECU on the first vehicle, where the second access request carries second information and an identifier of the second ECU, where the second information is obtained from the server, and where the second information 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 to 19, characterized in that The method further comprises: sending a request message for accessing a second vehicle to the server; receiving fifth information from the server, the fifth information being used to indicate a legal binding relationship between the diagnostic device and the second vehicle, the fifth information being different from the first information; A third access request is sent to a second device on the second vehicle, where the third access request is used to request access to the second vehicle, and the third access request carries the fifth information.

21. A secure access method, characterized in that: Applied to a server, the method comprises: receiving a request message from a first diagnostic device to access a first vehicle; First information is sent 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 used for the first diagnostic device to directly carry when sending an access request to the first vehicle; the method further includes: Sending a first decryption method to a first device on the first vehicle, the first decryption method corresponding to the first encryption method, the first decryption method being used for the first device to decrypt the first information when receiving the first information encrypted based on the first encryption method; Sending fourth information to the first diagnostic device, where the fourth information is a temporary key encrypted based on the second encryption method; A second decryption method is sent to the first diagnostic device, where the second decryption method corresponds to the second encryption method. The second decryption method is used by the first diagnostic device to decrypt the fourth information to obtain a temporary key when receiving the fourth information encrypted based on the second encryption method. The temporary key obtained by decrypting the fourth information is used to participate in 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; 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.

24. The method according to any one of claims 21 to 23, characterized in that The method further comprises: receiving a request message for accessing a second vehicle from a second diagnostic device; Sending 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: A first device applied to a first vehicle, the method comprising: sending a fourth access request to the first ECU on the first vehicle according to an instruction of the first diagnostic device, the fourth access request being used to request a second security verification of the first device accessing the first ECU, the fourth access request carrying a third MAC, wherein the second security verification is performed based on a 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.

26. The method according to claim 25, characterized in that The first device has a key of the ECU on the first vehicle, and the first diagnostic equipment 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 comprises: The third MAC is obtained, where the third MAC is calculated based on the key of the first ECU and a service seed corresponding to the first ECU, where the service seed corresponding to the first ECU is obtained from the first ECU.

28. The method according to any one of claims 25 to 27, characterized in that Before sending the fourth access request to the first ECU, the method further includes: receiving a first access request from the first diagnostic device for requesting access to the first ECU, the first access request carrying first information and an identifier of the first ECU, the first information being used to indicate a legal binding relationship between the first diagnostic device and the first vehicle; A first security verification is performed on the authority 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, the first information is used to indicate a temporary key, and the first security verification of the authority 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, where the first decryption method is indicated by the server, and the first decryption method corresponds to the first encryption method; The temporary key is verified based on a symmetric key authentication algorithm to perform the first security verification.

30. The method according to claim 29, characterized in that The temporary key is a 27 service key, and the verification of the temporary key based on a symmetric key authentication algorithm includes: Obtaining 27 a service seed from the first ECU and sending the 27 service seed to the first diagnostic device; Calculate a first 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; Verify whether the second MAC is the same as the first MAC.

31. The method according to claim 28, characterized in that The first information is a device security certificate, and the first security verification of the authority of the first diagnostic device to access the first vehicle based on the first information includes: Verifying the legitimacy 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, characterized in that 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. A device, characterized in that: The device comprises: Memory for storing computer program instructions and data; A processor, configured to execute the computer program instructions to support the apparatus to implement the method as described in any one of claims 1-12 or 25-32.

34. A diagnostic device, characterized in that The diagnostic equipment comprises: Memory for storing computer program instructions and data; A processor, configured to execute the computer program instructions to support the diagnostic device to implement the method as described in any one of claims 13-20.

35. A server, characterized in that: The server comprises: Memory for storing computer program instructions and data; A processor, configured to execute the computer program instructions to support the server in implementing the method as described in any one of claims 21-24.

36. A security verification system, characterized in that: The security verification system includes the device as described in claim 33 and the server as described in claim 35.

37. A vehicle, characterized in that: The vehicle comprises the apparatus of claim 33 and one or more ECUs.

38. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, which, when executed by a processing circuit, implement the method according to any one of claims 1-12, 13-20, 21-24 or 25-32.

39. A computer program product comprising instructions, characterized in that When the computer program product is run on a computer, the computer is caused to perform the method according to any one of claims 1-12, 13-20, 21-24 or 25-32.

Images