Identity authentication method, device, equipment and system for accessing vehicle-mounted diagnostic interface

Abstract

The invention discloses an identity authentication method, device, equipment and system for accessing a vehicle-mounted diagnostic interface, and relates to the technical field of vehicle network security, and the identity authentication method for accessing the vehicle-mounted diagnostic interface comprises the steps: obtaining a whole vehicle authentication state; when the whole vehicle authentication state is that authentication needs to be carried out, certificate information sent by diagnosis equipment is obtained; verifying the legality of the certificate information to obtain a verification result, and sending the verification result and an initial random number to the diagnostic device; receiving a signature random number sent by the diagnosis equipment; and authenticating the signature random number to obtain an authentication result, and sending the authentication result to the diagnostic device. The communication information security of the diagnosis service can be improved under the condition that the security algorithm of the whole vehicle ECU is not changed, and meanwhile efficient and accurate execution of the diagnosis operation is ensured.

Description

Technical Field

[0001] The present application relates to the field of vehicle network security technology, and in particular to an identity authentication method, device, equipment and system for accessing an on-board diagnostic interface. Background Art

[0002] With the development of intelligent automotive electronics, the requirements for vehicle information security are increasing. In this context, diagnostic equipment needs to use security algorithms to unlock the controller in order to perform more demanding diagnostic services, such as 2E write services and 31 routine services. The diagnostic communications of these services need to ensure security to prevent unauthorized access and potential information leakage.

[0003] At present, diagnostic equipment uses diagnostic security access service (27 diagnostic service) to unlock the controller. The specific steps include: the diagnostic instrument (Tester) sends 27 01 to request security access, the electronic control unit (Electronic Control Unit, ECU) replies with a random seed (Seed1...Seedn), the Tester calculates the key according to the built-in algorithm and sends 2702Key1...Keyn, the ECU compares the key sent by the Tester with the key calculated by itself, and if they are consistent, it replies with a positive response, and the security access is successfully unlocked. However, this solution has some problems. The security access algorithm of the security access service of the vehicle controller is a custom algorithm for each OEM, with low information security and confidentiality, and does not meet the regulatory information security requirements.

[0004] In existing practices, the security algorithm of the vehicle's ECU needs to be changed to improve security, which involves the rectification of all controllers and R&D equipment (including diagnostic test tools, production line equipment, after-sales diagnostic instruments, and OTA host computers) of the vehicle. The scope of change is large, the cost is high, and the cycle is long. In addition, some controller chips do not support algorithm upgrades, making it difficult to change the entire vehicle. The security algorithm upgrade of the controller's BOOT software may result in the inability to upgrade the new application software to the old BOOT software, which may easily lead to problems such as batch replacement of samples of vehicles on sale after OTA refresh fails. Therefore, how to improve the security of communication information of diagnostic services without changing the security algorithm of the vehicle's ECU has become an urgent problem to be solved.

[0005] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0006] The purpose of this application is to provide an identity authentication method, device, equipment and system for accessing an on-board diagnostic interface, aiming to solve the technical problem of how to improve the security of communication information of diagnostic services without changing the security algorithm of the vehicle ECU.

[0007] To achieve the above purpose, the present application proposes an identity authentication method for accessing an on-board diagnostic interface, the method being applied to a gateway controller of a vehicle, the method comprising:

[0008] The method is applied to a gateway controller of a vehicle, and the method comprises:

[0009] Get the vehicle certification status;

[0010] When the vehicle certification status is that certification is required, obtaining certificate information sent by the diagnostic device;

[0011] Verifying the legitimacy of the certificate information to obtain a verification result, and sending the verification result and an initial random number to the diagnostic device;

[0012] Receiving a signed random number sent by the diagnostic device;

[0013] The signature random number is authenticated to obtain an authentication result, and the authentication result is sent to the diagnostic device.

[0014] In one embodiment, the step of verifying the legitimacy of the certificate information, obtaining a verification result, and sending the verification result and an initial random number to the diagnostic device includes:

[0015] Performing a format check on the certificate information according to a preset format standard to obtain a format check result;

[0016] Verify the issuance chain of the certificate information according to the trusted root certificate authority information to obtain the issuance chain verification result;

[0017] When the format check result and the issuance chain verification result are both correct, the verification result is obtained as verification passed, and the verification result and the initial random number are sent to the diagnostic device;

[0018] When the format check result or the issuance chain verification result is incorrect, the verification result is obtained as verification failure, and the verification result and the initial random number are sent to the diagnostic device.

[0019] In one embodiment, the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device includes:

[0020] Extracting the public key from the certificate information;

[0021] Decrypt the signature random number using the public key to obtain a decrypted target random number;

[0022] Compare the initial random number with the target random number to obtain a comparison result;

[0023] When the comparison result is completely consistent, the authentication result is obtained as successful authentication, and the authentication result is sent to the diagnostic device;

[0024] When the comparison result is inconsistent, the authentication result is obtained as authentication failure, and the authentication result is sent to the diagnostic device.

[0025] In one embodiment, after the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, the step further includes:

[0026] When the authentication result is successful, configuring the controller area network channel and the Ethernet channel to enable the routing function;

[0027] When the vehicle authentication status is that authentication is not required or has been authenticated, a diagnostic message sent by a diagnostic device is received, and the diagnostic message is forwarded through the controller area network and the Ethernet.

[0028] In one embodiment, after the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, the step further includes:

[0029] When the authentication result is successful, switching the vehicle authentication state to authenticated;

[0030] When a software reset instruction or a sleep instruction is received, the diagnostic message forwarding function of the controller local area network and the Ethernet is turned off, and the vehicle authentication state is switched to authentication required.

[0031] In addition, to achieve the above purpose, the present application also proposes an identity authentication method for accessing an on-board diagnostic interface, the method being applied to a diagnostic device, the method comprising:

[0032] Get the vehicle certification status;

[0033] When the vehicle authentication status is that authentication is required, sending certificate information to the gateway controller of the vehicle;

[0034] Receiving the initial random number sent by the gateway controller and the verification result of the legitimacy of the certificate information;

[0035] Sign the initial random number using a private key to obtain a signed random number;

[0036] The signature random number is sent to the gateway controller, and an authentication result of the signature random number fed back by the gateway controller is received.

[0037] In one embodiment, after the step of sending the signature random number to the gateway controller and receiving the authentication result of the signature random number fed back by the gateway controller, the method further includes:

[0038] When the authentication result is successful, a diagnostic message is sent to the gateway controller to perform vehicle diagnosis.

[0039] In addition, to achieve the above purpose, the present application also proposes an identity authentication device connected to the on-board diagnostic interface, the device comprising:

[0040] Certification status acquisition module, used to obtain the vehicle certification status;

[0041] A certificate acquisition module, used for acquiring certificate information sent by the diagnostic device when the vehicle authentication status is that authentication is required;

[0042] A verification module, used to verify the legitimacy of the certificate information, obtain a verification result, and send the verification result and an initial random number to the diagnostic device;

[0043] A random number receiving module, used for receiving a signed random number sent by the diagnostic device;

[0044] The authentication module is used to authenticate the signature random number, obtain an authentication result, and send the authentication result to the diagnostic device.

[0045] In addition, to achieve the above-mentioned purpose, the present application also proposes an identity authentication device for accessing an on-board diagnostic interface, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the identity authentication method for accessing an on-board diagnostic interface as described above.

