Diagnostic device identity authentication method and device, and vehicle

Abstract

The application discloses a kind of diagnostic equipment identity authentication method, device and vehicle, wherein the method comprises: firewall is in the case where identity authentication request and public key certificate sent by the diagnostic equipment are received, the public key certificate is checked;In the case where checking succeeds, authentication identification is sent to the diagnostic equipment, to make the diagnostic equipment generate signature data based on the authentication identification and the preset data;In the case where the signature data sent by the diagnostic equipment is received, the signature data is verified according to the authentication identification, the preset data and the public key certificate;In the case where verifying succeeds, it is judged that the identity authentication of the diagnostic equipment passes.Through the technical scheme provided in the application, the diagnostic equipment can be verified by digital certificate and preset data double factor, to ensure that only the diagnostic equipment with identity authentication can access OBD interface, and the security of vehicle data is guaranteed.

Description

Technical Field

[0001] This application belongs to the field of vehicle safety technology, and in particular relates to a diagnostic device authentication method, device and vehicle. Background Technology

[0002] With the development of automotive electronics and intelligence, vehicles integrate a large number of electronic control systems and sensors. These systems and sensors can monitor and record the vehicle's operating status and fault information in real time. Local diagnostics, which utilizes onboard diagnostic tools or equipment to communicate with the vehicle's electronic control systems through the vehicle's local diagnostic interface (such as OBD (On-Board Diagnostics) interface) to read fault codes and data streams, is crucial for vehicle repair, maintenance, and troubleshooting. Local diagnostics helps repair personnel quickly and accurately locate vehicle faults, improving repair efficiency, reducing repair costs, and enhancing the driving experience for car owners.

[0003] As the entry point for local vehicle diagnostics, the OBD interface is directly related to the security of vehicle data. Once the OBD interface is illegally accessed or hacked, hackers can easily obtain sensitive vehicle information, such as driving routes and driving habits, thus threatening the owner's privacy. Furthermore, hackers may also maliciously tamper with or control the electronic control system through the OBD interface, leading to serious consequences such as vehicle malfunctions and safety accidents. Therefore, strengthening the protection of the OBD interface and ensuring that only authorized diagnostic equipment can access it is of great significance for ensuring the security of vehicle data and improving the vehicle's security capabilities.

[0004] In related technologies, security protection for OBD interfaces typically employs methods such as setting simple passwords and using dedicated diagnostic equipment to connect to the OBD interface. These methods are easily cracked, lack sufficient security, and cannot meet the high data security requirements of modern vehicles. Summary of the Invention

[0005] The embodiments of this application provide a diagnostic device authentication method, apparatus, and vehicle, thereby improving the security of vehicle data by at least to some extent through two-factor authentication of the diagnostic device.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to a first aspect of the embodiments of this application, a method for authenticating a diagnostic device is provided, applied to a vehicle, wherein the vehicle's on-board automatic diagnostic system (OBD) interface is equipped with a firewall, and the firewall and the diagnostic device are configured with the same preset data, the authentication method comprising:

[0008] Upon receiving an authentication request and public key certificate from the diagnostic device, the firewall verifies the public key certificate.

[0009] If the verification is successful, an authentication identifier is sent to the diagnostic device so that the diagnostic device can generate signature data based on the authentication identifier and the preset data;

[0010] Upon receiving the signature data sent by the diagnostic device, the signature data is verified based on the authentication identifier, the preset data, and the public key certificate;

[0011] If the signature verification is successful, the diagnostic device is deemed to have passed identity authentication.

[0012] In some embodiments, verifying the signature data based on the authentication identifier, the preset data, and the public key certificate includes:

[0013] The signature data is decrypted using the public key certificate to obtain decrypted data;

[0014] The authentication identifier and the preset data are concatenated and then hashed to obtain the hash result.

[0015] If the decrypted data is the same as the hash operation result, the signature verification is considered successful.

[0016] In some embodiments, verifying the public key certificate includes:

[0017] The validity of the public key certificate is verified according to the preset root certificate chain.

[0018] In some embodiments, before the firewall verifies the public key certificate upon receiving an authentication request and public key certificate from the diagnostic device, the authentication method further includes:

[0019] When the firewall is in diagnostic protection mode, it receives diagnostic requests sent by the diagnostic device.

[0020] Based on the diagnostic service corresponding to the diagnostic request, determine whether the diagnostic request is the identity authentication request.

[0021] In some embodiments, after determining that the diagnostic device has passed authentication, the authentication method further includes:

[0022] Exit the diagnostic protection state;

[0023] Receive diagnostic messages sent by the diagnostic device and the controller to be diagnosed, and forward the diagnostic messages.

[0024] In some embodiments, after exiting the diagnostic protection state, the authentication method further includes:

[0025] If the diagnostic message is not received within a preset time period, the system will re-enter the diagnostic protection state.

[0026] According to a second aspect of the embodiments of this application, an authentication device for a diagnostic device is provided, applied to a vehicle, wherein the vehicle's on-board automatic diagnostic system (OBD) interface is equipped with a firewall, the firewall and the diagnostic device are configured with the same preset data, and the authentication device includes:

[0027] The certificate verification module is used to verify the public key certificate upon receiving an authentication request and a public key certificate from the diagnostic device.

[0028] The signature module is used to send an authentication identifier to the diagnostic device when the verification is successful, so that the diagnostic device can generate signature data based on the authentication identifier and the preset data;

[0029] The signature verification module is used to verify the signature data based on the authentication identifier, the preset data, and the public key certificate when the signature data is received from the diagnostic device.

[0030] The identity verification module is used to determine that the identity authentication of the diagnostic device is successful if the signature verification is successful.

[0031] According to a third aspect of the embodiments of this application, a vehicle is provided, including a processor and a memory, the memory storing computer program instructions executable by the processor, wherein when the processor executes the computer program instructions, it implements the steps of the method as described in any of the first aspects above.

[0032] According to a fourth aspect of the embodiments of this application, an identity authentication system for a diagnostic device is provided, including a vehicle as described in the third aspect above and a diagnostic device, wherein the diagnostic device communicates with the vehicle through an OBD interface, and the firewall of the OBD interface and the diagnostic device are configured with the same preset data.

[0033] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein computer program instructions are stored therein, and when executed by a processor, the computer program instructions cause the processor to perform the steps of the method as described in any of the first aspects above.

[0034] In this application, upon receiving an authentication request and public key certificate from the diagnostic device, the firewall verifies the public key certificate. If the verification is successful, an authentication identifier is sent to the diagnostic device, enabling the diagnostic device to generate signature data based on the authentication identifier and preset data. Upon receiving the signature data from the diagnostic device, the firewall verifies the signature data according to the authentication identifier, the preset data, and the public key certificate. If the verification is successful, the diagnostic device's authentication is deemed successful. The technical solution provided in this application enables two-factor authentication of the diagnostic device using both digital certificates and preset data, ensuring that only authenticated diagnostic devices can access the OBD interface, thus guaranteeing the security of vehicle data.

[0035] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0037] Figure 1 A flowchart illustrating an authentication method for a diagnostic device in one embodiment is shown.

[0038] Figure 2 A schematic diagram of the interaction process between the firewall and the diagnostic device in one embodiment is shown;

[0039] Figure 3 A block diagram of an authentication device for a diagnostic device is shown in one embodiment;

[0040] Figure 4 A schematic diagram of the vehicle structure in one embodiment is shown. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0043] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0044] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0045] Figure 1 A flowchart illustrating an authentication method for a diagnostic device in one embodiment is shown. Figure 1 As shown, a diagnostic device authentication method is provided. This method is applied to a vehicle. The vehicle's OBD interface is equipped with a firewall. The firewall and the diagnostic device are configured with the same preset data. The method may include the following steps 101 to 104.

