CN117579287A

CN117579287A - Vehicle safety access method, system and related device

Info

Publication number: CN117579287A
Application number: CN202210945002.2A
Authority: CN
Inventors: 余舟毅; 侯林; 张作强
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-08-08
Filing date: 2022-08-08
Publication date: 2024-02-20
Also published as: WO2024032438A1

Abstract

The application discloses a vehicle safety access method, a system and a related device, in the method, the diagnostic instrument and an ECU of the vehicle do not hold the same secret key for safety access authentication, or the diagnostic instrument does not hold the secret key for safety access authentication, so that the possibility of secret key leakage of the diagnostic instrument is reduced or eliminated, the reliability of safety access authentication of the diagnostic instrument and the ECU of the vehicle is improved, and the safety of the vehicle is improved.

Description

Vehicle safety access method, system and related device

Technical Field

The application relates to the field of internet of vehicles, in particular to a vehicle safety access method, a system and a related device.

Background

The automobile fault diagnosis instrument, short for diagnosis instrument, is one portable intelligent automobile fault self-checking instrument for detecting automobile fault, and may be used by the user to read the fault in the automobile electric control system and display the fault information via the display screen to find out the fault position and cause.

Among them, unified diagnostic service (Unified Diagnostic Services, UDS) is a communication protocol used in diagnostic process of vehicle electronic control unit (Electronic Control Unit, ECU) as a standardized standard of diagnostic service. Specifically, in the diagnosis process, the diagnostic apparatus may send a request to the vehicle ECU, where the request carries a diagnostic service defined by the UDS protocol, and the vehicle ECU responds based on the diagnostic service, where the response sent by the vehicle ECU to the diagnostic apparatus carries diagnostic data of the vehicle ECU.

In general, the UDS protocol provides a basic framework for diagnostic services, and fault diagnosis is performed through the UDS protocol, so that development of production line detection equipment is facilitated, and after-sales maintenance and function implementation of the Internet of vehicles are facilitated.

Disclosure of Invention

The application provides a vehicle safety access method, a vehicle safety access system and a related device, which improve the reliability of safety access authentication before diagnosis of a vehicle ECU by a diagnostic instrument.

In a first aspect, embodiments of the present application provide a vehicle security access method applied to a vehicle including a first ECU, the vehicle storing a first key temporarily valid for a first period of time, and a second key of the first ECU, the method including: the vehicle receives a first security access request sent by first equipment; the vehicle uses the first key to verify whether the first device has the right to access the first ECU or not in the first period, and only the device stored with the first key has the right to access the first ECU; after the vehicle determines that the first device has the authority, the authentication process in the vehicle is executed by using the second secret key; the vehicle sends a first message to the first device, the first message being used to indicate that the vehicle has passed the authentication of the first device; the vehicle receives a first diagnosis request sent by first equipment; in response to the first diagnostic request, the vehicle transmits diagnostic data of the first ECU to the first device.

The method provided in the first aspect is implemented, wherein the diagnostic device for diagnosing the vehicle ECU uses the ECU temporary key to perform the security access authentication, and the ECU uses the ECU temporary key to perform the security access authentication. Thus, even if an attacker steals an ECU key on the ECU, the attacker cannot impersonate the diagnostic instrument to carry out security access authentication, or even if the attacker steals an ECU temporary key on the diagnostic instrument, the attacker cannot pass the security access authentication process between the diagnostic instrument and the ECU if the effective time is exceeded because the ECU temporary key is an effective temporary key in a period of time, so that the possibility of the attacker passing the security access authentication is reduced, the reliability of the security access authentication between the diagnostic instrument and the ECU is improved, and the safety of a vehicle is enhanced.

The diagnostic instrument can initiate safety access authentication before the controlled resources in the ECU are requested to be accessed or the ECU is required to be subjected to fault diagnosis, and request the controlled resources in the ECU to be accessed or the ECU to be subjected to fault diagnosis.

With reference to the first aspect, in one implementation manner, the verifying, by the vehicle, whether the first device has the right to access the first ECU using the first key specifically includes: the method comprises the steps that a vehicle generates a first seed and sends the first seed to first equipment; the vehicle receives the first seed encrypted by the first device by using the third key; the vehicle verifies whether the first seed encrypted by the third key is consistent with the first seed encrypted by the first key; in the case of coincidence, the first device has the right to access the first ECU.

It can be seen that when both parties performing the security access authentication use the same agreed key in encrypting the seed, the security access authentication passes, so that the attacker can be prevented from forging the diagnostic apparatus to steal the data of the ECU.

With reference to the first aspect, in one implementation manner, the vehicle further includes a KMS, and the vehicle verifies whether the first device has the right to access the first ECU using the first key, specifically including: the vehicle generates a first seed through the KMS, and sends the first seed to the first device through the KMS; receiving a first seed encrypted by the first device by using the third key through the KMS; verifying whether the first seed encrypted by the third key is consistent with the first seed encrypted by the first key through the KMS; in the case of coincidence, the first device has the right to access the first ECU.

It can be seen that, in the embodiment of the application, the vehicle-mounted KMS in the vehicle can interfere with the security access authentication process between the diagnostic apparatus and the ECU, and the vehicle-mounted KMS "impersonates" the ECU to complete the security access authentication between the diagnostic apparatus and to realize the security access authentication on the diagnostic apparatus and the ECU using different keys.

With reference to the first aspect, in one embodiment, the first key is a server-generated key managed and maintained by a vendor manufacturing the component of the vehicle.

That is, the ECU temporary key may be a key generated by a trusted third party, ensuring the credibility of the source of the ECU temporary key.

With reference to the first aspect, in an implementation manner, before the vehicle receives the first secure access request sent by the first device, the method further includes: the vehicle receives an authorization file sent by the first device, wherein the authorization file comprises: the first key, the invalidation parameter, signature determined according to the first key and the invalidation parameter; wherein the revocation parameter is used to indicate a first period of time, the signature characterizing the first key and the revocation parameter in the authorization file being generated by a device trusted by the vehicle.

The vehicle acquires the ECU temporary key by acquiring the authorization file, and the vehicle can judge whether an attacker falsifies parameters in the authorization file, such as the ECU temporary key and failure parameters, in the process of transmitting the authorization file to the vehicle by the diagnostic apparatus through checking the signature in the authorization file, so that the reliability of the ECU temporary key is ensured, and the reliability of the security access authentication process between the vehicle and the diagnostic apparatus by using the ECU temporary key is further ensured.

With reference to the first aspect, in an implementation manner, before the vehicle receives the authorization file sent by the first device, the method further includes: the vehicle receives a digital certificate sent by a first device, and the digital certificate characterizes the first device as a device with a trusted identity; or the vehicle receives the authorization file sent by the first device, which specifically comprises: the vehicle receives the authorization file sent by the first device through the UDS 2904 service, and the UDS 2904 service is used to prove that the first device is an identity-trusted device.

In order to avoid that the sender of the authorization document is an attacker, the vehicle may check the identity of the opposite party before receiving the authorization document, and acquire the authorization document sent by the opposite party after determining that the opposite party is a trusted diagnostic apparatus. The diagnostic device may prove its identity by sending a digital certificate to the vehicle before sending the authorization document, or the diagnostic device may send the authorization document directly to the vehicle via a trusted approach.

With reference to the first aspect, in one implementation manner, the authorization file further includes: vehicle information indicating a vehicle, and a signature is also determined from the vehicle information.

The vehicle information may be, for example, a VIN code of the vehicle. The authorization file also comprises information indicating the vehicle to be diagnosed currently, so that an attacker can be prevented from using the ECU temporary key for carrying out a security access authentication process with other vehicles, and the reliability of the security access authentication is improved.

With reference to the first aspect, in one implementation manner, the vehicle further includes a second ECU, and a fourth key of the second ECU is further stored, and the method further includes: the vehicle receives a second security access request sent by the first device; the vehicle uses the first key to verify whether the first device has the right to access the second ECU in a first period, and only the device stored with the first key has the right to access the second ECU; after the vehicle determines that the first device has the right to access the second ECU, the authentication process in the vehicle is executed by using the fourth secret key; the vehicle sends a second message to the first device, the second message being used to indicate that the vehicle has passed the authentication of the first device; the vehicle receives a second diagnosis request sent by the first device; in response to the second diagnostic request, the vehicle transmits diagnostic data of the second ECU to the first device.

That is, the ECU keys used when the different ECUs perform the security access authentication are different, and in addition, the diagnostic apparatus may complete the security access authentication process before diagnosing the different ECUs in the vehicle using only one ECU temporary key. Thus, even if the ECU keys of different ECUs are different, the diagnostic instrument does not need to frequently acquire the ECU keys used by different ECUs when diagnosing the different ECUs, thereby effectively solving the problem that the leak generated when most of the current vehicles use the same ECU keys for the same type of ECUs of the same vehicle type, namely, the ECU key of one ECU leaks, leading to invalid security access authentication of the type of ECUs in a plurality of vehicles, and effectively improving the feasibility of popularizing 'different ECUs use different ECU keys' in the industry.

With reference to the first aspect, in one implementation, the first secure access request, the first message, the first diagnostic request, and the diagnostic data are all sent according to a communication standard of a diagnostic service for the vehicle in a universal diagnostic service UDS protocol.

That is, the interactive messages between the diagnostic apparatus and the vehicle are all communicated according to the UDS protocol standard.

In some embodiments, the first security access request may carry a diagnostic service identifier SID of the UDS protocol, where the diagnostic service identifier SID is used for a diagnostic service initiated by the diagnostic apparatus to the vehicle, where the diagnostic service initiated by the diagnostic apparatus to the vehicle is a security access service for providing a way to access a controlled resource in the vehicle or perform fault diagnosis.

In a second aspect, embodiments of the present application provide a vehicle security access method applied to a vehicle including a first ECU, the vehicle storing a second key of the first ECU, the method including: the vehicle receives a first diagnosis request sent by first equipment, wherein the first equipment is equipment trusted by the vehicle; the vehicle performs a security access authentication process of the vehicle interior using the second key; in response to the first diagnostic request, the vehicle transmits diagnostic data of the first ECU to the first device.

The method provided in the second aspect is implemented, the diagnostic instrument is no longer provided with a key for performing security access authentication, the diagnostic instrument directly proves that the diagnostic instrument is a trusted diagnostic instrument to the vehicle, and sends a diagnostic request to directly request access to resources in the ECU, while the vehicle is still in the vehicle for performing security access authentication according to the first time, and then the diagnostic data of the ECU is sent to the diagnostic instrument to be executed in response to the diagnostic request. Therefore, the possibility that the diagnostic instrument leaks the secret key for the security access authentication is eliminated, the reliability of the security access authentication between the diagnostic instrument and the ECU is improved, the ECU still communicates according to the standard of the UDS protocol, a developer does not need to adapt the ECU, the trouble that the developer coordinates with different manufacturers to change the configuration of the ECU is avoided, and the feasibility of implementation of the method on the vehicle is increased.

With reference to the second aspect, in one implementation manner, before the vehicle receives the first diagnostic request sent by the first device, the method further includes: the vehicle receives a digital certificate sent by the first device, and the digital certificate characterizes the first device as an identity trusted device.

That is, the vehicle may determine whether the identity of the diagnostic instrument is authentic by accepting the digital certificate sent by the diagnostic instrument, ensuring that the device that initiates the diagnosis to the vehicle is an authentic diagnostic instrument, and not an attacker.

With reference to the second aspect, in one embodiment, the first diagnostic request and the diagnostic data are both transmitted according to a communication standard of a diagnostic service for the vehicle in a universal diagnostic service UDS protocol.

With reference to the second aspect, in one embodiment, the vehicle further includes a second ECU, the vehicle further stores a fourth key of the second ECU, and the method further includes: the vehicle receives a second diagnosis request sent by first equipment, wherein the first equipment is equipment trusted by the vehicle; the vehicle performs a security access authentication process of the vehicle interior using the fourth key; in response to the second diagnostic request, the vehicle transmits diagnostic data of the second ECU to the first device.

That is, the ECU keys used when different ECUs perform security access authentication are different. Because the diagnostic instrument does not hold the secret key for safety access authentication anymore, the secret keys of the ECUs are different immediately, and the diagnostic instrument does not need to frequently acquire the secret keys of the ECUs used by the ECUs when diagnosing the ECUs, the leak generated when most of the current vehicles use the same secret key of the same type of ECUs of the same vehicle type, namely the secret key of the ECU leaks, is effectively solved, the safety access authentication of the ECUs of the type in a plurality of vehicles is invalid, and the feasibility of popularizing the different ECUs to use the different secret keys in the industry is effectively improved.