[0046] In addition, to achieve the above objectives, the present application also proposes an identity authentication system for accessing an on-board diagnostic interface, the system comprising the gateway controller as described above and / or the diagnostic device as described above.

[0047] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the identity authentication method for accessing the on-board diagnostic interface as described above are implemented.

[0048] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the identity authentication method for accessing the on-board diagnostic interface as described above are implemented.

[0049] One or more technical solutions proposed in this application have at least the following technical effects:

[0050] Obtain the vehicle authentication status; when the vehicle authentication status is that authentication is required, obtain the certificate information sent by the diagnostic device; verify the legitimacy of the certificate information, obtain the verification result, and send the verification result and the initial random number to the diagnostic device; receive the signature random number sent by the diagnostic device; authenticate the signature random number, obtain the authentication result, and send the authentication result to the diagnostic device. The gateway controller first obtains the vehicle authentication status to determine whether the diagnostic device needs to be authenticated. This step helps maintain vehicle network security and ensure that only authorized devices can access. If the status shows that authentication is required, the gateway controller will request the diagnostic device to provide its certificate information to verify its identity and ensure the legitimacy of network access. Then, the gateway controller verifies the legitimacy of the received certificate information and sends the verification result together with the initial random number to the diagnostic device. This operation not only confirms the validity of the device's certificate, but also enhances the security of the authentication process through random numbers to prevent replay attacks. Subsequently, the gateway controller receives the random number signed by the diagnostic device using a private key. This step allows the gateway controller to verify whether the diagnostic device actually owns the corresponding private key, further ensuring the authenticity of the device's identity. Finally, the gateway controller authenticates the signature random number and sends the authentication result to the diagnostic device to complete the identity authentication process, so that only legitimate devices can perform subsequent diagnostic communications. This entire process improves security, ensures compliance, and improves the efficiency of the diagnostic process. Through this series of steps, the gateway controller system can improve the communication information security of the diagnostic service without changing the security algorithm of the vehicle ECU, while ensuring the efficient and accurate execution of diagnostic operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0052] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0053] Figure 1 A flowchart of the first embodiment of the identity authentication method for accessing the on-board diagnostic interface of the present application;

[0054] Figure 2A schematic diagram of a vehicle authentication state management machine provided in Example 1 of the identity authentication method for accessing an on-board diagnostic interface of this application;

[0055] Figure 3 A schematic diagram of the diagnostic device identity authentication principle provided in Example 1 of the identity authentication method for accessing the on-board diagnostic interface of this application;

[0056] Figure 4 A flowchart diagram of the second embodiment of the identity authentication method for accessing the on-board diagnostic interface of this application;

[0057] Figure 5 A schematic diagram of a simplified process of an identity authentication method for accessing an on-board diagnostic interface provided in Embodiment 2 of the present application;

[0058] Figure 6 This is a schematic diagram of the module structure of the identity authentication device connected to the on-board diagnostic interface in an embodiment of the present application;

[0059] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the identity authentication method for accessing the on-board diagnostic interface in the embodiment of the present application.

[0060] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0061] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0062] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0063] With the development of intelligent automotive electronics, vehicle information security has become crucial. In order to meet higher security standards, diagnostic equipment needs to unlock the controller through a security algorithm to perform advanced diagnostic operations such as 2E write services and 31 routine services to ensure the security of diagnostic communications and prevent unauthorized access and information leakage. Currently, diagnostic equipment uses 27 diagnostic services (security access services) to unlock the controller, which involves the process of sending requests, receiving random seeds, and calculating and verifying keys. However, due to the low confidentiality of the security access algorithms customized by each OEM and failure to meet regulatory requirements, the existing solutions have security risks. Improving ECU security algorithms faces the problems of wide rectification scope, high cost, and long cycle, and some controller chips do not support upgrades, which may lead to OTA refresh failures and other problems, increasing the complexity and difficulty of vehicle changes.

[0064] The main solution of the embodiment of the present application is: the gateway controller first checks the vehicle authentication status to determine whether the diagnostic equipment needs to be authenticated in order to maintain vehicle network security and ensure that only authorized devices are accessed. If authentication is required, the gateway requests the diagnostic equipment to provide certificate information, verifies its legitimacy, and sends an initial random number to enhance security. Next, the gateway receives and verifies the random number signed by the diagnostic equipment with a private key to confirm the authenticity of the device identity. Finally, the gateway feeds back the authentication result to the diagnostic equipment, completing the entire identity authentication process to ensure the security and compliance of subsequent diagnostic communications. This process effectively prevents unauthorized access and replay attacks, and improves diagnostic efficiency.

[0065] It should be noted that the execution subject of the embodiment of the present application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a gateway controller, a gateway controller system, etc. The following takes the gateway controller system as an example to illustrate this embodiment and the following embodiments.

[0066] Based on this, the embodiment of the present application provides an identity authentication method for accessing the on-board diagnostic interface, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the identity authentication method for accessing the on-board diagnostic interface of the present application.

[0067] In this embodiment, the method is applied to a gateway controller of a vehicle, and the identity authentication method for accessing an on-board diagnostic interface includes steps S10 to S50:

[0068] Step S10, obtaining the vehicle certification status;

[0069] It should be noted that the vehicle authentication state refers to the state of the vehicle's central gateway (Gateway) during the security authentication process. This state determines whether the vehicle's on-board diagnostics (OBD) interface allows external diagnostic devices to communicate and perform diagnostic operations. The vehicle authentication state mainly involves the following aspects: (1) Unauthenticated State: In this state, the vehicle's central gateway does not allow external diagnostic devices to perform most diagnostic communications through the OBD interface. Only specific diagnostic services (such as OBD emission services 0x00~0x0F) may be allowed. External diagnostic devices need to go through a series of identity authentication processes before they can change from "unauthenticated state" to "authenticated state". (2) Authenticated State: Once the external diagnostic device successfully passes the identity authentication process, the central gateway will switch to the "authenticated state". In this state, the central gateway will enable the CAN (Controller Area Network) and Ethernet message forwarding functions of the OBD port, allowing external diagnostic equipment to communicate and diagnose with the vehicle's ECU (Electronic Control Unit). In the authenticated state, the diagnostic equipment can diagnose the vehicle's ECU normally and initiate diagnostic commands, and the vehicle's ECU will respond to the diagnostic request from the diagnostic equipment connected to the OBD port according to the diagnostic specification. (3) Session Maintenance: In the "authenticated state", as long as the authentication session is valid, the central gateway will maintain this state and enable communication on both the CAN and Ethernet channels. If the authentication session fails for some reason (such as gateway sleep wake-up, reset, etc.), the central gateway will automatically switch back to the "unauthenticated state" and disable the corresponding message forwarding function. (4) Session Invalidation: When the central gateway loses state information due to initialization operations (such as reset, refresh, etc.), the authentication state will become invalid, and the external diagnostic equipment needs to re-perform the authentication process. The management of vehicle certification status is crucial to the information security of the vehicle, because it ensures that only authorized diagnostic equipment can access the vehicle's control system, thereby preventing unauthorized access and potential malicious operations. Through this mechanism, the vehicle's ECU can be protected from illegal modification, ensuring the normal operation and driving safety of the vehicle.