[0046] In step 101, the firewall verifies the public key certificate upon receiving the authentication request and public key certificate sent by the diagnostic device.

[0047] Understandably, a firewall can be deployed in the central gateway directly connected to the OBD interface within the vehicle, acting as the gateway to the OBD interface to protect data entering the OBD interface. By deploying an OBD interface firewall within the vehicle, diagnostic traffic from the OBD interface can be uniformly managed, effectively ensuring the information security of the controllers to be diagnosed within the vehicle.

[0048] In this embodiment, a dedicated state, namely the diagnostic protection state, is defined for diagnostic communication of the OBD interface. When the firewall is in the diagnostic protection state, all diagnostic services except those on the whitelist are prohibited from access. The whitelist includes necessary diagnostic services that can still be performed when the firewall is in the diagnostic protection state, such as diagnostic services in emissions certification and identity authentication services for diagnostic devices.

[0049] It should be noted that the preset data can be any form of data. In the implementation process, the preset data can be a mask, that is, a mask is configured for the firewall before the vehicle leaves the factory, and the diagnostic device is also configured with the same mask. This mask is mainly used as the salt value for hash calculation during the signing process. If the private key of the diagnostic device is leaked, the subsequent signature verification will fail as long as the mask is incorrect. This is equivalent to adding an identity authentication factor. Through two-factor authentication of digital certificates and masks, the security of identity authentication is greatly improved.

[0050] In some embodiments, when the firewall is in diagnostic protection mode, it receives diagnostic requests sent by diagnostic devices; and determines whether the diagnostic request is an authentication request based on the diagnostic service corresponding to the diagnostic request.

[0051] Understandably, a firewall can determine whether a diagnostic request is an authentication request by checking if the corresponding diagnostic service is the device's authentication service. If the service is, the request is considered an authentication request. Since the authentication service is on the whitelist, the firewall will allow diagnostic communication and receive the public key certificate sent by the device. If the service is not on the whitelist, the firewall will block the communication.

[0052] In some embodiments, the firewall can verify the legitimacy of the public key certificate based on a preset root certificate chain.

[0053] The preset root certificate chain can be a root certificate chain provided by the OEM (Original Equipment Manufacturer). The specific implementation method of the root certificate chain to verify the legality of the public key certificate is not limited in this application embodiment.

[0054] In step 102, if the verification is successful, an authentication identifier is sent to the diagnostic device so that the diagnostic device can generate signature data based on the authentication identifier and preset data.

[0055] The authentication identifier is a marker generated by the firewall after successful verification. This identifier is mainly used for subsequent signing and verification, as well as preventing replay attacks during the authentication process.

[0056] During implementation, after the firewall successfully verifies the public key certificate, it generates a 32-byte random number and sends this random number as an authentication identifier to the diagnostic device, enabling the diagnostic device to verify ownership of the public key certificate. If the firewall fails to verify the public key certificate, it stops the authentication process and returns a negative response to the diagnostic device.

[0057] Understandably, after receiving the authentication identifier, the diagnostic device can concatenate the authentication identifier and preset data, perform a hash operation, and obtain the hash result; then, it can use a private key to encrypt the hash result to obtain the signature data.

[0058] In some embodiments, after the authentication identifier and preset data are concatenated, a hash operation can be performed using the SHA256 algorithm to obtain the hash operation result, and then the hash operation result can be encrypted using the private key and the RSA2048 algorithm.

[0059] The signing process can be represented by the following formula:

[0060] Signature data = RSA2048_Encrypt(SHA256(CONCAT(authentication identifier, default data))).

[0061] After receiving the signed data, the diagnostic device sends the signed data to the firewall to prove that it does indeed own the public key certificate.

[0062] In step 103, upon receiving the signature data sent by the diagnostic device, the signature data is verified based on the authentication identifier, preset data, and public key certificate.