With reference to the first aspect or the second aspect, in one implementation manner, the vehicle further includes a KMS, and the vehicle performs an authentication process of the vehicle interior using the second key, specifically including: the vehicle is executed by the KMS and the first ECU:

the KMS sends a second secure access request to the first ECU;

the first ECU generates a second seed and sends the second seed to the KMS;

the KMS encrypts a second seed by using a second key, and sends the second seed encrypted by using the second key to the first ECU;

the first ECU verifies that the KMS uses the second seed encrypted by the second key and the first ECU uses the seed encrypted by the second key are consistent.

In order to realize that the diagnostic instrument and the ECU do not use the same secret key for safety access authentication, or the diagnostic instrument does not hold the secret key for safety access authentication, the vehicle-mounted KMS in the vehicle can interfere the safety access authentication process between the diagnostic instrument and the ECU, and the safety access authentication between the diagnostic instrument and the ECU is completed by using the secret key of the ECU, so that the ECU does not need to change the configuration to adapt to the scheme, and the scheme also considers that different ECUs in the vehicle can be sourced from different manufacturers, thereby avoiding the trouble that developers coordinate with different manufacturers to change the configuration of the ECUs, and increasing the feasibility of the method on the vehicle.

With reference to the first aspect or the second aspect, in one implementation manner, the second key is a key generated by the vehicle using the first vehicle key, where the vehicle keys of different vehicles are different.

That is, the vehicle can derive the ECU keys of different ECUs in the vehicle from one vehicle key, and the vehicle keys of different vehicles are different. Since the ECU keys of the respective ECUs in the vehicle are derived from the vehicle keys, if the vehicle keys are leaked, all the ECU keys in the vehicle are leaked. Therefore, the vehicle keys of different vehicles are different, and the influence caused by the leakage of the vehicle keys can be reduced as much as possible.

In a third aspect, an embodiment of the present application provides a vehicle security access method, where the method is applied to a first device, and the method includes: the first device sends a first secure access request to the vehicle; in the case that the vehicle has authority to access a first ECU in the vehicle and the authentication process inside the vehicle is performed using a second key, using a first key temporarily valid in a first period, the first device receives a first message sent by the vehicle, the first message being used to indicate that the vehicle has passed the authentication of the first device; the first device sends a first diagnostic request to the vehicle; the first device receives diagnostic data of the first ECU transmitted from the vehicle.

By implementing the method provided by the third aspect, the diagnostic apparatus can use a temporary effective key for developing the security access authentication process with the ECU, and the vehicle can complete the security access authentication with the diagnostic apparatus by using the temporary effective key, and then develop the security access authentication with the ECU by using the ECU key, so that the diagnostic apparatus and the ECU do not need to hold the same key. Thus, even if an attacker steals an ECU key on the ECU, the attacker cannot impersonate the diagnostic instrument to carry out security access authentication, or even if the attacker steals an ECU temporary key on the diagnostic instrument, the attacker cannot pass the security access authentication process between the diagnostic instrument and the ECU if the effective time is exceeded because the ECU temporary key is an effective temporary key in a period of time, so that the possibility of the attacker passing the security access authentication is reduced, the reliability of the security access authentication between the diagnostic instrument and the ECU is improved, and the safety of a vehicle is enhanced.

With reference to the third aspect, in one embodiment, in a process that the vehicle verifies that the first device has the right to access the first ECU in the vehicle using the first key that is temporarily valid for the first period of time, the method further includes: the method comprises the steps that first equipment obtains a first seed generated by a vehicle; the first device encrypts the first seed using a first key; the first device sends the first seed encrypted by the first key to the vehicle.

With reference to the third aspect, in one implementation, before the first device sends the first secure access request to the vehicle, the method further includes: the first device obtains a first key sent by a second device that is a server managed and maintained by a vendor that manufactures the components of the vehicle.

That is, the diagnostic apparatus can obtain the ECU temporary key from the third party device trusted by the officer, so as to ensure the credibility of the source of the ECU temporary key.

With reference to the third aspect, in one implementation manner, the first device acquires a first key sent by the second device, and specifically includes: the first device obtains an authorization file sent by the second device, wherein the authorization file comprises: the first key, the invalidation parameter, signature determined according to the first key and the invalidation parameter; wherein the revocation parameter is used to indicate a first period of time, the signature characterizing the first key and the revocation parameter in the authorization file being generated by the second device.

The diagnostic instrument can acquire the ECU temporary key by acquiring the authorization file sent by the server, and can judge whether an attacker falsifies parameters in the authorization file, such as the ECU temporary key and failure parameters, in the process of sending the authorization file to the diagnostic instrument by the server through checking the signature in the authorization file, so that the reliability of the ECU temporary key is ensured, and the reliability of a safety access authentication process between the vehicle and the diagnostic instrument by using the ECU temporary key is further ensured.

With reference to the third aspect, in one implementation manner, before the first device obtains the authorization file sent by the second device, the method further includes: the first device sends a digital certificate of the first device to the second device, the digital certificate being used to prove that the first device is a trusted device.

Thus, the server can be prevented from sending the authorization file to the attacker, and the attacker is prevented from stealing the ECU temporary key.

With reference to the third aspect, in one implementation manner, after the first device acquires the authorization file sent by the second device, the method further includes: the first device sends an authorization file to the vehicle.

The diagnostic instrument places the ECU temporary secret key in the authorization file, and transmits the ECU temporary secret key to the vehicle by sending the ECU temporary secret key to the vehicle, so that the vehicle can judge whether an attacker falsifies parameters in the authorization file, such as the ECU temporary secret key and failure parameters, in the process of sending the authorization file to the vehicle by the diagnostic instrument through checking the signature in the authorization file, thereby guaranteeing the reliability of the ECU temporary secret key, and further guaranteeing the reliability of a security access authentication process between the vehicle and the diagnostic instrument by using the ECU temporary secret key.

With reference to the third aspect, in one embodiment, before the first device sends the authorization file to the vehicle, the method further includes: the first device sends a digital certificate to the vehicle, wherein the digital certificate characterizes the first device as an identity trusted device; or, the first device sends the authorization file to the vehicle, which specifically includes: the first device sends the authorization file to the vehicle through the UDS 2904 service, and the UDS 2904 service is used to prove the first device as an identity-trusted device.

In order to avoid an attacker impersonating the temporary key sent by the diagnostic instrument to the ECU to the vehicle, the diagnostic instrument may prove the authenticity of its identity before sending the authorization document to the vehicle, or the diagnostic instrument may send the authorization document to the vehicle via a trusted path.

With reference to the third aspect, in one embodiment, the authorization file further includes: vehicle information indicating a vehicle, and a signature is also determined from the vehicle information.

The vehicle information may be, for example, a VIN code of the vehicle. The authorization file also comprises information indicating the vehicle to be diagnosed currently, so that the diagnosis instrument can be ensured to diagnose the vehicle indicated by the authorization file only, an attacker is prevented from using the ECU temporary key for developing a security access authentication process with other vehicles, and the reliability of the security access authentication is improved.

With reference to the third aspect, in one embodiment, the first secure access request, the first message, the first diagnostic request, and the diagnostic data are all sent according to a communication standard of a diagnostic service for the vehicle in a universal diagnostic service UDS protocol.

In a fourth aspect, an embodiment of the present application provides a vehicle security access method, where the method is applied to a first device, and the method includes: the first device authenticates the identity of the first device to the vehicle as being authentic; the first device sends a first diagnostic request to the vehicle; in the case where the vehicle performs a security access authentication process of the vehicle interior using the second key of the first ECU, the first device acquires diagnostic data of the first ECU in the vehicle transmitted by the vehicle.

The method provided in the fourth aspect is implemented, the diagnostic device no longer holds a key for performing security access authentication, the diagnostic device directly proves that the diagnostic device is a trusted diagnostic device to the vehicle, and sends a diagnostic request to directly request access to the resources in the ECU, while the vehicle interior still performs security access authentication according to the first time, and then the step of sending the diagnostic data of the ECU to the diagnostic device in response to the diagnostic request is performed. Therefore, the possibility that the diagnostic instrument leaks the secret key for the security access authentication is eliminated, the reliability of the security access authentication between the diagnostic instrument and the ECU is improved, the ECU still communicates according to the standard of the UDS protocol, a developer does not need to adapt the ECU, the trouble that the developer coordinates with different manufacturers to change the configuration of the ECU is avoided, and the feasibility of implementation of the method on the vehicle is increased.

With reference to the fourth aspect, in one implementation manner, the authentication of the identity of the first device by the first device to the vehicle is trusted, specifically includes: the first device sends a digital certificate to the vehicle, the digital certificate characterizing the first device as an identity-trusted device.

With reference to the fourth aspect, in one embodiment, before the first device sends the digital certificate to the vehicle, the method further includes: the first device sends a digital certificate to the second device; the first device sends the digital certificate to the vehicle, and specifically comprises the following steps: the first device sends the digital certificate to the vehicle in the case that the second device determines that the first device identity is trusted based on the digital certificate.

That is, before diagnosis is initiated to the vehicle, the diagnostic apparatus needs to complete dual authentication to the server and the vehicle, so that the diagnostic apparatus is ensured to be a trusted device as far as possible, an attacker is prevented from stealing the diagnostic data of the ECU, and the safety of the vehicle is ensured as far as possible.

With reference to the fourth aspect, in one embodiment, the first diagnostic request and the diagnostic data are both transmitted according to a communication standard of a diagnostic service for the vehicle in a universal diagnostic service UDS protocol.

With reference to the third aspect or the fourth aspect, in one implementation manner, the second key is a key generated by the vehicle using the first vehicle key, where the vehicle keys of different vehicles are different.

In a fifth aspect, embodiments of the present application provide a vehicle comprising a memory, one or more processors, and one or more programs; the one or more processors, when executing the one or more programs, cause the vehicle to implement the method as described in the first aspect or any implementation of the first aspect, the second aspect or any implementation of the second aspect.

In a sixth aspect, embodiments of the present application provide an electronic device including a memory, one or more processors, and one or more programs; the one or more processors, when executing the one or more programs, cause the electronic device to implement the method as described in the third aspect or any implementation of the third aspect, the fourth aspect or any implementation of the fourth aspect.

In a seventh aspect, embodiments of the present application provide a communication system, the system including a vehicle as in the fifth aspect and an electronic device as in the sixth aspect.

In an eighth aspect, embodiments of the present application provide a computer readable storage medium comprising instructions, characterized in that the instructions, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect or any implementation of the first aspect, any implementation of the second aspect or the second aspect, any implementation of the third aspect or the third aspect, any implementation of the fourth aspect or the fourth aspect.

In a ninth aspect, the present embodiments provide a computer program product, characterized in that the computer program product, when run on a computer, causes the computer to perform the method as described in the first aspect or any one of the embodiments of the first aspect, any one of the embodiments of the second aspect or any one of the embodiments of the third aspect, any one of the embodiments of the fourth aspect or any one of the embodiments of the fourth aspect.

Drawings

FIG. 1 is a schematic flow chart of a diagnostic apparatus and a vehicle ECU involved in performing a UDS27 service;

Fig. 2 is a schematic diagram of a communication system 1000 according to an embodiment of the present application;

fig. 3 is a schematic flow chart related to generating an ECU key in the vehicle security access method provided in the embodiment of the present application;

fig. 4 is a schematic flow chart of another process involved in generating an ECU key in the vehicle security access method provided in the embodiment of the present application;

fig. 5 is a schematic flow chart related to performing security access authentication by using an ECU key in the vehicle security access method provided in the embodiment of the present application;

fig. 6 is another schematic flow chart related to performing security access authentication by using an ECU key in the vehicle security access method provided in the embodiment of the present application;

fig. 7 is a schematic structural diagram of a vehicle 300 according to an embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of an electronic device 400 according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and thoroughly described below with reference to the accompanying drawings. Wherein, in the description of the embodiments of the present application, "/" means or is meant unless otherwise indicated, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and in addition, in the description of the embodiments of the present application, "plural" means two or more than two.

The terms "first," "second," and the like, are used below for descriptive purposes only and are not to be construed as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature, and in the description of embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" is two or more.

A series of diagnostic services are defined in the UDS protocol, through which the diagnostic instrument and the vehicle ECU can normalize the instructions and transmitted data sent during communication.