[0070] Please refer to Figure 2 , Figure 2A schematic diagram of a vehicle authentication state manager is provided for the first embodiment of the identity authentication method for accessing the on-board diagnostic interface of this application. The diagram shows the workflow of the vehicle authentication state manager, which includes three main states: no authentication required, authentication required and authenticated, and authentication required but not authenticated. In the state where authentication is not required, the vehicle's gateway allows the diagnostic device to communicate directly with the vehicle's ECU without identity authentication. When the vehicle is in the state where authentication is required and authenticated, the diagnostic device has passed the identity authentication, and the gateway keeps the diagnostic message forwarding function turned on, allowing the diagnostic device to communicate with the ECU. If the diagnostic device fails to pass the identity authentication, the vehicle will be in the state where authentication is required but not authenticated. At this time, the gateway will turn off the diagnostic message forwarding function to prevent unauthorized access. In addition, the figure also shows the triggering conditions of state transitions. For example, at the store-side PDI (Pre-Delivery Inspection) inspection station, the vehicle gateway will switch to a mode that requires authentication; only when the diagnostic device identity authentication is successful will the gateway switch to the authenticated state; if the gateway software is initialized, such as reset or wake-up after sleep, the identity authentication fails, the gateway will turn off the diagnostic message forwarding function and require re-authentication; for problem troubleshooting of sold vehicles, R&D testers can switch the gateway to a vehicle mode that does not require authentication, and then restore it to a user mode that requires authentication after the test is completed. This state manager ensures the security of vehicle information and facilitates legal diagnostic operations.

[0071] It is understood that first, the vehicle's gateway controller checks the authentication status information stored internally. This step is completed by reading a specific memory area in the gateway controller used to record the authentication status. This is done to determine whether a valid authentication session exists.

[0072] Step S20, when the vehicle authentication status is that authentication is required, obtaining the certificate information sent by the diagnostic device;

[0073] It should be noted that Need Authentication means that the vehicle's gateway controller requires external diagnostic devices to pass a series of identity authentication processes before further diagnostic communication and operation can be carried out. In this state, the gateway controller will not allow any unauthenticated diagnostic device to access the vehicle's controller area network (CAN) or ECU on Ethernet. The purpose of setting this state is to ensure that all external devices connected to the vehicle system are authorized, thereby protecting the vehicle's network security and data security. Diagnostic Device refers to a device used to connect to the vehicle's OBD interface. It can be a professional diagnostic tool or a portable diagnostic instrument used to read vehicle fault codes, perform system tests, reset system settings, etc. These devices usually have the ability to communicate with the vehicle's ECU and can send and receive specific diagnostic commands and data. After connecting to the vehicle, the diagnostic device needs to pass the vehicle's security authentication mechanism to prove its legitimacy and safety. Certificate Information refers to a digital certificate issued by an authoritative certificate authority (CA), which contains the public key, identity information, and validity period of the diagnostic device. The role of the digital certificate is to ensure the legitimacy and security of the diagnostic device. It is similar to a digital ID card, which enables the vehicle gateway to verify the authenticity of the connected device. During the identity authentication process, the diagnostic device will send its digital certificate to the vehicle gateway controller, and the gateway controller will use the preset root certificate chain to verify the validity and legitimacy of the certificate. Verification of certificate information is an important step to ensure the security of the vehicle system. Only diagnostic devices that pass the verification can obtain further access to the vehicle control system.

[0074] It is understandable that when the vehicle authentication status is that authentication is required, the vehicle's gateway controller will require the connected diagnostic device to provide the key credentials for its authentication, namely the digital certificate information. The specific steps are: First, the diagnostic device will send its stored digital certificate to the gateway controller through a secure communication channel; this digital certificate contains the diagnostic device's public key, identity information, and key data such as the validity period of the certificate issued by a trusted certificate authority. After receiving the certificate information, the gateway controller will use its internal preset root certificate chain to verify the certificate submitted by the diagnostic device, check the validity of the certificate, the credibility of the issuer, and whether the certificate has been tampered with. This verification process ensures that only legitimate and authenticated diagnostic devices can continue with subsequent vehicle diagnostics and communication operations, thereby maintaining the security of the vehicle network and the integrity of the data.

[0075] Step S30, verifying the legitimacy of the certificate information to obtain a verification result, and sending the verification result and the initial random number to the diagnostic device;

[0076] It should be noted that legitimacy refers to whether the certificate information provided by the diagnostic device meets the predetermined security standards and requirements, including whether the certificate is issued by a trusted certificate authority, whether the certificate is within the validity period, whether the certificate has been tampered with or forged, etc. Legitimacy verification is a key step in network security to ensure that the connected device is authorized and its identity is credible. The verification result refers to the conclusion obtained by the gateway controller after the legitimacy verification of the certificate information provided by the diagnostic device. This result indicates whether the certificate has passed all verification checks. If the certificate passes all verifications, the verification result will indicate that the certificate is valid; if the certificate fails to pass the verification, the verification result will indicate that the certificate is invalid and may include the reason for the failure, such as certificate expiration, signature mismatch, etc. The initial random number is a random value generated by the gateway controller during the identity authentication process to enhance security and ensure the uniqueness of each authentication process. This random number is usually used in subsequent encryption response processes. For example, the gateway controller may require the diagnostic device to use this random number and a preset mask to perform some encryption operation to further prove that it has a private key that matches the certificate. The use of the initial random number increases the security of the authentication process because the random number in each authentication process is different, which prevents replay attacks and some other security threats.

[0077] It can be understood that, first, the gateway controller will use the preset root certificate to verify the certificate sent by the diagnostic device. The specific operation is to confirm its authenticity by comparing the signature of the root certificate with the signature of the diagnostic device certificate. This is done to ensure that the certificate of the diagnostic device is issued by a trusted certificate authority, has not been tampered with, and is within the validity period. Secondly, the gateway controller will generate a verification result, which is based on various checks on certificate verification, including the validity of the certificate chain and the revocation status of the certificate. This step is to determine whether the identity of the diagnostic device is legal, thereby ensuring the security of the vehicle system. Then, for further security verification, the gateway controller will generate an initial random number, which will be used in the subsequent encryption response process to enhance the security of the authentication process and prevent replay attacks. Finally, the gateway controller sends this verification result and the initial random number to the diagnostic device. The diagnostic device determines whether re-authentication is required based on the verification result, and uses this random number to generate a response to prove that it has the corresponding private key. The effect of this step is to ensure that only legitimate diagnostic devices with the correct private key can pass the authentication and access the vehicle's control system.

[0078] Step S40, receiving a signed random number sent by the diagnostic device;

[0079] It should be noted that the signed random number refers to the data generated after the diagnostic device uses its private key to encrypt the initial random number previously sent by the gateway controller. This signed random number is a key link in the identity authentication process, which is used to prove that the diagnostic device does have the private key corresponding to the public key certificate it provides. Specifically, the signed random number is generated as follows: the gateway controller sends an initial random number to the diagnostic device as a challenge in the identity authentication process. After receiving this random number, the diagnostic device will use its preset private key to sign the random number. This signing operation usually involves an encryption algorithm, such as RSA or SHA-256, etc., to ensure that only devices holding the correct private key can generate a valid signature. Then, the diagnostic device sends this signed data (i.e., the signed random number) back to the gateway controller.

[0080] It is understandable that in the vehicle's network security authentication process, after the gateway controller verifies the legitimacy of the diagnostic device's certificate and sends the initial random number, it will wait to receive the signed random number returned by the diagnostic device.

[0081] Step S50, authenticating the signature random number to obtain an authentication result, and sending the authentication result to the diagnostic device.