[0063] Understandably, after obtaining the signature data, the firewall can verify the signature based on the diagnostic process of the device's signature verification. In some embodiments, the firewall can decrypt the signature data using a public key certificate to obtain decrypted data; concatenate the authentication identifier and preset data and perform a hash operation to obtain the hash result; if the decrypted data and the hash result are the same, the signature verification is deemed successful.

[0064] Taking the above signature process as an example, during signature verification, the signature data can be decrypted using a public key certificate and the RSA2048 algorithm to obtain decrypted data. The authentication identifier and preset data are then concatenated, and the SHA256 algorithm is used to perform a hash operation to obtain the hash operation result. If the decrypted data and the hash operation result are the same, the signature verification is considered successful; otherwise, the signature verification is considered unsuccessful.

[0065] The verification process can be represented by the following formula:

[0066] Verification result = RSA2048_Decrypt(signature data) = SHA256(CONCAT(authentication identifier, preset data)).

[0067] In step 104, if the verification is successful, the diagnostic device is deemed to have passed identity authentication.

[0068] Understandably, if the signature verification is successful, it means that the diagnostic device has proven its ownership of the public key certificate, and the diagnostic device's identity authentication is successful; if the signature verification fails, it means that the ownership proof has failed, at which point the firewall stops the identity authentication process and returns a negative response to the diagnostic device.

[0069] In some embodiments, after determining that the diagnostic device has passed authentication, the firewall can also exit the diagnostic protection state; receive diagnostic messages sent by the diagnostic device and the controller to be diagnosed, and forward the diagnostic messages.

[0070] Understandably, after the firewall exits diagnostic protection mode, it allows the vehicle to be diagnosed by diagnostic equipment. After the diagnostic equipment sends a diagnostic message, the firewall can receive the message and forward it directly to the controller inside the vehicle that needs to be diagnosed. Alternatively, the firewall can receive diagnostic messages from the controller and forward them to the diagnostic equipment.

[0071] In some embodiments, the firewall may also re-enter the diagnostic protection state if it does not receive a diagnostic message within a preset time period.

[0072] The preset duration can be set according to the actual situation, such as 10 minutes, 15 minutes, etc.

[0073] Understandably, if the firewall does not receive a diagnostic message within a preset time, it will determine that the authentication has failed and re-enter the diagnostic protection state to re-authenticate the diagnostic device. This can prevent the diagnostic device from being replaced by an unauthorized device after successful authentication and attacking the controller to be diagnosed in the vehicle, thus improving the security of the controller to be diagnosed in the vehicle.

[0074] Figure 2 A schematic diagram illustrating the interaction flow between a firewall and a diagnostic device in one embodiment is shown. Figure 2 As shown, the interaction process between the firewall and the diagnostic device includes the following steps:

[0075] Step 201: The diagnostic device sends a diagnostic request to the firewall;

[0076] Step 202: When the firewall is in diagnostic protection mode, it receives a diagnostic request and determines whether the diagnostic request is an authentication request based on the diagnostic service corresponding to the diagnostic request.

[0077] Step 203: If the firewall determines that the diagnostic request is an authentication request, it receives the public key certificate sent by the diagnostic device and verifies the validity of the public key certificate. If the verification is successful, it sends an authentication identifier to the diagnostic device.

[0078] Step 204: The diagnostic device concatenates the authentication identifier and mask into strings, then signs them using the private key to generate signature data, and sends the signature data to the firewall.

[0079] Step 205: Upon receiving the signed data, the firewall verifies the signature data based on the authentication identifier, mask, and public key certificate.

[0080] Step 206: If the signature verification is successful, the firewall determines that the diagnostic device's identity authentication is successful, returns a successful identity authentication result to the diagnostic device, and exits the diagnostic protection state.

[0081] Step 207: The diagnostic device sends a diagnostic request to the firewall again;

[0082] Step 208: The firewall forwards the diagnostic request to the controller to be diagnosed in the vehicle and returns the diagnostic response of the controller to be diagnosed to the diagnostic device.