Among other things, the UDS protocol defines a secure access service, UDS 27 service, which is used to provide a way to access controlled resources in a vehicle or to perform fault diagnostics. Since some data in the ECU or the failure diagnosis of the ECU is protected for safety reasons, it is necessary to perform the UDS 27 service to release the protection restriction on the ECU before the diagnostic instrument reads the resources in the ECU or performs the failure diagnosis on the ECU.

Fig. 1 is a schematic flow chart related to performing UDS 27 service between a diagnostic apparatus and a vehicle ECU.

As can be seen from fig. 1, after the diagnostic apparatus sends a secure access request to the vehicle ECU, the diagnostic apparatus and the vehicle ECU encrypt one seed generated by the vehicle ECU respectively, wherein in the encryption process, the diagnostic apparatus and the vehicle ECU use the same ECU key, then the diagnostic apparatus sends the encrypted seed to the vehicle ECU, if the vehicle ECU determines that the received encrypted seed is consistent with the locally encrypted seed, the diagnostic apparatus passes the secure access authentication, the vehicle ECU provides the diagnostic apparatus with the secure access authority, and then the diagnostic apparatus can access the limited resource on the vehicle ECU or perform fault diagnosis.

However, since the diagnostic apparatus and the vehicle ECU use the same ECU key, if the diagnostic apparatus or the ECU key on the vehicle ECU leaks, the authentication of the secure access is similar to the dummy, and an attacker can easily pass the authentication of the secure access, develop an attack on the vehicle ECU, for example, illegally access resources in the ECU, modify the configuration of the ECU, brush the software package of the ECU, and the like, which affects the security of the vehicle.

Therefore, how to improve the reliability of the secure access authentication in the vehicle ECU is a problem to be solved at present.

In order to solve the above-mentioned problems, the embodiment of the present application provides a vehicle security access method, in which the same key is not used for security access authentication on a diagnostic apparatus and an ECU, specifically, for a target ECU requiring resource access or fault diagnosis of the diagnostic apparatus, the diagnostic apparatus may use an ECU temporary key for completing security access authentication of the diagnostic apparatus and the target ECU, while the vehicle interior may intervene in security access authentication process of the diagnostic apparatus and the target ECU, the security access authentication process of the diagnostic apparatus is completed using the ECU temporary key, it is determined whether the diagnostic apparatus has authority to access resources or fault diagnosis, after the diagnostic apparatus passes security access authentication, the ECU determines that the diagnostic apparatus has authority to access resources of the ECU, and after the security access authentication of the vehicle interior passes, the ECU determines that the diagnostic apparatus has authority to access resources of the ECU, and may send diagnostic data of the ECU to the diagnostic apparatus based on a diagnostic request of the diagnostic apparatus. The ECU temporary key is a key that is valid for a certain period of time, and after a certain period of time, the ECU temporary key cannot be used for security access authentication.

It can be seen that the ECU uses both the ECU temporary key and the ECU key for the security access authentication of the diagnostic apparatus, and the diagnostic apparatus uses the ECU temporary key for authentication, so that even if an attacker steals the ECU key, the security access authentication process between the diagnostic apparatus and the ECU is not possible; in addition, because the ECU temporary key held on the diagnostic instrument has timeliness, an attacker steals the ECU temporary key, and if the time is exceeded, the security access authentication process between the diagnostic instrument and the ECU cannot be passed. Thus, the possibility of an attacker passing through the security access authentication is reduced, the reliability of the security access authentication of the diagnostic instrument and the ECU is improved, and the safety of the vehicle is enhanced.

The embodiment of the application also provides a vehicle security access method, in which the diagnostic instrument does not hold a key for security access authentication. Specifically, the diagnostic apparatus only needs to prove that the diagnostic apparatus is a trusted device to the vehicle, does not initiate the security access authentication any more, directly sends a diagnostic request to the target ECU, intercepts the diagnostic request, uses the ECU key to carry out the security access authentication with the target ECU, and transmits the diagnostic request to the target ECU after passing the authentication, thereby triggering the resource access or fault diagnosis to the target ECU.

It can be seen that the diagnostic instrument does not hold the secret key for carrying out the security access authentication, so that the possibility of the diagnostic instrument leaking the ECU secret key is eliminated, and the reliability of the diagnostic instrument and the ECU for carrying out the security access authentication is improved.

In the above two vehicle security access methods, the ECU key of the target ECU is a key that is derived from the vehicle-use vehicle key and used only for the target ECU to perform security access authentication, in other words, the ECU keys used by different ECUs in the vehicle are different.

Thus, the ECU keys used when different ECUs in the vehicle perform security access authentication are different, so that even if the ECU key of one ECU leaks, the security access authentication process of other ECUs in the vehicle is not affected. In addition, because the diagnostic instrument uses the ECU temporary key to carry out security access authentication with the vehicle, even if the ECU keys of different ECUs are different, the diagnostic instrument does not need to frequently acquire the ECU keys used by different ECUs when diagnosing the different ECUs, thereby effectively solving the problem that the leak generated when most of the current vehicle factories use the same ECU keys for the same type of ECUs of the same vehicle type, namely, the ECU key of one ECU leaks, leading to ineffective security access authentication of the type of ECUs in a plurality of vehicles, and effectively improving the feasibility of popularizing 'different ECUs using different ECU keys' in the industry.

Further, the vehicle keys of different vehicles may also be different. Since the ECU keys of the respective ECUs in the vehicle are derived from the vehicle keys, if the vehicle keys are leaked, all the ECU keys in the vehicle are leaked. Therefore, the vehicle keys of different vehicles are different, and the influence caused by the leakage of the vehicle keys can be reduced as much as possible.

The following describes a communication system 1000 provided in an embodiment of the present application.

Fig. 2 is a schematic diagram of a communication system 1000 according to an embodiment of the present application. As shown in fig. 2, the communication system 1000 may include: server 100, diagnostic apparatus 200, and vehicle 300. Wherein:

server 100 may be used to generate, manage, and distribute keys. In an embodiment of the present application, the key may include: vehicle keys, ECU temporary keys, ECU keys, etc. The server 100 may generate a vehicle key for a vehicle (e.g., the vehicle 300), and send the vehicle key to the vehicle 300, where the vehicle key may be used to derive an ECU key for the ECU, and the vehicle 300 may perform secure access authentication of the ECU inside the vehicle through the ECU key. The server 100 may derive an ECU key from the vehicle key and transmit the ECU key to the vehicle 300. In addition, the server 100 may generate an ECU temporary key for a diagnostic apparatus (for example, the diagnostic apparatus 200), and the diagnostic apparatus 200 may perform security access authentication of the ECU outside the vehicle through the ECU temporary key.

It should be noted that, in the process of the security access authentication, the interaction process between the diagnostic apparatus 200 and the vehicle is involved, and in the process of the security access authentication, the security access authentication in the vehicle is involved. See in particular the subsequent process flows, which are not first developed here.

The diagnostic apparatus 200 may be used to access resources in a vehicle and detect a malfunction of the vehicle. Specifically, the diagnostic apparatus 200 is used to access the resources of the ECU in the vehicle and detect a failure of the ECU. In the embodiment of the present application, the diagnostic apparatus 200 may be configured to acquire the ECU temporary key transmitted from the server 100 and transmit the ECU temporary key to the vehicle 300, and the diagnostic apparatus 200 may be configured to transmit a security access request to the vehicle 300, and perform security access authentication outside the vehicle using the ECU temporary key.

The vehicle 300, which is the subject of diagnosis by the diagnostic apparatus, can return the diagnosis data requested by the diagnosis request according to the diagnosis request transmitted by the diagnostic apparatus, and complete the security access authentication with the diagnostic apparatus before diagnosis. In the embodiment of the present application, the vehicle 300 may be configured to acquire or generate a vehicle key, and generate an ECU key of the ECU according to the vehicle key, acquire an ECU temporary key transmitted by the diagnostic apparatus 200, complete secure access authentication of the vehicle exterior to the diagnostic apparatus 200 using the ECU temporary key, complete secure access authentication of the vehicle interior using the ECU key, and transmit indication information that the authentication passes to the diagnostic apparatus 200 when the authentication of the secure access passes.

The embodiments of the present application do not limit the manner of communication connection between devices in the communication system 1000. In particular, the communication connection may be a wired connection, a wireless connection. The wireless connection may be a close range connection such as a high fidelity wireless communication (wireless fidelity, wi-Fi) connection, a bluetooth connection, an infrared connection, an NFC connection, a ZigBee connection, or a remote connection including, but not limited to, a remote connection of a mobile network based on 2g,3g,4g,5g, and subsequent standard protocols. For example, the server 100 may transmit the ECU temporary key to the diagnostic apparatus 200 by way of a wireless connection. For another example, the diagnostic apparatus 200 may communicate with the vehicle 300 via a wired connection, and the diagnostic apparatus 200 may communicate with the vehicle 300 via a wired connection to an on-board automated diagnostic system (On Board Diagnostics, OBD) port of the vehicle 300, for example.

In addition, it should be noted that, in the embodiments of the present application, the server, for example, the server 100, may be one server, or may refer to a server cluster formed by a plurality of servers. For example, the server 100 may be a server cluster in which a plurality of servers are deployed through a distributed architecture, which may include one or more of cloud computing servers, content delivery network (Content Delivery Network, CDN) servers, network time protocol (Network Time Protocol, NTP), domain name resolution system (Domain Name System, DNS) servers, and so forth. The servers can coordinate with each other to complete the functions of calculation, data storage, communication and the like. For convenience of description, in the embodiments of the present application, a single server, a distributed server, a server cluster, and the like are collectively referred to as a server. In an embodiment of the present application, the server 100 may be a server cluster deployed by a distributed architecture for a plurality of servers affiliated with an original equipment manufacturer (original equipment manufacturer, OEM) and collectively constituting a key management system (key management system, KMS) of the original equipment manufacturer.

The vehicle security access method provided by the embodiment of the application is used for realizing security access authentication of a diagnostic instrument before fault diagnosis or resource access is performed on a vehicle, and generally, the vehicle security access method mainly comprises the following steps: the vehicle acquires an ECU key for security access authentication, and the diagnostic apparatus performs security access authentication with the vehicle, and detailed procedures of the vehicle management method are described in two stages, respectively.

Stage one: generating an ECU Key

In the embodiment of the application, the ECU key is derived from a vehicle key in the vehicle, and in the embodiment of the application, the vehicle key may be generated by the vehicle or may be generated by a server.

Fig. 3 is a schematic flow chart related to generating an ECU key in the vehicle security access method provided in the embodiment of the present application, and fig. 4 is another schematic flow chart related to generating the ECU key in the vehicle security access method provided in the embodiment of the present application.

Wherein fig. 3 shows the interaction procedure involved by the server 100 and the vehicle 300 when the vehicle key is generated by the server 100, and fig. 4 shows the interaction procedure involved by the server 100 and the vehicle 300 when the vehicle key is generated by the vehicle 300.

In addition, the interaction illustrated in fig. 3 and 4 mainly involves two functional modules in the vehicle 300: vehicle-mounted KMS and ECU. The vehicle KMS is configured to generate and manage a key in a vehicle, and the vehicle 300 may include one or more ECUs, and for example, the ECU1 is illustrated in fig. 3 and 4, and the ECU1 may be any ECU in the vehicle 300, and in this embodiment, the ECU1 may refer to a target ECU that needs to be diagnosed by the diagnostic apparatus 200.

As shown in fig. 3, stage one mainly includes:

s101, the server 100 generates a vehicle key for the vehicle 300.

Specifically, the server 100 may generate a random number using a cryptographic algorithm, with the random number being used as the vehicle key for the vehicle 300.

Further, when multiple vehicles are involved, the server 100 may generate different vehicle keys for each vehicle, i.e., the vehicle keys for the different vehicles are different. For example, assuming that there is also a vehicle 400, the server 100 may generate a vehicle key 1 of the vehicle 300 for the vehicle 300, and a vehicle key 2 of the vehicle 400 for the vehicle 400.

In addition, the server 100 may bind the vehicle key with the vehicle identification code (Vehicle Identification Number, VIN) of the vehicle after generating the vehicle key, in other words, store the vehicle key of the vehicle with the VIN code. The VIN code is equivalent to the ID card number of the vehicle, is determined according to the national vehicle management standard, and contains information such as the manufacturer, the year, the vehicle type, the vehicle body type and code, the engine code, the assembly site and the like of the vehicle. Alternatively, it is also understood that binding the vehicle key to the vehicle's VIN code may refer to the vehicle key being part of the VIN code. Thus, the vehicle key can be managed by binding the vehicle key with the VIN code of the vehicle, and the vehicle keys of different vehicles can be distinguished.