[0082] It should be noted that the authentication result refers to the conclusion obtained by the gateway controller after verifying the signed random number sent by the diagnostic device. Specifically, this authentication result shows the following aspects: (1) Verify the validity of the signature: The gateway controller uses the public key in the public key certificate of the diagnostic device to decrypt the signed random number to verify whether the signature matches the initial random number previously sent to the diagnostic device. (2) Confirm the ownership of the private key: If the signed random number can be successfully decrypted by the public key of the diagnostic device and is consistent with the initial random number, this indicates that the diagnostic device does have a private key that matches the public key. (3) Determine the authentication status: The authentication result will indicate whether the diagnostic device has passed the identity authentication. If the signature verification is successful, the authentication result will indicate that the authentication is successful; if the signature verification fails, the authentication result will indicate that the authentication failed.

[0083] It can be understood that, first, after the gateway controller receives the signed random number from the diagnostic device, it will use the public key in the previously verified public key certificate of the diagnostic device to decrypt the signed random number. This step is to combine the public key with the signed random number and use a specific decryption algorithm to verify the integrity and correctness of the signature. The purpose is to verify whether the diagnostic device actually has a private key that matches the submitted public key. Secondly, the gateway controller compares the decrypted data with the initial random number previously sent to the diagnostic device. If the two are consistent, it means that the private key of the diagnostic device is correct and the authentication process is safe. This comparison process is to ensure the accuracy of the authentication and the legitimacy of the diagnostic device. Finally, the gateway controller will generate an authentication result. If the signature verification is successful, the result indicates that the authentication is successful. If it fails, it indicates that the authentication fails, and the authentication result is sent to the diagnostic device. The effect of this is to provide a clear feedback to the diagnostic device, informing it whether it has obtained the permission to access the vehicle control system. If the authentication is successful, the diagnostic device can continue to diagnose the vehicle; if the authentication fails, the diagnostic device needs to re-authenticate. This process enhances the security of the vehicle system and ensures that only authorized devices can access the vehicle's sensitive information and control system.

[0084] As an example, the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device includes: extracting the public key in the certificate information; decrypting the signed random number by using the public key to obtain a decrypted target random number; comparing the initial random number with the target random number to obtain a comparison result; when the comparison result is completely consistent, the authentication result is successful authentication, and the authentication result is sent to the diagnostic device; when the comparison result is inconsistent, the authentication result is failed authentication, and the authentication result is sent to the diagnostic device.

[0085] The public key refers to the encryption key paired with the private key and is used to encrypt data or verify the signature. In a digital certificate, the public key is public and can be obtained by anyone to verify the data signed by the corresponding private key. Decryption refers to the process of converting encrypted data into the original readable format. Here, the gateway controller uses the public key to decrypt the signed random number returned by the diagnostic device to verify the integrity and authenticity of the signature. The target random number refers to the random number obtained by the gateway controller after decrypting the signed random number using the public key. This random number should be the same as the initial random number originally sent to the diagnostic device by the gateway controller. The comparison result is the result of the gateway controller comparing the decrypted target random number with the initial random number originally sent. This result shows whether the two random numbers are the same. Complete consistency means that after the target random number is compared with the initial random number, the two are exactly the same without any difference, which indicates that the signed random number is generated by the diagnostic device with the correct private key. Authentication success means that when the comparison result is completely consistent, the gateway controller confirms that the identity authentication process of the diagnostic device is successful, which means that the diagnostic device has the right to access the vehicle's control system. Inconsistency means that after the target random number is compared with the initial random number, the two are not the same. This may mean that the signature random number has been tampered with, or the diagnostic device does not have the correct private key. Authentication failure means that when the comparison result is inconsistent, the gateway controller confirms that the identity authentication process of the diagnostic device has failed, which means that the diagnostic device has not passed the identity authentication and cannot obtain access to the vehicle control system.

[0086] First, the gateway controller extracts the public key from the certificate information provided by the diagnostic device, which is a key step for subsequent signature verification; secondly, the gateway controller uses the extracted public key to perform a decryption operation on the signed random number returned by the diagnostic device. This process converts the signature data back to the original random number, that is, the target random number; then, the gateway controller compares the decrypted target random number with the initial random number previously sent to the diagnostic device to verify whether the two are exactly the same; if the comparison result shows that the two random numbers are exactly the same, it means that the signature verification of the diagnostic device has passed, and the gateway controller will obtain a successful authentication result and send this result to the diagnostic device, indicating that it has obtained access rights; if the comparison results are inconsistent, it means that the signature verification has failed, and the gateway controller will obtain a failed authentication result and send this result to the diagnostic device, indicating that it has not obtained access rights and needs to re-authenticate. This process ensures that only legitimate diagnostic devices that correctly hold private keys can pass identity authentication, thereby protecting the security of the vehicle system.

[0087] As an example, after the step of authenticating the signature random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, it also includes: when the authentication result is successful authentication, configuring the controller local area network channel and the Ethernet channel to turn on the routing function; when the vehicle authentication status is that authentication is not required or has been authenticated, receiving the diagnostic message sent by the diagnostic device, and forwarding the diagnostic message through the controller local area network and the Ethernet.

[0088] The controller area network channel (CAN) refers to the CAN bus channel inside the vehicle, which is a network protocol that allows communication between ECUs. In this embodiment, the controller area network channel refers to the CAN network path used for connection and communication inside the vehicle. The Ethernet channel refers to the Ethernet network path inside the vehicle, which allows data exchange between various control units of the vehicle through Ethernet. In modern cars, Ethernet is usually used to connect systems that require high-speed data transmission, such as infotainment systems, advanced driver assistance systems, etc. The routing function refers to the ability of the gateway controller to forward data packets in the CAN and Ethernet channels. In this embodiment, when the diagnostic device passes the authentication, the gateway controller configures the routing function to be turned on, allowing data packets entering from the OBD port to be forwarded to the corresponding ECU of the vehicle, and also allowing data packets from the ECU to be sent out through the OBD port. The state that does not require authentication means that in certain specific operating modes, such as display mode, transportation mode or test mode, the central gateway of the vehicle does not require external diagnostic devices to perform identity authentication to perform diagnostic communication. In these modes, the gateway allows the forwarding function of CAN and Ethernet messages of the OBD port by default. The authenticated state means that the external diagnostic device has successfully passed the identity authentication process and the gateway controller has confirmed its identity. In this state, the gateway controller will keep the routing function open to allow the diagnostic device to communicate with the vehicle's ECU. Diagnostic messages refer to the data packets exchanged between the diagnostic device and the vehicle ECU during the vehicle diagnosis process. These messages contain instructions and data for performing diagnostic tests, reading fault codes, clearing fault codes, or configuring ECU parameters.

[0089] First, when the gateway controller receives the signed random number sent by the diagnostic device and verifies it, and confirms that the authentication is successful, it will adjust the vehicle's network communication settings. The specific operation is to activate the routing function of the controller area network (CAN) channel and the Ethernet channel. This is to allow the data packets entering the vehicle network from the OBD interface to be correctly forwarded to the target ECU; secondly, once the routing function is turned on, the gateway controller will monitor and listen to the diagnostic messages from the diagnostic device. These messages contain various instructions and requests required to perform vehicle diagnosis; finally, the gateway controller forwards these diagnostic messages to the corresponding ECU of the vehicle through the already turned on CAN channel and Ethernet channel. After receiving the message, the ECU will perform corresponding operations based on the content of the message, such as returning diagnostic data or executing diagnostic commands. The effect of this is that the diagnostic device can effectively exchange and communicate data with various ECUs inside the vehicle, complete fault diagnosis, system configuration and other tasks, and ensure that the maintenance and diagnosis of the vehicle system can proceed smoothly.