[0083] Step 209: If the firewall does not receive a diagnostic message (including diagnostic request or diagnostic response) within 10 minutes, it will re-enter the diagnostic protection state.

[0084] The aforementioned solution verifies the public key certificate upon receiving an authentication request and public key certificate from the diagnostic device via a firewall. If verification is successful, an authentication identifier is sent to the diagnostic device, enabling it to generate signature data based on the authentication identifier and preset data. Upon receiving the signature data from the diagnostic device, the signature data is verified against the authentication identifier, preset data, and public key certificate. If verification is successful, the diagnostic device's authentication is deemed successful. The technical solution provided in this application enables two-factor authentication of the diagnostic device using both digital certificates and preset data, ensuring that only authenticated diagnostic devices can access the OBD interface, thus guaranteeing the security of vehicle data.

[0085] The following describes an embodiment of the apparatus described in this application, which can be used to execute the authentication method for the diagnostic device described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the authentication method for the diagnostic device described in the above embodiments of this application.

[0086] Figure 3 A block diagram of an authentication device for a diagnostic device is shown in one embodiment. Figure 3As shown, the identity authentication device for a diagnostic device according to an embodiment of this application may include: a certificate verification module 301, a signature module 302, a signature verification module 303, and an identity determination module 304. The certificate verification module 301 verifies the public key certificate upon receiving an identity authentication request and a public key certificate from the diagnostic device. The signature module 302 sends an authentication identifier to the diagnostic device upon successful verification, enabling the diagnostic device to generate signature data based on the authentication identifier and preset data. The signature verification module 303 verifies the signature data based on the authentication identifier, preset data, and the public key certificate upon receiving the signature data from the diagnostic device. The identity determination module 304 determines that the diagnostic device's identity authentication is successful upon successful signature verification.

[0087] In some embodiments, the signature verification module 303 is further configured to decrypt the signature data using a public key certificate to obtain decrypted data; concatenate the authentication identifier and preset data and perform a hash operation to obtain a hash operation result; and determine that the signature verification is successful if the decrypted data and the hash operation result are the same.

[0088] In some embodiments, the certificate verification module 301 is further configured to verify the legality of the public key certificate according to a preset root certificate chain.

[0089] In some embodiments, the certificate verification module 301 is further configured to receive a diagnostic request sent by a diagnostic device when the firewall is in a diagnostic protection state; and determine whether the diagnostic request is an authentication request based on the diagnostic service corresponding to the diagnostic request.

[0090] In some embodiments, the authentication device of the diagnostic device may further include a message forwarding module (not shown) for exiting the diagnostic protection state; receiving diagnostic messages sent by the diagnostic device and the controller to be diagnosed; and forwarding the diagnostic messages.

[0091] In some embodiments, the message forwarding module is also configured to re-enter the diagnostic protection state if no diagnostic message is received within a preset time period.

[0092] Based on the same inventive concept, this application also provides a vehicle, see reference. Figure 4 The diagram shows a structural schematic of a vehicle according to an embodiment of this application. The vehicle includes one or more memories 404, one or more processors 402, and at least one computer program (computer program instructions) stored in the memory 404 and executable on the processor 402. When the processor 402 executes the computer program, it implements the method described above.

[0093] Among them, Figure 4In this document, a bus architecture (represented by bus 400) is used. Bus 400 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 402 and memory represented by memory 404. Bus 400 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 405 provides an interface between bus 400 and receiver 401 and transmitter 403. Receiver 401 and transmitter 403 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 402 is responsible for managing bus 400 and general processing, while memory 404 can be used to store data used by processor 402 during operation.

[0094] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the method described above.

[0095] Based on the same inventive concept, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0096] Based on the same inventive concept, this application provides an identity authentication system for a diagnostic device, including the aforementioned vehicle and the diagnostic device. The diagnostic device communicates with the vehicle through an OBD interface, and the firewall of the OBD interface and the diagnostic device are configured with the same preset data.