In the present embodiment, the server 100 is a server managed and maintained by a manufacturer that manufactures components of the vehicle, and the server 100 may also be referred to as a second device.

S102, the server 100 sends the vehicle key to the vehicle-mounted KMS in the vehicle 300.

The server 100 transmits the vehicle key to the vehicle 300, and specifically, the server 100 transmits the vehicle key to the in-vehicle KMS in the vehicle 300. Accordingly, the vehicle 300 may receive the vehicle key transmitted from the server 100.

Further, when the vehicle key is bound to the VIN code, the server 100 may transmit the vehicle key of the vehicle 300 to the vehicle 300 together when transmitting the VIN code of the vehicle 300 to the vehicle 300.

In addition, when multiple vehicles are involved, the server 100 may transmit the vehicle keys of the different vehicles to the respective vehicles, e.g., the server 100 transmits the vehicle key 1 of the vehicle 300 to the vehicle 300 and the vehicle key 2 of the vehicle 400 to the vehicle 400.

S103, the vehicle-mounted KMS in the vehicle 300 generates an ECU key of the ECU1 by using the vehicle key.

The vehicle 300 generates an ECU key of the ECU1 using the vehicle key. Specifically, the vehicle 300 may generate the ECU key of the ECU1 by using the vehicle key through the in-vehicle KMS.

Illustratively, vehicle 300 may derive a key from the vehicle key using a key derivation function (key derivation function, KDF) or HMAC-based KDF (i.e., HKDF), and use the derived key as the ECU key for ECU 1. The ECU key is used for encrypting the seed when the secure access authentication of the vehicle interior is performed, and the detailed process of the second stage can be seen.

Further, for a plurality of ECUs in the vehicle 300, the vehicle 300 may derive a plurality of keys from the vehicle key, and use the plurality of keys as ECU keys of the plurality of ECUs, respectively. For example, the in-vehicle KMS in the vehicle 300 derives the ECU key of the ECU1 and the ECU key of the ECU2 from the vehicle key.

In some embodiments, the ECU key may include one or more keys. Illustratively, the ECU key may include two keys: ECU2701 key and ECU2709 key. Wherein the ECU2701 key is for use in secure access authentication, and the ECU2709 key is for use in the ECU performing software package flashing. The number of ECU keys is not limited in the embodiment of the present application.

In the embodiment of the present application, the vehicle 300 may generate ECU keys of a plurality of ECUs using the vehicle key, for example, there are a first ECU and a second ECU, the ECU key of the first ECU may also be referred to as a second key, the ECU key of the second ECU may also be referred to as a fourth key, and the ECU1 may be referred to as a first ECU, for example.

S104, the vehicle-mounted KMS in the vehicle 300 sends the ECU key of the ECU1 to the ECU1.

For a plurality of ECUs in the vehicle 300, the vehicle 300 may transmit ECU keys respectively derived for the plurality of ECUs to the corresponding ECUs, respectively, through the in-vehicle KMS. For example, when the vehicle KMS generates ECU keys for ECU1 and ECU2, the vehicle KMS may transmit the ECU key of ECU1 to ECU1 and the ECU key of ECU2 to ECU2.

It should be appreciated that steps S101-S104 described above may be performed during the entire vehicle production line of the vehicle 300, that is, the server may preset the vehicle key in the vehicle in advance before the vehicle is put into the user' S driving, and the vehicle derives the ECU key required by each ECU in the vehicle during the security access authentication phase from the vehicle key.

S105. the server 100 generates an ECU key of the ECU1 using the vehicle key.

Similar to step S103, the server 100 may derive the ECU key from the vehicle key using a key derivation algorithm such as KDF or HKDF.

In some embodiments, the server 100 may derive the ECU key of the ECU1 from the vehicle key using a key derivation algorithm when the diagnostic apparatus 200 needs to perform fault diagnosis or resource access to the ECU1. After that, the server 100 transmits the ECU key to the vehicle 300 (not shown in fig. 3) so that the ECU1 completes the secure access authentication of the vehicle interior using the ECU key.

In this way, the vehicle 300 directly obtains the ECU key required for the ECU1 in the secure access authentication stage through the server 100 without using the vehicle key to generate the ECU key of the ECU1.

It is understood that step S105 is applicable to the diagnostic apparatus 200 being executed only for a single ECU of the vehicle 300, where steps S103-S104 are optional steps, the vehicle 300 may directly obtain ECU keys of the ECU through the server 100, or the vehicle 300 may generate ECU keys required for the diagnosis of a plurality of ECUs in advance, where step S105 is an optional step, and the vehicle 300 may generate ECU keys of a plurality of ECUs by itself. Note that in steps S103 and S105, the key derivation algorithm used by the server 100 and the vehicle 300 is the same.

As shown in fig. 4, stage one mainly includes:

s201. the vehicle KMS in the vehicle 300 generates a vehicle key of the vehicle 300.

S202. the vehicle KMS in the vehicle 300 sends the vehicle key to the server 100.

S203, the vehicle-mounted KMS in the vehicle 300 generates an ECU key of the ECU1 by using the vehicle key.

S204. the in-vehicle KMS in the vehicle 300 transmits the ECU key of the ECU1 to the ECU1.

S205. the server 100 generates an ECU key of the ECU1 using the vehicle key.

Wherein, in combination with steps S101-S105 shown in fig. 3, it can be seen from steps S201-S205 that steps S203-S205 are identical to steps S103-S105 shown in fig. 3, steps S201-S202 are similar to steps S101-S102 shown in fig. 3, except that in steps S201-S202 shown in fig. 4, a vehicle key is generated by the vehicle 300, specifically, by an on-board KMS in the vehicle 300, and the vehicle key is transmitted by the vehicle 300 to the server 100, whereas in steps S101-S102 shown in fig. 3, the vehicle key is generated by the server 100, and the vehicle key is transmitted by the server 100 to the vehicle 300.

It should be appreciated that after the vehicle 300 transmits the vehicle key to the server 100 in steps S201-S202, the server 100 may bind the vehicle key to the VIN code of the vehicle 300. In addition, when multiple vehicles are involved, the server 100 may receive vehicle keys generated by multiple vehicles, e.g., the server 100 receives the vehicle key of the vehicle 300 transmitted by the vehicle 300, and the vehicle key of the vehicle 400 transmitted by the vehicle 400.

In addition, step S202 and step S205, or step S203 and step S204 are optional steps, and the embodiment of the present application does not limit the execution order of step S202 in steps S201, S203, S204. For details not described in steps S201 to S205, reference may be made to the relevant content of steps S101 to S105, which are not described in detail herein.

Stage two: secure access authentication with ECU key

In the embodiment of the application, in order to avoid that the security access authentication process is invalid due to the leakage of the ECU key on the diagnostic apparatus or the ECU, two modes can be adopted: the same key is no longer used for the security access authentication on the diagnostic apparatus and the ECU, or the key for performing the security access authentication is no longer held on the diagnostic apparatus, so that the reliability of the security access authentication is improved.

Fig. 5 is a schematic flow chart related to performing security access authentication by using an ECU key in the vehicle security access method provided in the embodiment of the present application, and fig. 6 is another schematic flow chart related to performing security access authentication by using an ECU key in the vehicle security access method provided in the embodiment of the present application.

Fig. 5 shows an interaction procedure among the server 100, the diagnostic apparatus 200, and the vehicle 300 when the diagnostic apparatus 200 and the ECU1 in the vehicle 300 do not use the same key for security access authentication. Fig. 6 shows the interaction between the server 100, the diagnostic apparatus 200 and the vehicle 300 when the key for secure access authentication is no longer held on the diagnostic apparatus 200.

As shown in fig. 5, the second stage mainly includes:

S301, the server 100 and the diagnostic apparatus 200 finish diagnostic apparatus authentication.

The diagnostic apparatus 200 may trigger authentication to the server 100 when it is necessary to perform a failure diagnosis or resource access to the ECU in the vehicle 300, for example, the ECU1, or when it is necessary to acquire the ECU temporary key generated by the server 100. For example, diagnostic apparatus 200 may trigger a fault diagnosis of vehicle 300, such as one or more ECUs in vehicle 300, upon receiving a user-triggered diagnosis of the operation of the vehicle.

The server 100 performs diagnostic authentication with the diagnostic apparatus 200 to prove to the server 100 that the diagnostic apparatus 200 is legitimate, and to avoid an attacker impersonating the diagnostic apparatus 200 to communicate with the server 100, and illegally steal data in the server 100, such as an ECU temporary key.

Specifically, the diagnostic apparatus 200 may complete the diagnostic apparatus authentication by transmitting a digital certificate of the diagnostic apparatus 200 to the server 100, proving the validity of the diagnostic apparatus 200. Wherein the digital certificate is an electronic certificate issued by a certificate authority (Certificate Authority, CA) in a trusted third party, such as a public key infrastructure (Public Key Infrastructure, PKI), to the diagnostic apparatus 200 for proving its identity.

Further, the diagnostic apparatus 200 may communicate with the server 100 based on a transport layer security protocol (Transport Layer Security, TLS) to complete diagnostic apparatus authentication. The TLS protocol is a security protocol that provides security and data integrity assurance for communications between devices. In this way, the diagnostic apparatus 200 transmits the digital certificate of the diagnostic apparatus 200 based on the TLS protocol, so that the third party can be prevented from eavesdropping and tampering with the digital certificate, and the credibility of the authentication stage of the diagnostic apparatus can be ensured.

In embodiments of the present application, the diagnostic apparatus may also be referred to as a first device.

S302, the server 100 generates an ECU temporary key.

The ECU temporary key is used to encrypt the seed when the diagnostic apparatus 200 performs security access authentication with the vehicle 300. The server 100 may generate the ECU temporary key through PKI, for example.

It will be appreciated that the ECU temporary key is different from the ECU key and that the ECU temporary key is time-efficient, with the ECU temporary key only being valid for a period of time. In this way, it is possible to avoid as much as possible that the attacker spreads an attack on the vehicle 300 after stealing the ECU temporary key.

In addition, the ECU temporary key may be valid only for the diagnostic apparatus 200 to diagnose the ECU1, and at this time, the diagnostic apparatus 200 can use the ECU temporary key only in the security authentication process of the ECU 1.

Preferably, the ECU temporary key is valid for any one of the ECUs in the vehicle 300 to be diagnosed by the diagnostic apparatus 200, and at this time, the diagnostic apparatus 200 may use the ECU temporary key in the security authentication of any one of the ECUs in the vehicle 300 during the validity period of the ECU temporary key. In this way, when the diagnostic apparatus 200 needs to diagnose a plurality of ECUs in the vehicle 300, the diagnostic apparatus 200 does not need to frequently acquire a plurality of ECU temporary keys from the server 100 or frequently perform security access authentication with a different ECU.

Wherein the server 100 may generate the ECU temporary key after the diagnostic instrument authentication is passed.

In the present embodiment, the ECU temporary key may also be referred to as a first key.

S303, after passing the authentication, the server 100 sends the ECU temporary key to the diagnostic apparatus 200.

The server 100 transmits the ECU temporary key to the diagnostic apparatus 200, and accordingly, the diagnostic apparatus 200 receives the ECU temporary key transmitted from the server 100.

Further, in order to avoid a third party tampering with the ECU temporary key, the server 100 may store the ECU temporary key in an authorization file, and after the authentication is passed, send the authorization file carrying the ECU temporary key to the diagnostic apparatus 200. The server 100 may prove the validity of the ECU temporary key by other parameters in the authorization file. At this time, step S303 is modified to transmit the authorization file to the diagnostic apparatus 200 after the server 100 passes the authentication.

Wherein, the authorization file may include: ECU temporary key, revocation parameters, and signature. The invalidation parameter is used to indicate the validity time of the temporary key of the ECU, and the signature may be a signature obtained by digitally signing the temporary key of the ECU and the invalidation parameter by using a private key of the server 100. The signature is used to prove the validity of the ECU temporary key and the revocation parameter, i.e., the ECU temporary key and the revocation parameter are sourced from the server 100 and are not tampered with by a third party.

Optionally, one or more of the following parameters may be included in the authorization file: vehicle information, public key. In this case, the signature in the authorization file may be a signature obtained by digitally signing the ECU temporary key and one or more of the above parameters. The vehicle information is used to indicate the target vehicle diagnosed by the diagnostic apparatus, and may be, for example, a VIN code of the vehicle 300. The public key is a public key required for signing the signature in the authorization file, and the public key and the private key used for signing the server 100 are a pair of keys. In particular implementations, after the diagnostic apparatus 200 obtains the authorization file, the diagnostic apparatus 200 may use the public key to authenticate the signature to determine the validity of the ECU temporary key before using the ECU temporary key.