[0090] As an example, after the step of authenticating the signature random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, it also includes: when the authentication result is successful, switching the whole vehicle authentication status to authenticated; when a software reset instruction or a sleep instruction is received, turning off the diagnostic message forwarding function of the controller local area network and Ethernet, and switching the whole vehicle authentication status to requiring authentication.

[0091] A software reset command is a command issued by the software layer to restart or reset the software state of the gateway controller or other ECUs. The specific operation may include clearing the current operating state, interrupting the current communication session, and returning the device to the initial startup state. This can solve software-level problems and restore the normal operation of the device. A sleep command is a command issued by the software to put the device into a low-power or inactive state, that is, sleep mode. In sleep mode, the power consumption of the device is reduced, but it can be awakened and restored to a fully functional state. The sleep command is used to save energy, especially when the vehicle is not running or in standby mode. The diagnostic message forwarding function refers to the function of the gateway controller to forward diagnostic messages received from the OBD interface to the corresponding ECU in the vehicle's internal network, and forward the response message of the ECU back to the OBD interface. This function is the core of vehicle diagnostic communication and allows external diagnostic devices to communicate with the ECU inside the vehicle. Authentication required refers to the state where the vehicle's gateway controller requires external diagnostic devices to pass the identity authentication process before diagnostic communication can be carried out. In this state, the gateway controller will not forward any diagnostic messages until the diagnostic device successfully passes the identity authentication, ensuring that only authorized devices can access the vehicle's control system.

[0092] First, when the gateway controller confirms that the signature random number authentication of the diagnostic device is successful, it will mark the vehicle authentication status as "authenticated" in the internal status register. This operation is completed by modifying the status flag in the memory. The purpose of this is to allow the diagnostic device to perform subsequent diagnostic communications at the software level. Second, when the gateway controller receives a software reset instruction or a sleep instruction, it will perform two operations: one is to stop the diagnostic message forwarding function of the controller area network (CAN) and Ethernet, which is achieved by sending a shutdown instruction to the relevant network interface, and the second is to re-mark the vehicle authentication status as "authentication required". This operation is also completed by modifying the status flag in the status register. This is to prevent unauthenticated devices from accessing the vehicle network when the device is restarted or enters sleep and then starts again, ensuring network security. Finally, the effect of these operations is that only authenticated diagnostic devices can communicate with the vehicle's ECU, and after a software reset or sleep, all devices must be re-authenticated, thereby maintaining the security and integrity of the vehicle network and preventing potential unauthorized access and network attacks.

[0093] As an example, the method is applied to a diagnostic device, and the method includes: obtaining the whole vehicle authentication status; when the whole vehicle authentication status is that authentication is required, sending certificate information to a gateway controller of the vehicle; receiving an initial random number sent by the gateway controller and a verification result of the legality of the certificate information; signing the initial random number using a private key to obtain a signed random number; sending the signed random number to the gateway controller, and receiving the authentication result of the signed random number fed back by the gateway controller.

[0094] The private key is a sensitive key assigned to the diagnostic device in the digital certificate and public key infrastructure, which is used to encrypt and sign the data to verify the identity of the device and ensure the integrity of the data. During the vehicle network security authentication process, the diagnostic device uses its private key to encrypt and sign the received random number, generate a signed random number, and then send it to the gateway controller for verification. This process not only proves that the diagnostic device has the corresponding private key, but also ensures that only legitimate devices with the correct private key can pass the identity authentication and access the vehicle's control system, thereby maintaining the security of the vehicle network and the confidentiality of the data.

[0095] As an example, after the step of sending the signature random number to the gateway controller and receiving the authentication result of the signature random number fed back by the gateway controller, it also includes: when the authentication result is successful, sending a diagnostic message to the gateway controller to perform vehicle diagnosis.

[0096] First, after confirming that the authentication result received from the gateway controller is successful, the diagnostic device will start preparing diagnostic messages. These messages contain specific diagnostic commands that the diagnostic device wants to execute, such as querying the vehicle's real-time data, reading fault codes, or requesting the ECU to perform certain operations. The diagnostic device will format these commands into electronic signals according to the preset communication protocol; then, the diagnostic device sends these diagnostic messages to the gateway controller through the established communication connection. This step is completed through the vehicle's CAN bus or Ethernet channel. The gateway controller acts as an intermediary to further forward these messages to the target ECU in the vehicle's internal network; finally, after receiving the diagnostic message, the target ECU will perform the corresponding diagnostic operation according to the message content, and encapsulate the operation results into a response message and return it to the gateway controller. The gateway controller then forwards these response messages back to the diagnostic device. The effect of this is that the diagnostic device can communicate with each ECU of the vehicle safely and accurately, realize a comprehensive diagnosis of the vehicle status, discover and deal with potential problems in a timely manner, and ensure the performance and safety of the vehicle.

[0097] Please refer to Figure 3 , Figure 3 A schematic diagram of the principle of diagnostic device authentication provided in Example 1 of the authentication method for accessing the on-board diagnostic interface of this application shows the principle of diagnostic device authentication, in which the diagnostic device first needs to pass the secure authentication service of the central gateway when trying to communicate with the OBD port of the vehicle. The authentication process begins with the diagnostic device sending an authentication request, which contains the public key certificate of the diagnostic device. The central gateway then verifies the legitimacy of the certificate, including format check and issuance chain verification. If the certificate is legitimate, the gateway generates a 32-byte random number and sends it to the diagnostic device, while requesting verification of the certificate ownership. The diagnostic device signs the random number using its private key and a preset 32-byte mask, generates a signed random number, and sends it back to the central gateway. The central gateway verifies the correctness of the signed random number. If the verification is successful, the gateway notifies the controller area network (CAN) / Ethernet (ETH) gateway control program to turn on the diagnostic message forwarding function, allowing the diagnostic device to communicate with the vehicle's ECU. If the verification fails, the gateway will keep the diagnostic message forwarding function closed and require the diagnostic device to re-authenticate. In addition, the figure also shows that during the authentication process, if a software reset command or a sleep command is received, the central gateway will turn off the diagnostic message forwarding function of the controller area network and Ethernet, and switch the vehicle authentication state to require authentication. The entire process ensures that only authorized diagnostic devices can access the vehicle's control system, thereby improving the security of the vehicle's OBD port information.