[0097] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0099] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0100] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0101] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A diagnostic device authentication method, applied to vehicles, characterized in that, The vehicle's on-board diagnostic system (OBD) interface is equipped with a firewall. The firewall and the diagnostic device are configured with the same preset data, which is a mask. The authentication method includes: Upon receiving an authentication request and public key certificate from the diagnostic device, the firewall verifies the public key certificate. If the verification is successful, an authentication identifier is sent to the diagnostic device, so that the diagnostic device concatenates the authentication identifier and the preset data and performs a hash operation. After obtaining the hash operation result, the hash operation result is encrypted using a private key to obtain the signature data; wherein, the authentication identifier is a random number; Upon receiving the signature data sent by the diagnostic device, the signature data is verified based on the authentication identifier, the preset data, and the public key certificate; If the signature verification is successful, the diagnostic device is deemed to have passed identity authentication. The step of verifying the signature data based on the authentication identifier, the preset data, and the public key certificate includes: The signature data is decrypted using the public key certificate to obtain decrypted data; The authentication identifier and the preset data are concatenated and then hashed to obtain the hash result. If the decrypted data is the same as the hash operation result, the signature verification is considered successful.

2. The method for authenticating the identity of a diagnostic device according to claim 1, characterized in that, The verification of the public key certificate includes: The validity of the public key certificate is verified according to the preset root certificate chain.

3. The method for authenticating the identity of a diagnostic device according to claim 1, characterized in that, Before the firewall verifies the public key certificate upon receiving an authentication request and public key certificate from the diagnostic device, the authentication method further includes: When the firewall is in diagnostic protection mode, it receives diagnostic requests sent by the diagnostic device. Based on the diagnostic service corresponding to the diagnostic request, determine whether the diagnostic request is the identity authentication request.

4. The method for authenticating the identity of a diagnostic device according to claim 3, characterized in that, After determining that the diagnostic device has passed authentication, the authentication method further includes: Exit the diagnostic protection state; Receive diagnostic messages sent by the diagnostic device and the controller to be diagnosed, and forward the diagnostic messages.

5. The method for authenticating the identity of a diagnostic device according to claim 4, characterized in that, After exiting the diagnostic protection state, the authentication method further includes: If the diagnostic message is not received within a preset time period, the system will re-enter the diagnostic protection state.

6. An authentication device for a diagnostic device, applied to a vehicle, characterized in that, The vehicle's on-board diagnostic system (OBD) interface is equipped with a firewall. The firewall and the diagnostic equipment are configured with the same preset data, which is a mask. The authentication device includes: The certificate verification module is used to verify the public key certificate upon receiving an authentication request and a public key certificate from the diagnostic device. The signature module is used to send an authentication identifier to the diagnostic device when the verification is successful, so that the diagnostic device concatenates the authentication identifier and the preset data and performs a hash operation. After obtaining the hash operation result, the device encrypts the hash operation result using a private key to obtain the signature data; wherein, the authentication identifier is a random number. The signature verification module is used to verify the signature data based on the authentication identifier, the preset data, and the public key certificate when the signature data is received from the diagnostic device. The identity verification module is used to determine that the identity authentication of the diagnostic device is successful if the signature verification is successful. The step of verifying the signature data based on the authentication identifier, the preset data, and the public key certificate includes: The signature data is decrypted using the public key certificate to obtain decrypted data; The authentication identifier and the preset data are concatenated and then hashed to obtain the hash result. If the decrypted data is the same as the hash operation result, the signature verification is considered successful.

7. A vehicle comprising a processor and a memory, characterized in that, The memory stores computer program instructions that can be executed by the processor, and when the processor executes the computer program instructions, it implements the steps of the method as described in any one of claims 1 to 5.

8. An authentication system for a diagnostic device, characterized in that, The vehicle and diagnostic device according to claim 7 are included, wherein the diagnostic device communicates with the vehicle via an OBD interface, and the firewall of the OBD interface is configured with the same preset data as the diagnostic device.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 5.

Images