It should be noted that, the vehicle information is placed in the authorization file, so that an attacker can be prevented from using the ECU keys in other vehicles to authenticate the security access process of the ECU in the own vehicle, and the reliability of the security access authentication of the ECU is improved.

It is understood that the public key used to verify the signature in the authorization document may also be preset in the diagnostic apparatus 200 in advance, and the manner in which the diagnostic apparatus 200 obtains the public key is not limited in this embodiment of the present application. In addition, other parameters may be included in the authorization file, which is not limited in the embodiments of the present application.

S304. the diagnostic apparatus 200 sends the ECU temporary key to the vehicle KMS in the vehicle 300 in case the vehicle 300 determines that the diagnostic apparatus 200 is legal.

In the case where the vehicle 300 determines that the diagnostic apparatus 200 is legal, the diagnostic apparatus 200 transmits the ECU temporary key to the vehicle 300, specifically, to the in-vehicle KMS in the vehicle 300. Accordingly, the vehicle 300 receives the ECU temporary key transmitted from the diagnostic apparatus 200 in the case where it is determined that the diagnostic apparatus 200 is legal.

Wherein, when the vehicle 300 determines that the diagnostic apparatus 200 is legal, the diagnostic apparatus 200 transmits the ECU temporary key to the vehicle 300, so that it is possible to prevent an attacker from falsifying the diagnostic apparatus 200 to transmit the falsified ECU temporary key to the vehicle 300.

Diagnostic apparatus 200 may send the ECU temporary key to vehicle 300 in two ways:

1) Authentication is performed first, and then an ECU temporary key is sent

The diagnostic apparatus 200 may prove its legitimacy to the vehicle 300 and then send the ECU temporary key to the vehicle 300.

Illustratively, the diagnostic apparatus 200 may prove the legitimacy of the diagnostic apparatus 200 to the vehicle 300 based on a 29 service in the UDS protocol, hereinafter referred to as UDS 29 service, and then transmit the ECU temporary key to the vehicle 300 based on the UDS 38 service. The UDS 29 service is a service defined in the UDS protocol for proving identity to the counterpart. For example, the diagnostic apparatus 200 may authenticate through the UDS 29 service using a digital certificate preset in the diagnostic apparatus 200, such as an OEM certificate, and the UDS 38 service is a service for transferring files defined in the UDS protocol.

2) Transmitting ECU temporary keys via trusted means

The diagnostic apparatus 200 directly transmits the ECU temporary key to the vehicle 300 through a trusted path.

For example, the diagnostic apparatus 200 may transmit the ECU temporary key to the vehicle 300 based on the 04 sub-service of the UDS 29 service, hereinafter abbreviated as UDS 29 service. Among them, the UDS 29 service is a service defined in the UDS protocol for transmitting a file representing an identity to the counterpart, and in general, the file is a digital certificate of the diagnostic apparatus 200, and in the embodiment of the present application, the diagnostic apparatus 200 may transmit the ECU temporary key as the file representing an identity to the vehicle 300.

It will be appreciated that, in other manners, the diagnostic apparatus 200 may also send the ECU temporary key to the vehicle 300 while being able to prove the identity thereof, for example, the diagnostic apparatus 200 and the vehicle 300 may both reserve a random number, if the random number sent by the diagnostic apparatus 200 received by the vehicle 300 is a random number agreed by both parties, the diagnostic apparatus 200 is determined to be a trusted device, or the diagnostic apparatus 200 encrypts the ECU temporary key with the private key and then sends it to the vehicle 300, and the manner in which the diagnostic apparatus 200 sends the ECU temporary key is not limited in the embodiment of the present application.

In addition, it should be noted that, when the server 100 transmits the ECU temporary key to the diagnostic apparatus 200 by transmitting the authorization file carrying the ECU temporary key to the diagnostic apparatus 200, the diagnostic apparatus 200 may also directly transmit the authorization file carrying the ECU temporary key to the vehicle 300 when transmitting the ECU temporary key to the vehicle 300, and at this time, step S305 transmits the authorization file to the vehicle-mounted KMS in the vehicle 300 for the diagnostic apparatus 200, and the diagnostic apparatus 200 may avoid the transmitting party of the authorization file as an attacker by transmitting the authorization file to the vehicle after authentication or by transmitting the authorization file in a trusted way, and may avoid the attacker from tampering with the ECU temporary key or the failure parameters, etc. by transmitting the authorization file to the vehicle. After the vehicle 300 acquires the authorization file, the validity of the authorization file is checked by the signature in the authorization file before the ECU temporary key is used. The details of the authorization file may be referred to in the foregoing step S304, and will not be described herein.

S305. the diagnostic apparatus 200 sends a secure access request to the on-board KMS in the vehicle 300.

The diagnostic apparatus 200 transmits a secure access request (Security Access Request) to the vehicle 300, specifically to an onboard KMS in the vehicle 300, and accordingly, the vehicle 300 receives the secure access request transmitted from the diagnostic apparatus 200.

Wherein the diagnostic apparatus 200 sends a secure access request to the vehicle 300 based on the UDS protocol, and the secure access request may carry a diagnostic service identifier (service identifier, SID) of the UDS protocol, where the SID is used to instruct the diagnostic apparatus 200 to initiate a diagnostic service to the vehicle 300. In the present embodiment, the SID is 27. At this point, the diagnostic service initiated by the diagnostic instrument 200 to the vehicle 300 is a secure access service, i.e., UDS 27 service, which is used to provide a way to access controlled resources in the vehicle or to perform fault diagnostics. Specifically, the secure access request is for requesting acquisition of rights to access resources of the ECU1 in the vehicle 300 or to perform fault diagnosis of the ECU 1.

It should be appreciated that diagnostic apparatus 200 does not directly send a secure access request to the onboard KMS in vehicle 300, and diagnostic apparatus 200 would otherwise send the secure access request to ECU1 in vehicle 300, in actual implementation, the onboard KMS would intercept data interacted between diagnostic apparatus 200 and ECU1, and the onboard KMS would serve as a "bridge" for diagnostic apparatus 200 to communicate with ECU 1. Therefore, the in-vehicle KMS may intercept a message of USD 27 service, i.e., a secure access request, sent from the diagnostic apparatus 200 to the ECU1, and complete secure access authentication of the diagnostic apparatus 200 using the ECU temporary key, see, in particular, steps S306-S311 described below.

In the present embodiment, this secure access request for the ECU1 (e.g., first ECU) may also be referred to as a first secure access request, and in addition, the secure access request for the ECU2 (e.g., second ECU) may also be referred to as a third secure access request for requesting access to the ECU1, and the third secure access request for requesting access to the ECU2.

S306, generating seeds by the vehicle-mounted KMS in the vehicle 300.

In response to the secure access request sent by the diagnostic apparatus 200, the vehicle 300 generates a seed (Send), and in particular, the vehicle 300 may generate a seed through the in-vehicle KMS. The seed may be a random number generated by the vehicle KMS.

In embodiments of the present application, the seed may also be referred to as a first seed.

S307. the onboard KMS in the vehicle 300 sends the seed to the diagnostic apparatus 200.

The vehicle 300 transmits the seed to the diagnostic apparatus 200, and specifically, the on-board KMS in the vehicle 300 transmits the seed to the diagnostic apparatus 200, and accordingly, the diagnostic apparatus 200 receives the seed transmitted from the vehicle 300.

S308, the diagnostic apparatus 200 encrypts the seeds by using the ECU temporary key.

In the UDS protocol, ciphertext obtained by encrypting a seed may be referred to as a Key (Security Key).

S309. the in-vehicle KMS in the vehicle 300 encrypts the seed using the ECU temporary key.

Step S308 and step S309 indicate that both the diagnostic apparatus 200 and the vehicle 300 encrypt the seed using the ECU temporary key that they have acquired in advance. It should be noted, among other things, that the diagnostic apparatus 200 and the vehicle 300 use the same key algorithm, with the ECU temporary key encrypting the seed. The same key algorithm may be an algorithm agreed in advance for the diagnostic apparatus 200 and the vehicle 300, including: the data encryption standard (Data Encryption Standard, DES), the international data encryption algorithm (International Data Encryption Algorithm, IDEA), the advanced encryption standard (Advanced Encryption Standard, AES), etc., for example, the diagnostic apparatus 200 may agree with the vehicle 300 after passing the authentication, or the key algorithm may be an algorithm manually introduced into the diagnostic apparatus 200 and the vehicle 300 by a developer, and the manner in which the diagnostic apparatus 200 and the vehicle 300 acquire the key algorithm and the time are not limited in the embodiments of the present application.

Since the ECU temporary key is valid only for a period of time, for example, the first period of time, the diagnostic apparatus 200 and the vehicle 300 encrypt the seed with the ECU temporary key for the first period of time, otherwise, the ECU temporary key is invalidated beyond the first period of time, thereby minimizing the hazard caused by the leakage of the ECU temporary key.

S310, the diagnostic apparatus 200 sends the encrypted seeds to the vehicle-mounted KMS in the vehicle 300.

The diagnostic apparatus 200 transmits the encrypted seed to the vehicle 300, specifically to an on-board KMS in the vehicle 300, and accordingly, the vehicle 300 receives the encrypted seed transmitted from the diagnostic apparatus 200.

It should be appreciated that the diagnostic apparatus 200 does not perceive the recipient of the encrypted seed when it is sent to the vehicle 300. The diagnostic apparatus 200 originally transmits the encrypted seed to the ECU1, and the vehicle-mounted KMS intercepts the encrypted seed after the diagnostic apparatus 200 transmits the encrypted seed.

S311, the vehicle-mounted KMS in the vehicle 300 judges whether the received encrypted seeds are consistent with the locally encrypted seeds.

The vehicle 300 determines whether the received encrypted seed (e.g., the first seed encrypted with the third key) is consistent with the locally encrypted seed (e.g., the first seed encrypted with the first key), and specifically, the vehicle 300 may determine whether the received encrypted seed is consistent with the locally encrypted seed through the vehicle-mounted KMS. In this way, the in-vehicle KMS can determine whether the diagnostic apparatus 200 has authority to access the resources of the ECU (e.g., ECU 1) or perform fault diagnosis on the ECU by judging the received encrypted seed and the locally encrypted seed.

The locally encrypted seed may refer to a seed encrypted by an on-board KMS in the vehicle 300.

S312. in case of coincidence, the in-vehicle KMS in the vehicle 300 transmits a secure access request to the ECU1.

If the information matches, it is described that the in-vehicle KMS determines that the diagnostic apparatus 200 has authority to access the resources of the ECU (e.g., ECU 1) or perform fault diagnosis on the ECU, that is, has authority to access the ECU1.

The vehicle 300 transmits the secure access request to the ECU1 in the vehicle 300 through the in-vehicle KMS. Similar to the secure access request mentioned in step S305, the secure access request is for the diagnostic apparatus 200 to request acquisition of the rights to access the resources of the ECU1 in the vehicle 300 or to perform the failure diagnosis of the ECU1. The description of the secure access request may refer to the description of the secure access request in step S305, and will not be repeated here.

It should be understood that the ECU1 does not sense the sender of the secure access request, and still generates and transmits a seed according to the secure access request according to the existing diagnostic procedure between the diagnostic apparatus and the ECU, encrypts the seed with the ECU key, and so on, as can be seen in the following steps S313-S319. The vehicle safety access method provided by the embodiment of the application is implemented without adapting the ECU in consideration of the fact that the vehicle possibly comprises ECUs produced by a plurality of manufacturers, so that the trouble that developers coordinate with different manufacturers to change the configuration of the ECU is avoided, and the feasibility of implementation of the method on the vehicle is increased.

In the embodiment of the present application, the secure access request transmitted by the vehicle KMS to the ECU1 may also be referred to as a second secure access request.

S313. the ECU1 in the vehicle 300 generates seeds.

In response to the secure access request sent by the vehicle-mounted KMS, the ECU1 generates a seed (Send), wherein the seed may be a random number generated by the ECU 1.

In embodiments of the present application, the seed may also be referred to as a second seed.

S314. ECU1 in vehicle 300 transmits the seed to the in-vehicle KMS.