[0098] This embodiment provides an identity authentication method for accessing an on-board diagnostic interface, obtaining the whole vehicle authentication status; when the whole vehicle authentication status is that authentication is required, obtaining the certificate information sent by the diagnostic device; verifying the legitimacy of the certificate information, obtaining the verification result, and sending the verification result and the initial random number to the diagnostic device; receiving the signature random number sent by the diagnostic device; authenticating the signature random number, obtaining the authentication result, and sending the authentication result to the diagnostic device. The gateway controller first obtains the whole vehicle authentication status to determine whether the diagnostic device needs to be authenticated. This step helps maintain vehicle network security and ensure that only authorized devices can access. If the status shows that authentication is required, the gateway controller will request the diagnostic device to provide its certificate information to verify its identity and ensure the legitimacy of network access. Then, the gateway controller performs a legitimacy check on the received certificate information and sends the verification result together with the initial random number to the diagnostic device. This operation not only confirms the validity of the device's certificate, but also enhances the security of the authentication process through random numbers to prevent replay attacks. Subsequently, the gateway controller receives the random number signed by the diagnostic device using a private key. This step allows the gateway controller to verify whether the diagnostic device actually owns the corresponding private key, further ensuring the authenticity of the device's identity. Finally, the gateway controller authenticates the signature random number and sends the authentication result to the diagnostic device to complete the identity authentication process, so that only legitimate devices can perform subsequent diagnostic communications. This entire process improves security, ensures compliance, and improves the efficiency of the diagnostic process. Through this series of steps, the gateway controller system can improve the communication information security of the diagnostic service without changing the security algorithm of the vehicle ECU, while ensuring the efficient and accurate execution of diagnostic operations.

[0099] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 4 , Figure 4 This is a flow chart of the second embodiment of the identity authentication method for accessing the on-board diagnostic interface of the present application. Step S30 of the identity authentication method for accessing the on-board diagnostic interface includes steps S31 to S34:

[0100] Step S31, performing a format check on the certificate information according to a preset format standard to obtain a format check result;

[0101] It should be noted that the preset format standard refers to a set of predefined rules used to verify whether the digital certificate information meets specific structure and encoding requirements. These standards are usually formulated by the certificate authority (CA) or relevant standard organizations to ensure the format consistency and correctness of the digital certificate. For example, X.509 is a widely used digital certificate standard that defines the basic structure of the certificate, including fields such as certificate version, serial number, signature algorithm, issuer and subject information, validity period, extension, etc. The preset format standard specifies how these fields should be encoded and organized. The format check result refers to the conclusion drawn after the format check of the certificate information, indicating whether the certificate information meets the preset format standard. If the certificate information fully meets the preset format standard, the format check result will indicate "correct format" or "format verification passed". If the certificate information has a format error or does not meet the standard, the format check result will indicate "format error" or "format verification failed", and may provide specific error information, such as missing fields, encoding errors, etc.

[0102] It is understandable that during the digital certificate verification process, the certificate information provided by the diagnostic device will first be subject to a detailed format check based on the preset format standard, such as the X.509 standard. This includes verifying whether the various components of the certificate, such as the version number, serial number, validity period, issuer information, subject information, and extension fields, comply with the prescribed encoding rules and structure; this check is to ensure the integrity and correctness of the certificate information and prevent security issues caused by format errors. Then, the system will generate a format check result based on the check result. If the certificate information fully complies with the preset format standard, the result will show that the format verification passed, indicating that the certificate format is correct; if there are any deviations or errors in the format, the result will show that the format verification failed, and may indicate specific error details, such as missing fields or encoding errors, so as to ensure that only certificates with the correct format can be further processed and used. This process is an important part of ensuring the security and reliability of digital certificates.

[0103] Step S32, verifying the issuance chain of the certificate information according to the trusted root certificate authority information to obtain the issuance chain verification result;

[0104] It should be noted that the trusted root certificate authority information refers to the public key, name and other identity information of the root certificate authority (CA), which is used as the starting point for verifying the authenticity of other certificates. The root CA is the top level in the certificate hierarchy, and its certificate is considered to be self-signed and is pre-installed in the system or trusted in other ways. The information of the trusted root CA is the basis for verifying the validity of the certificate. The issuance chain refers to the path from a specific certificate (usually a user certificate or an intermediate CA certificate) back to the trusted root CA certificate. Each certificate in this chain is issued by the previous level certificate until it is traced back to the root CA certificate. The issuance chain proves the source and issuance path of the certificate, and is an important means to verify the authenticity of the certificate. The issuance chain verification result is the conclusion reached after verifying the issuance path of the certificate. This verification process includes checking the validity of each certificate, the certificate revocation status, the validity of the signature algorithm, the issuer and validity period of the certificate, etc. If all certificates in the issuance chain are valid and can be successfully traced back to the trusted root CA certificate, the issuance chain verification result will indicate "verification passed" or "chain valid". If there are any problems in the issuance chain, such as revoked certificates, signature mismatches or expiration, the issuance chain verification result will indicate "verification failed" or "chain invalid", and may provide the specific reasons for the verification failure.

[0105] It can be understood that, first, the system will start with the certificate provided by the diagnostic device, and use the trusted root certificate authority information, that is, the public key of the root CA, to verify the digital signature on the certificate. This step is to ensure that the certificate is issued by a trusted CA; then, the system will check the validity of the certificate, including confirming whether the certificate is within the validity period, whether it has been revoked, and whether the signature algorithm meets security standards. This can prevent expired or revoked certificates from being abused; finally, the system will trace the issuance path of the certificate, from the current certificate back to the previous level CA certificate until it reaches the root CA certificate, forming a complete issuance chain. If all certificates in this chain are verified correctly, the system will obtain the result that the issuance chain verification has passed, which means that the certificate is trustworthy and can be used to ensure the security of communications; if any certificate in the chain fails to verify, the system will obtain the result that the issuance chain verification has failed and point out the problem. The effect of this is to ensure that only certificates that have been strictly verified can be accepted, thereby maintaining the security and trust of the entire system.

[0106] Step S33, when the format check result and the issuance chain verification result are both correct, the verification result is obtained as verification passed, and the verification result and the initial random number are sent to the diagnostic device;

[0107] It should be noted that correct means that no errors or problems were found during the format check and issuance chain verification of the certificate information. Specifically: the format check result of "correct" means that the certificate information fully complies with the preset format standards, and all necessary fields are present and in the correct format. The issuance chain verification result of "correct" means that the issuance path of the certificate from the certificate back to the root certificate authority is complete and reliable, all intermediate certificates are valid, and no certificates have been revoked or expired. Verification passed means that after the format check and issuance chain verification are completed, the certificate information is confirmed to be valid and reliable, which means: the format of the certificate meets the requirements and there are no format errors; the issuance chain of the certificate is valid and can be traced back to a trusted root certificate authority; therefore, the certificate is considered legitimate and can be used for subsequent secure communication and identity authentication processes.

[0108] It is understandable that after the format check and issuance chain verification of the certificate information provided by the diagnostic device, if no problems are found in the two verification steps, that is, the format meets the preset standards, and the issuance chain is complete and credible, the system will obtain the verification result as "verification passed". This result means that the certificate information is valid and trustworthy. The system will then send this verification result and an initial random number to the diagnostic device. This is done to notify the diagnostic device that its certificate has been verified and to start the next authentication step, which is to require the diagnostic device to sign the initial random number with its private key, thereby proving that it owns the corresponding private key and further ensuring the identity of the diagnostic device, laying the foundation for subsequent secure communication.

[0109] Step S34, when the format check result or the issuance chain verification result is incorrect, the verification result is obtained as verification failure, and the verification result and the initial random number are sent to the diagnostic device.

[0110] It should be noted that an error means that an error or problem is found during the format check or issuance chain verification of the certificate information. Specifically: an "error" in the format check result means that the certificate information does not meet the preset format standards, and there may be missing fields, format errors or other problems; an "error" in the issuance chain verification result means that there is a problem in the process of tracing the certificate issuance path from the certificate back to the root certificate authority, such as an intermediate certificate is invalid, revoked, expired, or the path is incomplete. Failed verification means that after completing the format check and / or issuance chain verification, the certificate information is confirmed to be invalid or untrustworthy, which means: the format of the certificate does not meet the requirements and there are format errors; the certificate issuance chain is invalid and cannot be traced back to a trusted root certificate authority; therefore, the certificate is considered illegal or untrustworthy and cannot be used for subsequent secure communications and identity authentication processes.