It should be appreciated that the ECU1 in the vehicle 300 would have sent the seed to the diagnostic apparatus 200, and the in-vehicle KMS would have intercepted the seed sent by the ECU1 to the diagnostic apparatus 200, thus causing the ECU1 to send the seed to the in-vehicle KMS.

S315. the onboard KMS in the vehicle 300 encrypts the seed using the ECU key.

S316. the ECU1 in the vehicle 300 encrypts the seed with the ECU key.

Similar to steps S308-S309, the in-vehicle KMS and ECU1 in the vehicle 300 also encrypt the seed using the same key algorithm, except that the encryption referred to in steps S308-S309 is encrypted using the ECU temporary key, and the encryption referred to in steps S315-S316 is encrypted using the ECU key.

In addition, the key algorithm used by the vehicle KMS and the ECU1 may be the same as or different from the key algorithm used by the diagnostic apparatus 200 and the vehicle 300 in steps S308 to S309, which is not limited in the embodiment of the present application.

S317, the vehicle-mounted KMS in the vehicle 300 sends the encrypted seeds to the ECU1.

The vehicle-mounted KMS transmits the encrypted seed to the ECU1, and accordingly, the ECU1 receives the encrypted seed transmitted by the vehicle-mounted KMS.

S318. the ECU1 in the vehicle 300 determines whether the received encrypted seed is identical to the locally encrypted seed.

The locally encrypted seed may be referred to as a seed encrypted by the ECU1.

S319. in the case of coincidence, the ECU1 in the vehicle 300 transmits the instruction information indicating the passing of the authentication of the secure access to the diagnostic apparatus 200.

In the case of agreement, it is explained that the ECU1 determines that the diagnostic apparatus 200 has authority to access the resources of the ECU (e.g., the ECU 1) or to perform fault diagnosis on the ECU.

The ECU1 in the vehicle 300 transmits, to the diagnostic apparatus 200, instruction information (e.g., a first message) that the authentication of the secure access is passed, which indicates that the vehicle 300 determines that the diagnostic apparatus 200 has authority to access the controlled resource of the ECU1 or diagnose the ECU1. Thereafter, the diagnostic apparatus 200 can access the controlled resources on the ECU1 or perform fault diagnosis on the ECU1.

The ECU1 in the vehicle 300 may directly send the instruction information to the diagnostic apparatus 200, or the vehicle-mounted KMS may intercept the instruction information sent by the ECU1 and forward the instruction information to the diagnostic apparatus 200.

S320. the diagnostic apparatus 200 transmits a diagnostic request to the ECU1 in the vehicle 300.

After the diagnostic apparatus 200 completes the authentication of the secure access, the diagnostic apparatus 200 may initiate a diagnosis to the target ECU, i.e., the ECU1, wherein the diagnosis request is for triggering access to resources in the ECU1 or for triggering a failure diagnosis to the ECU1, in other words, the diagnosis request is for requesting acquisition of diagnosis data in the ECU1.

Similar to the secure access request, the diagnostic request may carry a diagnostic service identifier SID in the UDS protocol, where the diagnostic service identifier SID is used for a diagnostic service initiated by the diagnostic apparatus to the vehicle, and the ECU1 may determine a diagnostic service specifically initiated by the diagnostic apparatus 200 according to the SID, and return diagnostic data required for the corresponding diagnostic service.

In addition, it should be noted that the diagnostic apparatus 200 may directly send the diagnostic request to the ECU1, or the vehicle-mounted KMS may intercept the diagnostic request and send the diagnostic request to the ECU1.

In the embodiment of the present application, this diagnostic request for the ECU1 may also be referred to as a first diagnostic request for requesting acquisition of diagnostic data of the ECU1, and the diagnostic request for the ECU2 may also be referred to as a second diagnostic request for requesting acquisition of diagnostic data of the ECU 2.

S321. the ECU1 in the vehicle 300 transmits the diagnostic data to the diagnostic apparatus 200.

In response to the diagnosis request, the ECU1 searches for the diagnosis data requested by the diagnosis request and transmits the diagnosis data to the diagnostic apparatus 200.

The ECU1 in the vehicle 300 may directly send the diagnostic data to the diagnostic apparatus 200, or the vehicle-mounted KMS may intercept the diagnostic data sent by the ECU1 and forward the same to the diagnostic apparatus 200.

In addition, as can be seen from fig. 5, steps S305 to S311 are the above-mentioned security access authentication process for the outside of the vehicle, and steps S312 to S318 are the above-mentioned security access authentication process for the inside of the vehicle. The diagnostic apparatus 200 authenticates with the vehicle 300 using the ECU temporary key in the security access authentication process outside the vehicle, and the vehicle-mounted KMS and ECU1 in the vehicle 300 authenticate using the ECU key in the security access authentication process inside the vehicle.

It should be appreciated that the content of the interaction between the diagnostic apparatus 200 and the vehicle 300, such as the secure access request, the indication of passing authentication, the diagnostic request, the diagnostic data, etc., may be interacted with by the communication standard of the UDS protocol.

It can be seen that the diagnosis instrument and the ECU hold different keys through the authentication process of the safety access between the diagnosis instrument and the ECU by the vehicle-mounted KMS, so that the influence caused by key leakage is reduced as much as possible.

In addition, in addition to the fact that the same key is no longer used for the security access authentication on the diagnostic apparatus and the ECU as described in the flowchart shown in fig. 5, the key for the security access authentication may no longer be held on the diagnostic apparatus, at which time the diagnostic apparatus no longer initiates a security access request to the diagnostic apparatus through the UDS27 service, but directly initiates a diagnostic request, that is to say, the security access authentication is no longer performed outside the vehicle, but the security access authentication is retained inside the vehicle, as described in detail below with respect to the flowchart shown in fig. 6.

As shown in fig. 6, the second stage mainly includes:

s401, the server 100 and the diagnostic instrument 200 finish diagnostic instrument authentication.

Before the diagnostic apparatus 200 diagnoses the vehicle 300, the diagnostic apparatus 200 needs to authenticate to the server 100 to prove the validity of the identity thereof.

The diagnostic apparatus 200 may complete the diagnostic apparatus authentication by transmitting a digital certificate of the diagnostic apparatus 200 to the server 100, thereby proving the validity of the diagnostic apparatus 200. The authentication process may be specifically related to the foregoing step S301, and will not be described herein.

In addition, after the server 100 determines that the diagnostic apparatus 200 is legal, the instruction information indicating the passing of authentication may be transmitted to the diagnostic apparatus 200 so that the diagnostic apparatus 200 is authenticated to the vehicle 300.

It will be appreciated that step S401 is an optional step, and the diagnostic apparatus 200 may trigger diagnosis directly after passing the authentication of the diagnostic apparatus by the vehicle 300, which is not limited in this embodiment of the present application.

S402, the diagnostic apparatus 200 and the vehicle-mounted KMS in the vehicle 300 complete diagnostic apparatus authentication.

After the diagnostic instrument 200 passes the diagnostic instrument authentication with the server 100, the diagnostic instrument 200 may then authenticate to the vehicle 300 to prove the legitimacy of its identity.

Similar to step S401, the diagnostic apparatus 200 may complete the diagnostic apparatus authentication by transmitting the digital certificate of the diagnostic apparatus 200 to the vehicle 300, proving the validity of the diagnostic apparatus 200.

In addition, after the vehicle 300 determines that the diagnostic apparatus 200 is legal, the instruction information indicating the passing of the authentication may be transmitted to the diagnostic apparatus 200.

S403, after the authentication is passed, the diagnostic apparatus 200 sends a diagnosis request to the vehicle-mounted KMS in the vehicle 300.

After authentication of the diagnostic apparatus 200 with the server 100 and authentication of the diagnostic apparatus 200 with the vehicle 300 pass, the diagnostic apparatus 200 may transmit a diagnostic request for requesting acquisition of diagnostic data of the ECU1 to the vehicle 300.

It should be understood that the diagnostic apparatus 200 originally transmits the diagnosis request to the ECU1, and the in-vehicle KMS may intercept the diagnosis request transmitted from the diagnostic apparatus 200 to the ECU1, so that the diagnostic apparatus 200 transmits the diagnosis request to the in-vehicle KMS specifically after the authentication is passed.

As can be seen from comparing the foregoing steps S305 to S311, in step S403, the diagnostic apparatus 200 skips the UDS 27 service, directly initiates a diagnostic service to the ECU1, and requests to acquire diagnostic data of the ECU1. Thus, the diagnostic apparatus 200 does not hold a key for security access authentication, and the hidden trouble of the diagnostic apparatus leaking the ECU key is eliminated.

S404, the vehicle-mounted KMS in the vehicle 300 sends the security access request to the ECU1.

After acquiring the diagnosis request, the in-vehicle KMS transmits a secure access request to the ECU1. The secure access request is for requesting acquisition of a seed. The description of the secure access request may refer to the relevant content of the foregoing step S305 or S312, and will not be repeated here.

It can be seen that the vehicle KMS still retains the secure access authentication procedure prior to diagnosis, so that the ECU1 still operates according to the steps of authentication before diagnosis, thus eliminating the need to alter the configuration of the ECU, and increasing the feasibility of implementation of the solution on a vehicle.

S405. the ECU1 in the vehicle 300 generates seeds.

S406, the ECU1 in the vehicle 300 sends the seed to the vehicle-mounted KMS.

S407. the onboard KMS in the vehicle 300 encrypts the seed with the ECU key.

S408. the ECU1 in the vehicle 300 encrypts the seed using the ECU key.

S409, the vehicle-mounted KMS in the vehicle 300 sends the encrypted seeds to the ECU1.

S410, the ECU1 in the vehicle 300 judges whether the received encrypted seeds are consistent with the locally encrypted seeds.

It should be understood that steps S405-S410 are the same as steps S313-S318, and may be referred to correspondingly, and will not be described again here.

S411. in the case of coincidence, the ECU1 in the vehicle 300 transmits, to the vehicle-mounted KMS, instruction information that the authentication of the secure access is passed.

It should be understood that the ECU1 originally transmits the instruction information indicating the authentication of the secure access to the diagnostic apparatus 200, and the in-vehicle KMS may intercept the instruction information in the middle so that the ECU1 transmits the instruction information indicating the authentication of the secure access to the in-vehicle KMS.

S412, the onboard KMS in the vehicle 300 sends the diagnosis request to the ECU1.

After the in-vehicle KMS knows that the authentication of the secure access is passed, the in-vehicle KMS may transmit a diagnosis request transmitted by the diagnostic apparatus 200 to the ECU1.

S413. the ECU1 in the vehicle 300 transmits the diagnostic data to the diagnostic apparatus 200.

It should be understood that the steps shown in fig. 6 and not mentioned above or not described in detail may refer to the flowchart shown in fig. 5, which is not described herein.

In general, the diagnostic apparatus may directly initiate a diagnostic request to a target ECU in the vehicle after double authentication with the server and the vehicle, and the vehicle interior may complete secure access authentication using the ECU key first, and then transmit diagnostic data to the diagnostic apparatus in response to the diagnostic request after the authentication is passed. Therefore, the diagnostic instrument does not hold a secret key for safety access authentication, the possibility of secret key leakage of the diagnostic instrument is eliminated, the reliability of safety access authentication of the diagnostic instrument and the ECU is improved, and the safety of a vehicle is enhanced.

Fig. 7 is a schematic structural diagram of a vehicle 300 according to an embodiment of the present application.

As shown in fig. 7, the vehicle 300 includes: a controller area network (controller area network, CAN) bus 11, a plurality of electronic control units (electronic control unit, ECU), an engine 13, a vehicle box (T-box) 14, a transmission 15, a tachograph 16, an antilock system (antilock brake system, ABS) 17, a sensor system 18, an image pickup system 19, a microphone 20, and the like.

The CAN bus 11 is a serial communication network supporting distributed control or real-time control for connecting the respective components of the vehicle 300. Any component on CAN bus 11 CAN listen to all data transmitted on CAN bus 11. The frames transmitted by CAN bus 11 may include data frames, remote frames, error frames, overload frames, different frames transmitting different types of data. In the present embodiment, the CAN bus 11 may be used to transmit data related to each component in a voice command based control method, and specific implementation of this method may be referred to in the following detailed description of the method embodiment.

Not limited to the CAN bus 11, in other embodiments, the various components of the vehicle 300 may also be connected and communicate in other ways. For example, the components may also communicate via an on-board ethernet (ethernet) local interconnect network (local interconnect network, LIN) bus, flexRay, and a conventional on-board network system (media oriented systems, MOST) bus, to name a few. The following embodiments are described in terms of the various components communicating via the CAN bus 11.

The ECU corresponds to a processor or a brain of the vehicle 300 for instructing the corresponding components to perform the corresponding actions according to the instructions acquired from the CAN bus 11 or according to the operations input by the user. The ECU may be composed of a security chip, a microprocessor ((microcontroller unit, MCU), a random access memory (random access memory, RAM), a Read Only Memory (ROM), an input/output interface (I/O), an analog/digital converter (a/D converter), and a large scale integrated circuit for input, output, shaping, driving, and the like.

The ECU is of a wide variety and different kinds of ECU can be used to realize different functions.

In the embodiment of the present application, the ECU may also store other functional modules in the vehicle 300, such as ECU keys generated by the vehicle-mounted KMS. In addition, the ECU, which is the object of diagnosis by the diagnostic apparatus, for example, the diagnostic apparatus 200, may communicate with the diagnostic apparatus 200 based on the UDS protocol, complete the security access authentication process with the diagnostic apparatus 200, and transmit diagnostic data to the diagnostic apparatus 200 based on the diagnostic request transmitted by the diagnostic apparatus 200 after the authentication is passed.

The plurality of ECUs in the vehicle 300 may include, for example: an engine ECU121, an ECU122 of a vehicle box (T-box), a transmission ECU123, a drive recorder ECU124, an anti-lock brake system (antilock brake system, ABS) ECU 125, and the like.

The engine ECU121 is used to manage the engine, coordinate various functions of the engine, and may be used to start the engine, shut down the engine, and the like, for example. The engine is a device that powers the vehicle 300. An engine is a machine that converts some form of energy into mechanical energy. The vehicle 300 may be used to burn chemical energy of liquid or gas, or to convert electrical energy into mechanical energy and output power to the outside. The engine component can comprise a crank connecting rod mechanism, a valve mechanism and five systems including a cooling system, a lubricating system, an ignition system, an energy supply system and a starting system. The main components of the engine are a cylinder body, a cylinder cover, a piston pin, a connecting rod, a crankshaft, a flywheel and the like.

The T-box ECU122 is for managing the T-box14.

The T-box14 is primarily responsible for communicating with the internet, providing a remote communication interface for the vehicle 300, and providing services including navigation, entertainment, driving data collection, driving track recording, vehicle fault monitoring, vehicle remote inquiry and control (e.g., lock-out, air conditioning control, window control, engine torque limitation, engine start-stop, seat adjustment, battery level inquiry, oil level, door status, etc.), driving behavior analysis, wireless hot spot sharing, road rescue, anomaly notification, etc.

The T-box14 may be used to communicate with an automotive remote service provider (telematics service provider, TSP) and user (e.g., driver) side electronics to enable vehicle status display and control on the electronics. After the user sends a control command through the vehicle management application on the electronic device, the TSP sends a request command to the T-box14, and after the T-box14 acquires the control command, the control message is sent through the CAN bus to control the vehicle 300, and finally, the operation result is fed back to the vehicle management application on the electronic device on the user side. That is, the data read by the T-box14 through the CAN bus 11, such as the data of the vehicle condition report, the driving report, the fuel consumption statistics, the violation inquiry, the position track, the driving behavior, etc., may be transmitted to the TSP background system through the network, and forwarded to the electronic device at the user side by the TSP background system for the user to check.

The T-box14 may include a communication module and a display screen, in particular.

The communication module may be configured to provide wireless communication functions, and support the vehicle 300 to communicate with other devices via wireless local area networks (wireless local area networks, WLAN) (e.g., wi-Fi network, wireless fidelity), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), ultra-wideband (UWB), and other wireless communication technologies. The communication module may also be used to provide mobile communication functions to support the vehicle 300 in communication with other devices via the global system for mobile communications (global system for mobile communications, GSM), universal mobile telecommunications system (universal Mobile telecommunications system, UMTS), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), 5G, and future-emerging 6G, among other communication technologies.

The communication module may establish a connection and communicate with a variety of things (vehicle to everything, V2X) communication technology (cellular V2X, C-V2X) and other devices such as servers, user-side electronic devices, etc. via a cellular network based vehicle. The C-V2X may include, for example, V2X (LTE-V2X), 5G-V2X, etc., based on long term evolution (long term evolution, LTE).

In some embodiments, the communication module may be used to enable communication between the vehicle 300 and a server, such as the server 100, to send a vehicle key in the vehicle 300 to the server 100, or to receive a vehicle key sent by the server 100, and so on.

The display screen is used to provide a visual interface for the driver. The vehicle 300 may include one or more displays therein, such as an onboard display disposed in front of the operator's seat, a display disposed above the seat for displaying ambient conditions, a head up digital display (HUD) that projects information onto the windshield, and the like.

T-box14 may also be referred to as a vehicle system, a telematics device, a vehicle gateway, etc., and embodiments of the present application are not limited in this regard.

The transmission ECU123 is for managing the transmission.

The transmission 15 may be used as a mechanism for varying the rotational speed and torque of the engine, which can fix or shift the ratio of the output shaft to the input shaft. The transmission 15 components may include a variable speed drive, an operating mechanism, a power take off mechanism, and the like. The main function of the variable speed transmission mechanism is to change the numerical value and direction of torque and rotating speed; the main function of the control mechanism is to control the transmission mechanism to realize the change of the transmission ratio of the transmission, namely the gear shift, so as to achieve the purposes of speed change and torque conversion.

The event data recorder ECU124 is for managing the event data recorder 16.

The components of the tachograph 16 may include a host computer, a vehicle speed sensor, data analysis software, and the like. The drive recorder 16 is an instrument for recording images and sounds during the running of the vehicle, including information about the time, speed, position, etc. In the embodiment of the present application, when the vehicle runs, the vehicle speed sensor collects the wheel rotation speed, and sends the vehicle speed information to the vehicle recorder 16 through the CAN bus.

The ABS ECU125 is for managing the ABS17.

The ABS17 is configured to automatically control the magnitude of the braking force of the brake when the vehicle is braked, so that the wheels are not locked and are in a state of rolling and sliding at the same time, so as to ensure that the adhesion between the wheels and the ground is maximum. In the braking process, when the electronic control device judges that the wheels tend to lock according to the wheel rotating speed signals input by the wheel rotating speed sensor, the ABS enters an anti-lock braking pressure adjusting process.

The sensor system 18 may include: acceleration sensor, vehicle speed sensor, vibration sensor, gyro sensor, radar sensor, signal transmitter, signal receiver, etc. The acceleration sensor and the vehicle speed sensor are used to detect the speed of the vehicle 300. The shock sensor may be disposed under the seat, in the seat belt, in the seat back, in the operator panel, in the air bag, or in other locations for detecting whether the vehicle 300 is crashed and where the user is located. The gyroscopic sensor may be used to determine a motion pose of the vehicle 300. The radar sensor may include a lidar, an ultrasonic radar, a millimeter wave radar, or the like. The radar sensor is used to emit electromagnetic waves to irradiate a target and receive echoes thereof, thereby obtaining information of a distance, a distance change rate (radial velocity), an azimuth, an altitude, and the like of the target to an electromagnetic wave emission point, thereby identifying other vehicles, pedestrians, roadblocks, and the like near the vehicle 300. The signal transmitter and the signal receiver are used for receiving signals, which can be used for detecting the position of the user, and the signals can be ultrasonic waves, millimeter waves, laser, etc.

The camera system 19 may include a plurality of cameras for capturing still images or video. The camera in the camera system 19 can be arranged at the front, rear, side, in-car and other positions, so that the functions of driving assistance, driving recording, panoramic looking around, in-car monitoring and the like can be realized conveniently.

The sensor system 18 and the camera system 19 can be used for detecting the surrounding environment, so that the vehicle 300 can conveniently make corresponding decisions to cope with environmental changes, and can be used for completing tasks focusing on the surrounding environment in an automatic driving stage.

A microphone 20, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or outputting a voice command, the user can sound near the microphone 20 through the mouth, inputting a sound signal to the microphone 20. The vehicle 300 may be provided with at least one microphone 20. In other embodiments, the vehicle 300 may be provided with two microphones 20, and may perform a noise reduction function in addition to collecting sound signals. In other embodiments, the vehicle 300 may also be provided with three, four, or more microphones 20, forming a microphone array, enabling collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.

In addition, the vehicle 300 may also include multiple interfaces, such as a USB interface, an RS-232 interface, an RS485 interface, etc., that may be externally connected to a camera, a microphone, an earphone, and a user-side electronic device.

In the present embodiment, the microphone 20 may be used to detect voice commands entered by a user. The sensor system 18, the camera system 19, the T-box14, etc. may be used to acquire character information of the user who inputs the voice instruction. For the manner in which the various components in the vehicle 300 obtain the user's role information, reference may be made to the relevant descriptions in the subsequent method embodiments. The T-box ECU122 may be configured to determine, according to the role information, whether the user currently has the authority corresponding to the voice command, and only if the user has the authority, the T-box ECU122 may schedule the corresponding component in the vehicle 300 to respond to the voice command.

It will be appreciated that the configuration illustrated in the embodiments of the present application does not constitute a specific limitation on the vehicle system. The number of electronic control units ECU is not limited in the embodiment of the present application. The vehicle 300 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

For example, the vehicle 300 may also include separate memories, batteries, lights, wipers, dashboards, audio, vehicle terminals (transmission control unit, TCU), auxiliary control units (auxiliary control unit, ACU), intelligent access and start systems (passive entry passive start, PEPS), on Board Units (OBU), body control modules (body control module, BCM), charging interfaces, and the like.

In addition, it should be noted that a vehicle KMS (not shown in the figure) in the vehicle 300 is configured to monitor and intercept data communicated between the diagnostic apparatus and the ECU, and send the data to the diagnostic apparatus or the ECU, so as to implement secure access authentication between the diagnostic apparatus and the ECU. For example, the in-vehicle KMS may intercept a security access request sent from the diagnostic apparatus 200 to the ECU1, perform security access authentication with the diagnostic apparatus 200 based on the security access request, send the security access request to the ECU1 after the authentication is passed, perform security access authentication with the ECU1, and the like. It should be understood that the on-board KMS mentioned in the embodiments of the present application may be a single hardware device for implementing the above functions in the vehicle 300, or may be a hardware cluster, a chip system, or the like for implementing the above functions, which is not limited in the embodiments of the present application.

As shown in fig. 8, the electronic device 400 may include: one or more processors 201, memory 202, communication interface 203, transmitter 205, receiver 206, coupler 207, and antenna 208. These components may be connected by a bus 204 or otherwise, fig. 8 being an example of a connection via a bus. Wherein:

the communication interface 203 may be used for the electronic device 400 and other communication devices. In particular, the communication interface 203 may be a 3G communication interface, a Long Term Evolution (LTE) (4G) communication interface, a 5G communication interface, a WLAN communication interface, a WAN communication interface, and the like. Not limited to a wireless communication interface, the electronic device 400 may also be configured with a wired communication interface 203 to support wired communication, such as when the electronic device 400 is a diagnostic instrument, communication between the electronic device 400 and the vehicle may be via a wired connection.

In some embodiments of the present application, the transmitter 205 and the receiver 206 may be considered as one wireless modem. The transmitter 205 may be used to transmit the signal output by the processor 201. The receiver 206 may be used to receive signals. In the electronic device 400, the number of transmitters 205 and receivers 206 may each be one or more. The antenna 208 may be used to convert electromagnetic energy in the transmission line into electromagnetic waves in free space or to convert electromagnetic waves in free space into electromagnetic energy in the transmission line. Coupler 207 may be used to split the mobile communication signal into multiple paths that are distributed to multiple receivers 206. It is appreciated that the antenna 208 of the electronic device 400 may be implemented as a large-scale antenna array.

Memory 202 is coupled to processor 201 for storing various software programs and/or sets of instructions. In particular, memory 202 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

The memory 202 may store an operating system (hereinafter referred to as a system), such as an embedded operating system, for example uCOS, vxWorks, RTLinux.

In the present embodiment, the processor 201 may be used to read and execute computer readable instructions.

In the embodiment of the present application, when the electronic device 400 is the server 100:

the processor 201 is operable to generate a key according to a key algorithm, including: vehicle keys, ECU temporary keys, etc., from which the ECU keys are derived according to a key derivation algorithm.

The transmitter 205 may be used to transmit a vehicle key, or an ECU temporary key, or the like.

The receiver 206 may be used to receive a vehicle key, or a digital certificate of a diagnostic instrument, or the like.