[0111] It is understood that if any errors are found when checking the format or verifying the issuance chain of the certificate information provided by the diagnostic device, such as the certificate structure not meeting the standards or problems with the issuance path, the system will determine that the certificate verification result is "failed to pass the verification". This result means that the certificate has failed the necessary security verification and is therefore untrustworthy. Subsequently, the system will send this verification failure result and an initial random number to the diagnostic device to inform the diagnostic device that its certificate has failed to meet the security requirements and that it may need to take appropriate measures, such as re-obtaining or updating the certificate, in order to retry the authentication process. At the same time, sending the initial random number may be to allow the diagnostic device to use this random number to re-authenticate after correcting the problem, ensuring that the diagnostic device is given the opportunity to re-authenticate even in the event of an authentication failure. This step helps maintain the security of the vehicle network while providing the diagnostic device with clear feedback and guidance for subsequent actions.

[0112] This embodiment performs a format check on the certificate information according to a preset format standard to obtain a format check result; verifies the issuance chain of the certificate information according to the trusted root certificate authority information to obtain an issuance chain verification result; when the format check result and the issuance chain verification result are both correct, the verification result is obtained as verification passed, and the verification result and the initial random number are sent to the diagnostic device; when the format check result or the issuance chain verification result is incorrect, the verification result is obtained as verification failed, and the verification result and the initial random number are sent to the diagnostic device. First, the system performs a format check on the certificate information according to the preset format standard to ensure that the structure and encoding of the certificate meet the specified standards. This step helps to ensure the integrity and correctness of the certificate information and eliminates invalid certificates or security vulnerabilities caused by format errors. Next, the system uses the trusted root certificate authority information to verify the issuance chain of the certificate, traces back the complete path from the current certificate to the root CA certificate, and verifies the credibility of each level of issuance. This step enhances the security of the system and prevents the use of forged certificates. If the format check and the issuance chain verification are correct, the system will obtain the verification result as "verification passed", and send this result and the initial random number to the diagnostic device, confirming the validity and credibility of the certificate, allowing the diagnostic device to continue with subsequent secure communications and diagnostic operations. At the same time, the initial random number provides the necessary data for the next step of identity authentication, ensuring the continuity and reliability of secure communications. On the contrary, if any verification result is incorrect, the system will obtain the verification result as "verification failed", and send this result and the initial random number to the diagnostic device, promptly identifying and preventing possible security risks, protecting the vehicle network from unauthorized access, and providing the diagnostic device with an opportunity to re-authenticate, increasing the flexibility of the authentication process, ensuring that only legitimate diagnostic devices can communicate with the vehicle's ECU, and maintaining the security of the vehicle system and the integrity of the data.

[0113] For example, in order to help understand the implementation process of the identity authentication method for accessing the on-board diagnostic interface obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 5 , Figure 5 A brief flow chart of an identity authentication method for accessing an on-board diagnostic interface is provided, specifically:

[0114] The figure shows the process of OBD port security authentication, which starts with the diagnostic device accessing the OBD port and then sending an authentication request to the OBD access security authentication service of the central gateway. The central gateway verifies the legitimacy of the certificate, including format check and issuance chain verification. If correct, it generates a 32-byte random number and sends it to the diagnostic device, and requests to verify the certificate ownership. The diagnostic device signs the random number using the private key and mask, and sends the signed random number back to the central gateway. The gateway verifies the signed random number. If the verification is successful, it notifies the controller area network (CAN) / Ethernet (ETH) gateway control program to enable the diagnostic message forwarding function, allowing the diagnostic device to communicate with the vehicle ECU. If the verification fails, the diagnostic message forwarding function remains disabled and requires re-authentication. In addition, if a software reset or sleep command is received, the central gateway will disable the forwarding function and switch the authentication state to require authentication. The entire process ensures vehicle network security and prevents unauthorized access. At the same time, after successful authentication, the diagnostic device can send diagnostic messages for vehicle diagnosis. The central gateway decides whether to forward these messages to the ECU to be diagnosed based on the authentication state and the instructions of the control program.

[0115] The entire process ensures that only authorized diagnostic equipment can access the vehicle's control system, thereby improving the security of the vehicle's OBD port information.

[0116] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the identity authentication method of the present application for accessing the on-board diagnostic interface. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0117] This application also provides an identity authentication device connected to the vehicle diagnostic interface, please refer to Figure 6 The identity authentication device connected to the on-board diagnostic interface includes:

[0118] The certification status acquisition module 10 is used to obtain the certification status of the vehicle;

[0119] The certificate acquisition module 20 is used to acquire the certificate information sent by the diagnostic device when the vehicle authentication status is that authentication is required;

[0120] A verification module 30, used to verify the legitimacy of the certificate information, obtain a verification result, and send the verification result and an initial random number to the diagnostic device;

[0121] A random number receiving module 40, used to receive a signed random number sent by the diagnostic device;

[0122] The authentication module 50 is used to authenticate the signature random number, obtain an authentication result, and send the authentication result to the diagnostic device.

[0123] In one embodiment, the verification module 30 is further used to perform a format check on the certificate information according to a preset format standard to obtain a format check result; to verify the issuance chain of the certificate information according to the trusted root certificate authority information to obtain a issuance chain verification result; when the format check result and the issuance chain verification result are both correct, the verification result is obtained as verification passed, and the verification result and the initial random number are sent to the diagnostic device; when the format check result or the issuance chain verification result is incorrect, the verification result is obtained as verification failed, and the verification result and the initial random number are sent to the diagnostic device.

[0124] In one embodiment, the authentication module 50 is also used to extract the public key in the certificate information; decrypt the signature random number by using the public key to obtain a decrypted target random number; compare the initial random number with the target random number to obtain a comparison result; when the comparison result is completely consistent, the authentication result is a successful authentication, and the authentication result is sent to the diagnostic device; when the comparison result is inconsistent, the authentication result is a failed authentication, and the authentication result is sent to the diagnostic device.

[0125] In one embodiment, the authentication module 50 is also used to configure the controller local area network channel and the Ethernet channel to enable the routing function when the authentication result is successful authentication; when the vehicle authentication status is that authentication is not required or has been authenticated, receive the diagnostic message sent by the diagnostic device, and forward the diagnostic message through the controller local area network and the Ethernet.

[0126] In one embodiment, the authentication module 50 is also used to switch the vehicle authentication state to authenticated when the authentication result is successful; when a software reset instruction or a sleep instruction is received, the diagnostic message forwarding function of the controller local area network and Ethernet is turned off, and the vehicle authentication state is switched to requiring authentication.

[0127] The identity authentication device for accessing the on-board diagnostic interface provided by the present application adopts the identity authentication method for accessing the on-board diagnostic interface in the above-mentioned embodiment, which can solve the technical problem of how to improve the security of the communication information of the diagnostic service without changing the security algorithm of the whole vehicle ECU. Compared with the prior art, the beneficial effects of the identity authentication device for accessing the on-board diagnostic interface provided by the present application are the same as the beneficial effects of the identity authentication method for accessing the on-board diagnostic interface provided by the above-mentioned embodiment, and the other technical features of the identity authentication device for accessing the on-board diagnostic interface are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0128] The present application provides an identity authentication device for accessing an on-board diagnostic interface, and the identity authentication device for accessing the on-board diagnostic interface includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the identity authentication method for accessing the on-board diagnostic interface in the above-mentioned embodiment one.