The memory 202 may be used to store key algorithms, key derivation algorithms, and vehicle keys, ECU temporary keys, and the like.

In the embodiment of the present application, when the electronic device 400 is the diagnostic apparatus 200:

The processor 201 may be configured to encrypt the seed using the ECU temporary key.

The transmitter 205 may be used to send secure access requests or diagnostic requests, as well as encrypted seeds, and the like.

The receiver 206 may be used to receive seeds, authenticated knowledge of secure access, diagnostic data, and the like.

The memory 202 may be used to store key algorithms, diagnostic data for the vehicle, and the like.

In addition, when the electronic device 400 is the diagnostic apparatus 200, the electronic device 400 may further include a display screen for displaying fault information of the vehicle.

Details of the server 100 and the diagnostic apparatus 200 not mentioned may be found in the foregoing, and will not be described herein.

It should be understood that the steps in the above-described method embodiments may be accomplished by integrated logic circuitry in hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware processor or in a combination of hardware and software modules in a processor.

The application also provides an electronic device, which may include: memory and a processor. Wherein the memory is operable to store a computer program; the processor may be configured to invoke the computer program in the memory to cause the electronic device to perform the method performed by the server 100, the diagnostic apparatus 200 or the vehicle 300 in any of the embodiments described above.

The present application also provides a chip system comprising at least one processor for implementing the functions involved in the method performed by the server 100, the diagnostic apparatus 200 or the vehicle 300 in any of the embodiments described above.

In one possible design, the system on a chip further includes a memory to hold program instructions and data, the memory being located either within the processor or external to the processor.

The chip system may be formed of a chip or may include a chip and other discrete devices.

Alternatively, the processor in the system-on-chip may be one or more. The processor may be implemented in hardware or in software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general purpose processor, implemented by reading software code stored in a memory.

Alternatively, the memory in the system-on-chip may be one or more. The memory may be integrated with the processor or may be separate from the processor, and embodiments of the present application are not limited. For example, the memory may be a non-transitory processor, such as a ROM, which may be integrated on the same chip as the processor, or may be separately disposed on different chips, and the type of memory and the manner of disposing the memory and the processor in the embodiments of the present application are not specifically limited.

Illustratively, the system-on-chip may be a field programmable gate array (field programmable gate array, FPGA), an application specific integrated chip (application specific integrated circuit, ASIC), a system on chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (digital signal processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip.

The present application also provides a computer program product comprising: a computer program (which may also be referred to as code, or instructions), when executed, causes a computer to perform the method performed by any of the server 100, diagnostic apparatus 200, or vehicle 300 in any of the embodiments described above.

The present application also provides a computer-readable storage medium storing a computer program (which may also be referred to as code, or instructions). The computer program, when executed, causes a computer to perform the method performed by any of the server 100, diagnostic apparatus 200, or vehicle 300 in any of the embodiments described above.

It should be appreciated that the processor in the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a digital signal processor (digital signal processor, DSP), an application specific integrated circuit (AP 800plication specific integrated circuit,ASIC), a field programmable gate array (field programmable gate array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

In addition, the embodiment of the application also provides a device. The apparatus may be a component or module in particular, and may comprise one or more processors and memory coupled. Wherein the memory is for storing a computer program. The computer program, when executed by one or more processors, causes an apparatus to perform the methods of the method embodiments described above.

Wherein an apparatus, a computer-readable storage medium, a computer program product, or a chip provided by embodiments of the present application are each configured to perform the corresponding method provided above. Therefore, the advantages achieved by the method can be referred to as the advantages in the corresponding method provided above, and will not be described herein.

The embodiments of the present application may be arbitrarily combined to achieve different technical effects.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may 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 processes or functions described in the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may 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 may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

In summary, the foregoing description is only exemplary embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made according to the disclosure of the present invention should be included in the protection scope of the present invention.

Claims

1. A vehicle security access method, the method being applied to a vehicle including a first ECU, the vehicle storing a first key that is temporarily valid for a first period of time, and a second key of the first ECU, the method comprising:

the vehicle receives a first security access request sent by first equipment;

the vehicle verifies whether the first device has the right to access the first ECU by using the first key in the first period, and only the device storing the first key has the right to access the first ECU;

After the vehicle determines that the first device has the authority, the authentication process in the vehicle is executed by using the second key;

the vehicle sends a first message to the first device, the first message being used to indicate that the vehicle has passed authentication of the first device;

the vehicle receives a first diagnosis request sent by the first equipment;

in response to the first diagnostic request, the vehicle transmits diagnostic data of the first ECU to the first device.

2. The method according to claim 1, wherein the vehicle verifies, using the first key, whether the first device is authorized to access the first ECU, in particular comprising:

the vehicle generates a first seed and sends the first seed to the first device;

the vehicle receives the first seed encrypted by the first device by using a third key;

the vehicle verifies whether the first seed encrypted by the third key is consistent with the first seed encrypted by the first key; and in case of coincidence, the first device has the right to access the first ECU.

3. The method of claim 2, wherein the vehicle further comprises a KMS, and wherein the vehicle verifies that the first device has permission to access the first ECU using the first key, comprising:

the vehicle generates a first seed through the KMS, and sends the first seed to the first device through the KMS;

receiving, by the KMS, the first seed encrypted by the first device using a third key;

verifying whether the first seed encrypted by the third key is consistent with the first seed encrypted by the first key through the KMS; and in case of coincidence, the first device has the right to access the first ECU.

4. A method according to any one of claims 1-3, wherein the first key is a server generated key managed and maintained by a manufacturer of the component of the vehicle.

5. The method of any of claims 1-4, wherein prior to the vehicle receiving the first secure access request sent by the first device, the method further comprises:

the vehicle receives an authorization file sent by the first device, wherein the authorization file comprises: the first key, the invalidation parameter and the signature determined according to the first key and the invalidation parameter; wherein the revocation parameter is used to indicate the first period of time, the signature characterizing the first key and revocation parameter in the authorization file being generated by a device trusted by the vehicle.

6. The method of claim 5, wherein the step of determining the position of the probe is performed,

before the vehicle receives the authorization file sent by the first device, the method further comprises:

the vehicle receives a digital certificate sent by the first device, and the digital certificate characterizes the first device as a device with trusted identity;

or,

the vehicle receives the authorization file sent by the first device, and specifically includes:

the vehicle receives the authorization file sent by the first device through a UDS 2904 service, and the UDS 2904 service is used for proving that the first device is a device with trusted identity.

7. The method according to claim 5 or 6, wherein the authorization file further comprises: vehicle information indicating the vehicle, the signature being further determined from the vehicle information.

8. The method of any of claims 1-7, wherein the vehicle further comprises a second ECU, the fourth key of the second ECU further stored, the method further comprising:

the vehicle receives a third security access request sent by the first device;

the vehicle verifies whether the first device has the right to access the second ECU by using the first key in the first period, and only the device storing the first key has the right to access the second ECU;

After the vehicle determines that the first device has the right to access the second ECU, the vehicle executes an authentication process inside the vehicle by using the fourth key;

the vehicle sends a second message to the first device, the second message being used to indicate that the vehicle has passed the authentication of the first device;

the vehicle receives a second diagnosis request sent by the first device;

in response to the second diagnostic request, the vehicle transmits diagnostic data of the second ECU to the first device.

9. A vehicle security access method, characterized in that the method is applied to a vehicle including a first ECU, the vehicle storing a second key of the first ECU, the method comprising:

the vehicle receives a first diagnosis request sent by first equipment, wherein the first equipment is trusted equipment of the vehicle;

the vehicle performs a secure access authentication process of the vehicle interior using the second key;

10. The method of claim 9, wherein prior to the vehicle receiving the first diagnostic request sent by the first device, the method further comprises:

The vehicle receives a digital certificate sent by the first device, and the digital certificate characterizes the first device as a device with trusted identity.

11. The method of claim 9 or 10, wherein the vehicle further comprises a second ECU, the vehicle further storing a fourth key of the second ECU, the method further comprising:

the vehicle receives a second diagnosis request sent by first equipment, wherein the first equipment is trusted equipment of the vehicle;

the vehicle performs a security access authentication process of the vehicle interior using the fourth key;

12. The method according to any one of claims 1-11, wherein the vehicle further comprises a KMS, wherein the vehicle performs an authentication process of the vehicle interior using the second key, comprising in particular:

the vehicle performs, via the KMS and the first ECU:

the KMS sends a second secure access request to the first ECU;

the first ECU generates a second seed and sends the second seed to the KMS;

the KMS encrypts the second seed by using the second key and sends the second seed encrypted by using the second key to the first ECU;

The first ECU verifies that the second seed encrypted by the KMS by using the second key is consistent with the seed encrypted by the first ECU by using the second key.

13. The method of any of claims 1-12, wherein the second key is a key generated by the vehicle using a first vehicle key, wherein the vehicle keys are different for different vehicles.

14. A method of vehicle security access, the method being applied to a first device, the method comprising:

the first device sends a first secure access request to a vehicle;

in a case where the vehicle has authority to access a first ECU in the vehicle and performs an authentication process inside the vehicle using a second key using a first key temporarily valid during a first period, the first device receives a first message sent by the vehicle, the first message being for indicating that the vehicle has passed the authentication of the first device;

the first device sending a first diagnostic request to the vehicle;

the first device receives diagnostic data of the first ECU transmitted by the vehicle.

15. The method of claim 14, wherein during the verifying that the first device has the right to access the first ECU in the vehicle using the first key that is temporarily valid for the first period of time, the method further comprises:

the first device obtains a first seed generated by the vehicle;

the first device encrypts the first seed using the first key;

and the first device sends the first seed encrypted by the first key to the vehicle.

16. The method of claim 14 or 15, wherein before the first device sends the first secure access request to the vehicle, the method further comprises:

the first device obtains the first key sent by a second device, which is a server managed and maintained by a manufacturer that manufactures the components of the vehicle.

17. The method according to claim 16, wherein the first device obtains the first key sent by the second device, specifically including:

the first device obtains an authorization file sent by the second device, where the authorization file includes: the first key, the invalidation parameter and the signature determined according to the first key and the invalidation parameter; wherein the revocation parameter is used to indicate the first period of time, the signature characterizing the first key and revocation parameter in the authorization file being generated by the second device.

18. The method of claim 17, wherein after the first device obtains the authorization file sent by the second device, the method further comprises:

the first device sends the authorization file to the vehicle.

19. The method of claim 18, wherein before the first device sends the authorization file to the vehicle, the method further comprises:

the first device sends a digital certificate to the vehicle, wherein the digital certificate characterizes the first device as an identity trusted device;

or,

the first device sends the authorization file to the vehicle, and specifically includes:

the first device sends the authorization file to the vehicle through a UDS 2904 service, and the UDS 2904 service is used for proving that the first device is an identity trusted device.

20. The method according to any one of claims 17-19, wherein the authorization file further comprises: vehicle information indicating the vehicle, the signature being further determined from the vehicle information.

21. A method of vehicle security access, the method being applied to a first device, the method comprising:

The first device authenticates the identity of the first device to the vehicle as being authentic;

the first device sending a first diagnostic request to the vehicle;

in the case where the vehicle performs a security access authentication process of the vehicle interior using the second key of the first ECU, the first device acquires diagnostic data of the first ECU in the vehicle transmitted by the vehicle.

22. The method of claim 21, wherein the first device authenticates the identity of the first device to the vehicle as trusted, comprising:

the first device sends a digital certificate to the vehicle, the digital certificate characterizing the first device as an identity trusted device.

23. The method of claim 22, wherein prior to the first device sending the digital certificate to the vehicle, the method further comprises:

the first device sends the digital certificate to a second device;

the first device sends a digital certificate to the vehicle, and specifically comprises:

and the first device sends the digital certificate to the vehicle under the condition that the second device determines that the first device identity is trusted according to the digital certificate.

24. The method of any of claims 14-23, wherein the second key is a key generated by the vehicle using a first vehicle key, wherein the vehicle keys are different for different vehicles.

25. A vehicle comprising a memory, one or more processors, and one or more programs; the one or more processors, when executing the one or more programs, cause the vehicle to implement the method of any of claims 1-13.

26. An electronic device comprising a memory, one or more processors, and one or more programs; the one or more processors, when executing the one or more programs, cause the electronic device to implement the method of any of claims 14-24.

27. A communication system comprising a vehicle according to claim 25 and an electronic device according to claim 26.

28. A computer readable storage medium comprising instructions which, when run on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 13, or 14 to 24.