[0129] Reference below Figure 7 , which shows a schematic diagram of the structure of an identity authentication device for accessing a vehicle-mounted diagnostic interface suitable for implementing an embodiment of the present application. The identity authentication device for accessing a vehicle-mounted diagnostic interface in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The identity authentication device connected to the on-board diagnostic interface shown is merely an example and should not bring any limitations to the functions and scope of use of the embodiments of the present application.

[0130] like Figure 7As shown, the identity authentication device connected to the on-board diagnostic interface may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the identity authentication device connected to the on-board diagnostic interface are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the identity authentication device connected to the on-board diagnostic interface to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an identity authentication device connected to the on-board diagnostic interface with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0131] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0132] The identity authentication device for accessing the on-board diagnostic interface provided by the present application adopts the identity authentication method for accessing the on-board diagnostic interface in the above embodiment, which can solve the technical problem of how to improve the security of the communication information of the diagnostic service without changing the security algorithm of the vehicle ECU. Compared with the prior art, the beneficial effects of the identity authentication device for accessing the on-board diagnostic interface provided by the present application are the same as the beneficial effects of the identity authentication method for accessing the on-board diagnostic interface provided by the above embodiment, and the other technical features of the identity authentication device for accessing the on-board diagnostic interface are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0133] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

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

[0135] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, the computer-readable program instructions being used to execute the identity authentication method for accessing an on-board diagnostic interface in the above-mentioned embodiment.

[0136] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0137] The computer-readable storage medium may be included in the identity authentication device connected to the on-board diagnostic interface; or may exist independently without being assembled into the identity authentication device connected to the on-board diagnostic interface.

[0138] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the identity authentication device connected to the on-board diagnostic interface, the identity authentication device connected to the on-board diagnostic interface: obtains the whole vehicle authentication status; when the whole vehicle authentication status is that authentication is required, obtains the certificate information sent by the diagnostic device; verifies the legitimacy of the certificate information, obtains the verification result, and sends the verification result and the initial random number to the diagnostic device; receives the signed random number sent by the diagnostic device; authenticates the signed random number, obtains the authentication result, and sends the authentication result to the diagnostic device.

[0139] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0140] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0141] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0142] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned identity authentication method for accessing the on-board diagnostic interface, and can solve the technical problem of how to improve the security of the communication information of the diagnostic service without changing the security algorithm of the vehicle ECU. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the identity authentication method for accessing the on-board diagnostic interface provided by the above-mentioned embodiment, and will not be repeated here.

[0143] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the identity authentication method for accessing an on-board diagnostic interface as described above.

[0144] The computer program product provided by this application can solve the technical problem of how to improve the security of the communication information of the diagnostic service without changing the security algorithm of the vehicle ECU. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the identity authentication method for accessing the on-board diagnostic interface provided by the above embodiment, and will not be repeated here.

[0145] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. An identity authentication method for accessing an on-board diagnostic interface, characterized in that: The method is applied to a gateway controller of a vehicle, and the method comprises: Get the vehicle certification status; When the vehicle certification status is that certification is required, obtaining certificate information sent by the diagnostic device; Verifying the legitimacy of the certificate information to obtain a verification result, and sending the verification result and an initial random number to the diagnostic device; Receiving a signed random number sent by the diagnostic device; The signature random number is authenticated to obtain an authentication result, and the authentication result is sent to the diagnostic device.

2. The method according to claim 1, characterized in that The step of verifying the legitimacy of the certificate information, obtaining a verification result, and sending the verification result and an initial random number to the diagnostic device comprises: Performing a format check on the certificate information according to a preset format standard to obtain a format check result; Verify the issuance chain of the certificate information according to the trusted root certificate authority information to obtain the issuance chain verification result; When the format check result and the issuance chain verification result are both correct, the verification result is obtained as verification passed, and the verification result and the initial random number are sent to the diagnostic device; When the format check result or the issuance chain verification result is incorrect, the verification result is obtained as verification failure, and the verification result and the initial random number are sent to the diagnostic device.

3. The method according to claim 1, characterized in that The step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device comprises: Extracting the public key from the certificate information; Decrypt the signature random number using the public key to obtain a decrypted target random number; Compare the initial random number with the target random number to obtain a comparison result; When the comparison result is completely consistent, the authentication result is obtained as successful authentication, and the authentication result is sent to the diagnostic device; When the comparison result is inconsistent, the authentication result is obtained as authentication failure, and the authentication result is sent to the diagnostic device.

4. The method according to claim 1, characterized in that After the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, the method further includes: When the authentication result is successful, configuring the controller area network channel and the Ethernet channel to enable the routing function; When the vehicle authentication status is that authentication is not required or has been authenticated, a diagnostic message sent by a diagnostic device is received, and the diagnostic message is forwarded through the controller area network and the Ethernet.

5. The method according to claim 1, characterized in that After the step of authenticating the signed random number, obtaining an authentication result, and sending the authentication result to the diagnostic device, the method further includes: When the authentication result is successful, switching the vehicle authentication state to authenticated; When a software reset instruction or a sleep instruction is received, the diagnostic message forwarding function of the controller local area network and the Ethernet is turned off, and the vehicle authentication state is switched to authentication required.

6. An identity authentication method for accessing an on-board diagnostic interface, characterized in that: The method is applied to a diagnostic device, and the method comprises: Get the vehicle certification status; When the vehicle authentication status is that authentication is required, sending certificate information to the gateway controller of the vehicle; Receiving the initial random number sent by the gateway controller and the verification result of the legitimacy of the certificate information; Sign the initial random number using a private key to obtain a signed random number; The signature random number is sent to the gateway controller, and an authentication result of the signature random number fed back by the gateway controller is received.

7. The method according to claim 6, characterized in that After the step of sending the signature random number to the gateway controller and receiving the authentication result of the signature random number fed back by the gateway controller, the method further includes: When the authentication result is successful, a diagnostic message is sent to the gateway controller to perform vehicle diagnosis.

8. An identity authentication device connected to an on-board diagnostic interface, characterized in that: The device comprises: Certification status acquisition module, used to obtain the vehicle certification status; A certificate acquisition module, used for acquiring certificate information sent by the diagnostic device when the vehicle authentication status is that authentication is required; A verification module, used to verify the legitimacy of the certificate information, obtain a verification result, and send the verification result and an initial random number to the diagnostic device; A random number receiving module, used for receiving a signed random number sent by the diagnostic device; The authentication module is used to authenticate the signature random number, obtain an authentication result, and send the authentication result to the diagnostic device.

9. An identity authentication device connected to an on-board diagnostic interface, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program on the gateway controller is configured to implement the steps of the identity authentication method for accessing the on-board diagnostic interface as described in any one of claims 1 to 5, and the computer program on the diagnostic device is configured to implement the steps of the identity authentication method for accessing the on-board diagnostic interface as described in any one of claims 6 to 7.

10. An identity authentication system connected to an on-board diagnostic interface, characterized in that: The system comprises a gateway controller as claimed in any one of claims 1 to 5 or a diagnostic device as claimed in any one of claims 6 to 7.

Images