Authentication method, apparatus and system

Abstract

An authentication method, an apparatus and a system. The method comprises: a diagnostic node sending authentication request information to a server, the authentication request information comprising a first identifier of the diagnostic node and information to be signed; the server determining, on the basis of the first identifier, a first sub-private key corresponding to the diagnostic node, and signing, on the basis of the first sub-private key, the information to be signed to obtain a first sub-signature; the server sending the first sub-signature to the diagnostic node, and the diagnostic node using a second sub-private key to sign the first sub-signature so as to obtain a first signature, the first signature being used for checking the diagnostic node; and the diagnostic node sending the first signature and the first identifier to a vehicle to be diagnosed, wherein the first sub-private key and the second sub-private key are both private key components of the diagnostic node.

Description

Authentication methods, devices and systems Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and more specifically, to an authentication method, apparatus, and system. Background Technology

[0002] On-board diagnostics (OBD) is an online diagnostic system used in vehicles to monitor vehicle status and control emissions. An OBD system can include a diagnostic node and a diagnostic agent module within the vehicle. The diagnostic agent module receives diagnostic commands from the diagnostic node through a diagnostic interface. These commands are used to diagnose the target electronic control unit (ECU). Upon receiving a diagnostic command, the diagnostic agent module performs a diagnostic on the target ECU according to the command. To avoid exposing vehicle information or introducing attacks through the diagnostic node, the vehicle needs to authenticate and authorize the diagnostic node before performing diagnostics. When diagnostics are required through the diagnostic node, the diagnostic agent node typically needs to perform OBD access authentication based on the diagnostic node's digital signature. After successful OBD access authentication, the diagnostic node can perform diagnostics other than those related to security access (0x27) services (hereinafter referred to as 27 services). When performing 27 service-related diagnostics, the diagnostic agent node needs to further authenticate the diagnostic node.

[0003] However, under the current technological background, the private key used for the digital signature of the diagnostic node is easily leaked, making the diagnostic node vulnerable to being impersonated or simulated by attackers. Furthermore, impersonated or simulated diagnostic nodes are not easily detected by the diagnostic agent node, allowing attackers to obtain vehicle information through OBD access authentication.

[0004] Therefore, a certification scheme for diagnostic nodes that can improve vehicle safety is urgently needed.

[0005] Summary of the Invention

[0006] This application provides an authentication method, apparatus, and system that helps improve the reliability of access authentication results when performing access authentication on diagnostic nodes of connected vehicles, thereby improving vehicle security and reducing the probability of vehicle information leakage.

[0007] Firstly, an authentication method is provided that can be executed by a server, for example, by the server's processor, chip, or circuitry.

[0008] The method includes: receiving authentication request information, the authentication request information including a first identifier of a first diagnostic node, the first diagnostic node being used to diagnose a vehicle to be diagnosed; obtaining first signature information, the first signature information being used by the vehicle to be diagnosed to verify the first diagnostic node; determining a first sub-private key corresponding to the first diagnostic node based on the first identifier; signing the first signature information based on the first sub-private key to obtain a first sub-signature, the first sub-signature being used to generate a first signature, the first signature being used by the vehicle to be diagnosed to verify the legitimacy of the first diagnostic node; and sending the first sub-signature to the first diagnostic node.

[0009] In some implementations, the first information to be signed is random. For example, the first information to be signed can be randomly generated raw data (such as a string), or the first information to be signed can be a hash value (or hash value) obtained by hashing the randomly generated raw data.

[0010] In some implementations, obtaining the first information to be signed includes receiving the first information to be signed from the first diagnostic node.

[0011] In some implementations, obtaining the first information to be signed includes generating the first information to be signed. In this implementation, the method further includes sending the first information to be signed to the vehicle to be diagnosed; and / or sending the first information to be signed to a first diagnostic node.

[0012] In the above technical solution, the server generates a portion of the signature used to verify the first diagnostic node, while the remaining portion of the signature is generated by other entities. Thus, when an attacker wants to impersonate the first diagnostic node, they need to compromise at least two entities, including the server, simultaneously. This increases the difficulty of the attack and improves the reliability of the authentication results of the vehicle under diagnosis accessing the first diagnostic node, thereby enhancing the security of the vehicle under diagnosis and reducing the risk of information leakage.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, the first sub-signature is obtained by signing the first information to be signed based on the first sub-private key, including: when the legitimacy verification of the first diagnostic node is passed, the first information to be signed is signed to obtain the first sub-signature.

[0014] In the above technical solution, before the server signs the first information to be signed, it verifies the legitimacy of the first diagnostic node, which can identify counterfeit or simulated diagnostic nodes. Only when the legitimacy of the first diagnostic node is verified is the first information to be signed signed, which can reduce the risk of leakage of the private key of the first diagnostic node.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: receiving a third identifier of the vehicle to be diagnosed; receiving a second identifier of the first diagnostic node; and performing a legality verification on the first diagnostic node based on the second identifier and the third identifier.

[0016] In some implementations, the first identifier and the second identifier are the same; for example, both the first identifier and the second identifier are the serial number (SN) of the first diagnostic node. Alternatively, the first identifier and the second identifier can be different; for example, the first identifier is the digital certificate of the first diagnostic node, and the second identifier is the SN of the first diagnostic node, or the first identifier is the SN of the first diagnostic node, and the second identifier is the digital certificate of the first diagnostic node. The digital certificate includes information such as the public key of the first diagnostic node, the identifier of the first diagnostic node (e.g., SN), and the signature algorithm used in the certificate, which can be used to determine the identity of the certificate owner.

[0017] In the above technical solution, combining the identification of the vehicle to be diagnosed by the first diagnostic node with the legitimacy verification of the first diagnostic node helps to improve the reliability of the legitimacy verification results.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: determining that the legality verification of the first diagnostic node is passed when the following conditions are met based on the second identifier and the third identifier: the vehicle to be diagnosed is powered on; the second identifier and the third identifier are bound together; the number of times the communication address corresponding to the second identifier changes within a first time period does not exceed a first threshold; and the number of times the authentication request information corresponding to the second identifier is received within a second time period does not exceed a second threshold.

[0019] In the above technical solution, the legitimacy of the first diagnostic node is verified based on the status of the vehicle to be diagnosed, the relationship between the vehicle to be diagnosed and the first diagnostic node, and the relevant status of the first diagnostic node. This helps to further improve the reliability of the legitimacy verification results, thereby reducing the risk of leakage of relevant information of the vehicle to be diagnosed.

[0020] In conjunction with the first aspect, in some implementations of the first aspect, the first identifier includes the first certificate of the first diagnostic node. Before receiving the authentication request information, the method further includes: generating a first sub-private key; generating a first sub-public key based on the first sub-private key, the first sub-public key being used to obtain the first certificate; and sending the first sub-public key to the first diagnostic node.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: storing the association between the first sub-private key and the first diagnostic node.

[0022] In some implementations, the server stores the association between multiple pairs of diagnostic nodes and sub-private keys.

[0023] In the above technical solution, the server stores the association between the first diagnostic node and its related sub-private keys, which facilitates the quick determination of the sub-private key associated with the first diagnostic node when the authentication request information of the first diagnostic node is received, thereby speeding up the authentication process of the first diagnostic node.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, the first sub-signature includes a first part, a second part, and a third part. The first sub-signature is obtained by signing the first information to be signed based on the first sub-private key, including: generating a first random number; calculating a first value based on the base point and the first random number; generating a second random number; determining the first part based on the second random number and the first value; determining the second part based on the first sub-private key and the first part; and determining the third part based on the first sub-private key and the first value.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: receiving a second value from a first diagnostic node, the second value being generated based on a base point; determining a first part based on a second random number and a first value, including: determining the first part based on the first value, the second value, and the second random number.

[0026] The second aspect provides an authentication method that can be executed by a first diagnostic node, which can be a diagnostic instrument or diagnostic platform, and more specifically, can be executed by the processor, chip or circuit of the first diagnostic node.

[0027] The method includes: sending authentication request information to a first server, the authentication request information including a first identifier of a first diagnostic node; receiving a first sub-signature from the first server, the first sub-signature being obtained by signing a first piece of information to be signed, the first piece of information to be signed being used by the vehicle to be diagnosed to verify the first diagnostic node; signing the first piece of information to be signed using a second sub-private key to obtain a first signature, the first signature being used to verify the first diagnostic node; and sending the first signature and the first identifier to the vehicle to be diagnosed.

[0028] In the above technical solution, the server generates a portion of the signature used to verify the first diagnostic node. Based on this portion of the signature generated by the server, the first diagnostic node obtains the complete first signature, enabling the vehicle under diagnosis to verify the first diagnostic node. This way, if an attacker wants to impersonate the first diagnostic node, they need to compromise both the server and the first diagnostic node simultaneously, increasing the difficulty of the attack and thus improving the reliability of the authentication result of the vehicle under diagnosis accessing the first diagnostic node. This, in turn, enhances the security of the vehicle under diagnosis and reduces the risk of information leakage.

[0029] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving first unsigned information from the vehicle to be diagnosed.

[0030] In the above technical solution, the first node to be diagnosed obtains the first signature information from the vehicle to be diagnosed, which helps to reduce the processing complexity and computational load of the first node to be diagnosed.

[0031] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: generating raw data; performing hash processing on the raw data to obtain the first information to be signed.

[0032] In some implementations, the method further includes: the first node to be diagnosed sends the first signature information to the vehicle to be diagnosed.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the first sub-signature includes a first part, a second part, and a third part. The first signature is obtained by signing the first information to be signed using the second sub-private key, including: obtaining the first signature based on the second sub-private key, the first part, the second part, and the third part.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: generating a third random number; generating a second value based on the third random number and a base point; sending the second value to a first server, the second value being used to generate the first part. In conjunction with the second aspect, in some implementations of the second aspect, the first identifier includes a first certificate of the first diagnostic node, and the method further includes: generating a second sub-private key; receiving a first sub-public key from the first server; generating a first public key based on the second sub-private key and the first sub-public key; and obtaining a first certificate based on the first public key.

[0035] Thirdly, an authentication device is provided, comprising a transceiver unit and a processing unit. The transceiver unit is configured to: receive authentication request information, the authentication request information including a first identifier of a first diagnostic node and first information to be signed, the first information to be signed being used by the vehicle to be diagnosed to verify the first diagnostic node; the transceiver unit is further configured to: obtain the first information to be signed, the first information to be signed being used by the vehicle to be diagnosed to verify the first diagnostic node; the first diagnostic node is used to diagnose the vehicle to be diagnosed; the processing unit is configured to: determine a first sub-private key corresponding to the first diagnostic node based on the first identifier; the processing unit is further configured to: sign the first information to be signed based on the first sub-private key to obtain a first sub-signature, the first sub-signature being used to generate a first signature, the first signature being used by the vehicle to be diagnosed to verify the legitimacy of the first diagnostic node; the transceiver unit is further configured to: send the first sub-signature to the first diagnostic node.

[0036] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is used to: sign the first information to be signed to obtain a first sub-signature when the legality verification of the first diagnostic node passes.

[0037] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is further configured to: receive the third identifier of the vehicle to be diagnosed; receive the second identifier of the first diagnostic node; and the processing unit is further configured to: perform legality verification on the first diagnostic node based on the second identifier and the third identifier.

[0038] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is further configured to: determine that the legality verification of the first diagnostic node is passed when the following conditions are met based on the second identifier and the third identifier: the vehicle to be diagnosed is in a powered-on state; the second identifier and the third identifier have a binding relationship; the number of times the communication address corresponding to the second identifier changes within a first time period does not exceed a first threshold; and the number of times the authentication request information corresponding to the second identifier is received within a second time period does not exceed the second threshold.

[0039] In conjunction with the third aspect, in some implementations of the third aspect, the first identifier includes the first certificate of the first diagnostic node. Before the transceiver unit receives the authentication request information, the processing unit is further configured to: generate a first sub-private key; generate a first sub-public key based on the first sub-private key, the first sub-public key being used to obtain the first certificate; the transceiver unit is further configured to: send the first sub-public key to the first diagnostic node.

[0040] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is also used to: store the association between the first sub-private key and the first diagnostic node.

[0041] In conjunction with the third aspect, in some implementations of the third aspect, the first sub-signature includes a first part, a second part, and a third part. The processing unit is further configured to: generate a first random number, calculate a first value based on the base point and the first random number; generate a second random number, determine the first part based on the second random number and the first value; determine the second part based on the first sub-private key and the first part; and determine the third part based on the first sub-private key and the first value.

[0042] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is further configured to: receive a second value from the first diagnostic node, the second value being generated based on the base point; and the processing unit is configured to: determine the first part based on the first value, the second value, and the second random number.

[0043] Fourthly, an authentication device is provided, comprising a transceiver unit and a processing unit, wherein the transceiver unit is configured to: send authentication request information to a first server, the authentication request information including a first identifier of a first diagnostic node; receive a first sub-signature from the first server, the first sub-signature being obtained by signing first information to be signed, the first information to be signed being used by the vehicle to be diagnosed to verify the first diagnostic node; the processing unit is configured to: sign the first information to be signed using a second sub-private key to obtain a first signature, the first signature being used to verify the first diagnostic node; the transceiver unit is further configured to: send the first signature and the first identifier to the vehicle to be diagnosed.

[0044] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is also used to: receive first unsigned information from the vehicle to be diagnosed.

[0045] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is also used to: generate raw data; and perform hash processing on the raw data to obtain the first information to be signed.

[0046] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first sub-signature includes a first part, a second part, and a third part, and the processing unit is used to obtain the first signature based on the second sub-private key, the first part, the second part, and the third part.

[0047] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is further configured to: generate a third random number, and generate a second value based on the third random number and the base point; the transceiver unit is further configured to: send the second value to the first server, the second value being used to generate the first part. In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first identifier includes the first certificate of the first diagnostic node, and the processing unit is further configured to: generate a second sub-private key; the transceiver unit is further configured to: receive a first sub-public key from the first server; generate a first public key based on the second sub-private key and the first sub-public key; and obtain the first certificate based on the first public key.

[0048] Fifthly, an authentication device is provided, the device comprising: a processor for executing a computer program stored in the memory, such that the device performs the method in any possible implementation of the first aspect described above.

[0049] A sixth aspect provides an authentication device comprising: a processor for executing a computer program stored in the memory, such that the device performs the method in any possible implementation of the second aspect described above.

[0050] In conjunction with the fifth or sixth aspect, in some implementations of the fifth or sixth aspect, the device also includes a memory.

[0051] In a seventh aspect, an authentication system is provided, which includes the means of any one of the implementations of the third and fourth aspects, or the system includes the means of any one of the implementations of the fifth and sixth aspects.

[0052] Eighthly, a computer program product is provided, comprising: computer program code, which, when executed on a computer or processor, causes the computer or processor to perform the method in any possible implementation of the first or second aspect.

[0053] It should be noted that the above computer program code can be stored in whole or in part on a storage medium, which can be packaged together with the processor or packaged separately from the processor.

[0054] Ninth aspect, a computer-readable storage medium is provided, the computer-readable medium storing instructions that, when executed by a processor, cause the processor to implement the method in any possible implementation of the first or second aspect.

[0055] In a tenth aspect, a chip is provided, the chip including circuitry for performing the methods in any possible implementation of the first or second aspect described above.

[0056] For the beneficial effects not described in detail in aspects three through ten, please refer to the descriptions in aspect one or two, which will not be repeated here. Attached Figure Description

[0057] Figure 1 is a schematic diagram of the diagnostic system provided in an embodiment of this application;

[0058] Figure 2 is a schematic flowchart of the authentication method provided in the embodiments of this application;

[0059] Figure 3 is another schematic flowchart of the authentication method provided in the embodiments of this application;

[0060] Figure 4 is another schematic flowchart of the authentication method provided in the embodiments of this application;

[0061] Figure 5 is another schematic flowchart of the authentication method provided in the embodiments of this application;

[0062] Figure 6 is another schematic flowchart of the authentication method provided in the embodiments of this application;

[0063] Figure 7 is a schematic block diagram of the authentication device provided in an embodiment of this application;

[0064] Figure 8 is another schematic block diagram of the authentication device provided in the embodiments of this application. Detailed Implementation

[0065] On-board diagnostics (OBD) refers to the inspection of a vehicle without disassembling it, determining its technical condition and identifying the location and cause of faults. OBD generally includes: testing and diagnosing the vehicle's powertrain, chassis, body and accessories, exhaust emissions and noise, and ECU firmware updates.

[0066] On-board diagnostics includes remote diagnostics and local diagnostics. Remote diagnostics refers to the process where the diagnostic platform sends diagnostic commands via a wireless communication network to a device that communicates with both in-vehicle and external equipment, such as a telematics box (T-Box). The T-Box then forwards the diagnostic commands to the target ECU for diagnosis. Local diagnostics refers to the process where the diagnostic tool connects to a diagnostic interface and directly sends diagnostic commands to the target ECU for diagnosis.

[0067] As mentioned above, under the current technological background, the private key used for the digital signature of the diagnostic instrument is easily leaked, which can lead to the diagnostic instrument being impersonated or simulated by attackers. Furthermore, the impersonated or simulated diagnostic instrument is not easily detected by the diagnostic agent node, which allows attackers to access authentication through OBD and thus easily obtain vehicle information.

[0068] Therefore, embodiments of this application provide an authentication method, apparatus, and system that can improve the reliability of authentication results for diagnostic nodes, thereby enhancing vehicle safety during the diagnostic process.

[0069] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0070] Figure 1 illustrates a diagnostic system provided in an embodiment of this application. As shown in Figure 1, the diagnostic system 100 includes a diagnostic node 110, a diagnostic node cloud server 120, a vehicle 140, and a vehicle cloud server 150. The vehicle 140 includes a diagnostic agent module 130 and multiple devices to be diagnosed, such as device 1 and device 2. The diagnostic agent module 130 and the devices to be diagnosed can communicate based on the diagnostic communication over controller area network (DoCAN) protocol or the diagnostic communication over Internet protocol (DoIP) over Ethernet.

[0071] For example, in this embodiment, the device to be diagnosed may include, but is not limited to, an electronic control unit (ECU) or a domain control unit (DCU). The diagnostic node 110 may be a diagnostic tool or other physical diagnostic device for vehicle diagnostics. The vehicle cloud server 150 may be a vehicle history record (VHR) server or other vehicle networking servers. The diagnostic agent module 130 may be located in the vehicle domain controller (VDC), or it may be located in a communication device such as a gateway or a telematics box (T-box). In actual implementation, the diagnostic agent module 130 may also be located in the cockpit domain controller (CDC) and / or the advanced driving domain controller (ADC), also known as a mobile data center (MDC). Among them, VDC is used to realize functions such as vehicle control. VDC can be regarded as an integration of the power domain, chassis domain and body domain. In actual implementation, VDC may also be called other names, such as body domain controller (BDC), vehicle control server ICAS1, body super core (BSC), etc.; CDC is used to realize intelligent cockpit functions such as human-machine interaction. In actual implementation, CDC may also be called other names, such as media graphics unit (MGU), intelligent cockpit server ICAS3, cockpit super core (CSC), etc.; ADC or MDC is used to realize perception, decision and control functions related to intelligent driving. In actual implementation, ADC or MDC may also be called other names, such as special equipment system (SAS), intelligent driving server ICAS2, ADAS super core, etc. Among them, ICAS stands for in-car application-server (ICAS). Alternatively, the diagnostic agent module 130 can also be set in the vehicle central computer (VCC).

[0072] Specifically, diagnostic node 110 may include the aforementioned diagnostic platform and / or diagnostic instrument. During near-end diagnostics, diagnostic node 110 (e.g., a diagnostic instrument) can connect to diagnostic agent module 130 via the diagnostic interface of vehicle 140, and diagnostic agent module 130 performs diagnostics on the device to be diagnosed in vehicle 140. During remote diagnostics, diagnostic node 110 (e.g., a diagnostic platform) can connect to diagnostic agent module 130 via a communication system such as a T-Box in vehicle 140, and diagnostic agent module 130 performs diagnostics on the device to be diagnosed in vehicle 140. Before diagnosing the device to be diagnosed in response to diagnostic commands from diagnostic node 110, diagnostic node cloud server 120 and diagnostic agent module 130 need to authenticate diagnostic node 110. If authentication is successful, diagnostic agent node 130 performs the corresponding diagnostics in response to diagnostic commands from diagnostic node 110; otherwise, diagnostic agent node 130 does not respond to diagnostic commands from diagnostic node 110. More specifically, during the authentication process of diagnostic node 110, the roles of each node or module in the diagnostic system 100 are as described in items (i) to (iv) below:

[0073] (i) The vehicle cloud server 150 is used to acquire and store relevant information about one or more vehicles, such as vehicle identification information and vehicle power-on status. The vehicle identification information may include a vehicle identification number (VIN), or other uniquely identifying and distinguishing information about the vehicle. Further, the vehicle cloud server 150 can send the relevant information of one or more vehicles to the diagnostic node cloud server 120. For example, the vehicle cloud server 150 can communicate with the vehicle via a communication module such as a vehicle telematics box (T-BOX).

[0074] (II) Diagnostic Node Cloud Server 120: Used to register unregistered diagnostic nodes, assign sub-private keys and sub-public keys to unregistered diagnostic nodes, so that the certification authority (CA) can issue digital certificates for the unregistered diagnostic nodes. Before or after a diagnostic node completes registration, the diagnostic node can be paired with a vehicle. After pairing, the diagnostic node can be used to diagnose the vehicle. The pairing relationship between the diagnostic node and the vehicle can be stored in the vehicle or in the vehicle cloud server 150. The pairing relationship between the diagnostic node and the vehicle can be one-to-one (i.e., one diagnostic node is used to diagnose one vehicle), many-to-one (i.e., multiple diagnostic nodes are used to diagnose one vehicle), or one-to-many (i.e., one diagnostic node is used to diagnose multiple vehicles). For example, the pairing relationship between the vehicle and the diagnostic node can be configured by the engineer in the background or configured through other means, such as scanning a code (e.g., a QR code). The cloud server 120 can obtain relevant information about one or more vehicles from the vehicle cloud server 150, and can also obtain the pairing relationship between the diagnostic node and the vehicle from the vehicle cloud server 150. In some implementations, after receiving access information from diagnostic node 110, the diagnostic node cloud server 120 can verify the legitimacy of the diagnostic node based on the vehicle identifier carried in the access information. The access information can be sent by diagnostic node 110 to the diagnostic node cloud server 120 after connecting to the vehicle's diagnostic interface. After the legitimacy verification of the diagnostic node is successful, the diagnostic node cloud server 120 uses the sub-private key corresponding to diagnostic node 110 to sign the information to be signed from diagnostic node 110 to obtain a sub-signature. Further, the diagnostic node cloud server 120 sends the sub-signature information, including the sub-signature, to diagnostic node 110.

[0075] It should be noted that the aforementioned information to be signed can be generated by the vehicle to be diagnosed, for example, by the diagnostic agent module 130; or, the aforementioned information to be signed can also be generated by the diagnostic node 110 and notified to the vehicle to be diagnosed.

[0076] (III) Diagnostic node 110 signs the sub-signature using its own sub-private key to obtain the complete signature. The sub-private key of diagnostic node 110 is associated with the sub-private key corresponding to diagnostic node 110 generated by the diagnostic node cloud server 120. For example, associating the two sub-private keys can be understood as meaning that the complete private key cannot be recovered using only one of the two sub-private keys. For instance, each of the two associated sub-private keys can be a private key component generated using a key generation algorithm such as elliptic curve public key cryptography (e.g., the SM2 algorithm). Further, diagnostic node 110 sends the complete signature to the diagnostic agent module 130.

[0077] (iv) The diagnostic agent module 130 verifies the legitimacy of the diagnostic node 110 based on the complete signature. More specifically, the diagnostic agent module 130 can obtain the digital certificate of the diagnostic node 110, which includes a public key used to verify the complete signature. When the diagnostic agent module 130 receives the complete signature from the diagnostic node 110, the diagnostic agent module 130 verifies the legitimacy of the complete signature using the digital certificate of the diagnostic node 110. After the legitimacy verification is passed, the diagnostic node 110 is determined to be a legitimate diagnostic node.

[0078] The diagnostic system provided in this application has been explained above with reference to Figure 1. The specific process of the authentication method performed based on the system shown in Figure 1 will be explained in detail below with reference to Figure 2.

[0079] Figure 2 shows a schematic flowchart of the authentication method provided in this application embodiment. This method can be executed by a first server, a first diagnostic node, and a vehicle to be diagnosed. The first server can be the diagnostic node cloud server 120 in the diagnostic system 100 shown in Figure 1, the first diagnostic node can be the diagnostic node 110 in the diagnostic system 100 shown in Figure 1, and the vehicle to be diagnosed can be the vehicle 140 in the diagnostic system 100 shown in Figure 1. The actions performed by the vehicle to be diagnosed in the method shown in Figure 2 can be performed by a diagnostic agent node in the vehicle to be diagnosed. More specifically, the method includes a certificate issuance stage and an authentication stage. The certificate issuance stage includes steps S201 to S204, and the authentication stage includes some or all of the steps in S205 to S212. Wherein:

[0080] S201, the first server generates a first sub-private key associated with the first diagnostic node, and generates a first sub-public key based on the first sub-private key.

[0081] In some implementations, after the first server generates the first sub-private key, it stores the correspondence between the first sub-private key and the first diagnostic node.

[0082] Understandably, the first server can store multiple sub-private keys, as well as information about the diagnostic nodes corresponding to each of the multiple sub-private keys.

[0083] In some implementations, the first diagnostic node is a diagnostic node that has been registered with the first server.

[0084] In some implementations, the first diagnostic node is a diagnostic instrument, and the first server is a server that can be used to manage the diagnostic instrument; or, the first diagnostic node is a diagnostic platform, and the first server can be a server used to manage the diagnostic platform. For example, the first server and the diagnostic platform can be two parts of the same server, or the first server and the diagnostic platform can be two separate servers.

[0085] S202, the first diagnostic node generates the second sub-private key.

[0086] The second sub-private key and the first sub-private key are private key components of the same private key.

[0087] For example, the first server and the first diagnostic node can each calculate the sub-public keys corresponding to the first and second sub-private keys based on the same public key calculation algorithm. For example, the aforementioned public key calculation algorithm may include, but is not limited to, elliptic curve public key cryptography, discrete logarithm-based public key cryptography algorithms, or asymmetric encryption algorithms such as RSA.

[0088] In actual implementation, S201 and S202 can be executed simultaneously or sequentially, and this application does not limit this.

[0089] S203, the first server sends the first sub-public key to the first diagnostic node.

[0090] S204, the first diagnostic node obtains the first certificate issued for the first diagnostic node based on the first sub-public key and the second sub-private key.

[0091] In some implementations, the first diagnostic node calculates its public key based on the first sub-public key and the second sub-private key, and sends this public key, along with its identifier (such as a serial number), to the CA. Further, after the CA verifies the identity of the first diagnostic node based on its identifier, it signs the public key associated with the first diagnostic node to generate a first certificate, and sends the first certificate to the first diagnostic node.

[0092] In some implementations, the first diagnostic node sends the first certificate to the first server, and the first server stores the association between the first certificate and the first diagnostic node.

[0093] The aforementioned S201 to S204 describe the specific process by which the first diagnostic node obtains the first certificate before the first diagnostic node access authentication. The following details the authentication process after the first diagnostic node accesses the vehicle to be diagnosed.

[0094] After the first diagnostic node connects to the vehicle to be diagnosed, the first diagnostic node sends an authentication request to the first server to initiate the authentication process for the first diagnostic node.

[0095] S205, the first diagnostic node sends an authentication request to the first server, the authentication request including the first identifier of the first diagnostic node.

[0096] S206, The first server obtains the first information to be signed.

[0097] The information to be signed is used to verify the first diagnostic node of the vehicle to be diagnosed. For example, the first server obtains the first information to be signed in the following two ways:

[0098] 1) The first server generates the first signature information;

[0099] 2) The first server receives the first unsigned information from the first diagnostic node.

[0100] In the first scenario, after the first server generates the first information to be signed, it also sends the first information to be signed to the vehicle to be diagnosed; and / or, sends the first information to be signed to the first diagnostic node. In the second scenario, the first information to be signed can be generated by the first diagnostic node, or the first information to be signed can be generated by the vehicle to be diagnosed and sent to the first diagnostic node. If the first information to be signed is generated by the first diagnostic node, the first diagnostic node can also send the first information to be signed to the vehicle to be diagnosed.

[0101] S207, determine whether the first server has passed the legality verification of the first diagnostic node.

[0102] For example, the first server verifies the legitimacy of the first diagnostic node based on the identifier of the first diagnostic node and the identifier of the vehicle to be diagnosed.

[0103] Furthermore, if the first server passes the validity check of the first diagnostic node, S208 is executed; otherwise, the first server determines that the first diagnostic node is invalid.

[0104] "The legitimacy verification of the first diagnostic node has passed" can be understood as: the first server has determined that the first diagnostic node is qualified to diagnose the vehicle to be diagnosed.

[0105] In some implementations, the method further includes: a first server receiving a third identifier of the vehicle to be diagnosed; the first server receiving a second identifier of the first diagnostic node; and the first server performing a validity verification on the first diagnostic node based on the second identifier and the third identifier.

[0106] In some implementations, the legitimacy verification of the first diagnostic node is deemed successful when the first server determines that the following conditions are met based on the second and third identifiers: the vehicle to be diagnosed is powered on; the second and third identifiers are bound together; the number of times the communication address corresponding to the second identifier changes within a first time period does not exceed a first threshold; and the number of times the authentication request information corresponding to the second identifier is received within a second time period does not exceed a second threshold.

[0107] S208, the first server generates the first sub-signature based on the first sub-private key and the first information to be signed.

[0108] Specifically, generating the first sub-signature based on the first sub-private key and the first information to be signed can be done by: using the first sub-private key to sign the first information to be signed, thus obtaining the first sub-signature.

[0109] For example, the first subsignature can be generated using an elliptic curve digital signature algorithm, or it can be generated using a public-key cryptography algorithm based on discrete logarithms, or an algorithm such as RSA.

[0110] In some implementations, the first subsignature includes a first part, a second part, and a third part. Generating the first subsignature includes: a first server generating a first random number and calculating a first value based on a base point and the first random number; a first server generating a second random number and determining the first part based on the second random number and the first value; a first server determining the second part based on the first sub-private key and the first part; and a first server determining the third part based on the first sub-private key and the first value.

[0111] In some implementations, the method further includes: a first server receiving a second value from a first diagnostic node, the second value being generated based on a base point; the first server determining a first part based on a second random number and a first value, including: the first server determining the first part based on the first value, the second value, and the second random number.

[0112] S209, the first server sends the first sub-signature to the first diagnostic node.

[0113] S210, the first diagnostic node generates the first signature based on the first sub-signature and the second sub-private key.

[0114] Specifically, generating the first signature based on the first sub-signature and the second sub-private key can be achieved by using the second sub-private key to sign the first sub-signature, thus obtaining the first signature.

[0115] For example, the first signature is generated using the same algorithm as in S208.

[0116] In some implementations, the first sub-signature includes a first part, a second part, and a third part. The first signature is obtained by signing the first information to be signed using the second sub-private key. This includes: the first diagnostic node obtains the first signature based on the second sub-private key, the first part, the second part, and the third part.

[0117] S211, the first diagnostic node sends the first signature and the first identifier to the vehicle to be diagnosed.

[0118] Optionally, after executing S204', S206 can be executed directly, so that when the first diagnostic node sends the first signature to the node to be diagnosed, the first signature information is sent together.

[0119] S212, the vehicle to be diagnosed verifies the legitimacy of the first diagnostic node based on the first signature.

[0120] For example, the vehicle to be diagnosed uses the public key in the first certificate to process the first information to be signed to obtain relevant values, and then determines whether the relevant values ​​are consistent with the first signature. If they are consistent, the first diagnostic node is determined to be a legitimate diagnostic node, that is, the first diagnostic node can diagnose the vehicle to be diagnosed. For example, the first diagnostic node can obtain information such as the mileage, energy consumption, tire pressure, and vehicle air quality data of the vehicle to be diagnosed; or, after passing 27 authentication, the first diagnostic node can also obtain the image file of the vehicle to be diagnosed, thereby realizing the diagnosis of the vehicle to be diagnosed based on 27 services.

[0121] The authentication method provided in this application embodiment has been described above. The following, with reference to Figures 3 to 6, details the specific implementation of digital certificate issuance, verification of the legality of the diagnostic node by the diagnostic node cloud server, and verification of the legality of the diagnostic node by the vehicle to be diagnosed. The methods shown in Figures 3 to 6 can be considered as an expansion of the method shown in Figure 2, or the methods shown in Figures 3 to 6 can be executed independently. More specifically, each method shown in Figures 3 to 6 can be executed by some or all of the server 1, diagnostic node 1, and vehicle to be diagnosed. Server 1 can be considered an example of the aforementioned diagnostic node cloud server 120, diagnostic node 1 can be considered an example of the aforementioned diagnostic node 110, and the vehicle to be diagnosed can be considered an example of the aforementioned vehicle 140.

[0122] Figure 3 shows another schematic flowchart of the authentication method provided in this application embodiment. This method is used to register diagnostic nodes and issue digital certificates for registered diagnostic nodes. More specifically, the method includes:

[0123] S301, Diagnostic Node 1 transmits its identification information to Server 1 for registration.

[0124] For example, the identification information of diagnostic node 1 may include one or more of the following information that can uniquely identify diagnostic node 1: the serial number (SN) of diagnostic node 1, the physical fingerprint of diagnostic node 1, or the authentication chip information of diagnostic node 1.

[0125] After receiving the identification information of diagnostic node 1, if diagnostic node 1 has not yet registered with server 1, server 1 records (or registers) the identification information of diagnostic node 1. Further, server 1 can execute S302.

[0126] S302, Server 1 generates sub-private key 1 for diagnostic node 1 and records the correspondence between diagnostic node 1 and sub-private key 1.

[0127] For example, server 1 can generate a random number k1 based on an elliptic curve public-key cryptography algorithm, which serves as the sub-private key 1.

[0128] Furthermore, server 1 includes a correspondence between sub-private key 1 and diagnostic node 1, so that sub-private key 1 can be used to sign the information to be signed related to diagnostic node 1.

[0129] S303, Diagnostic node 1 generates sub-private key 2.

[0130] For example, diagnostic node 1 generates a random number k2 as sub-private key 2. Specifically, diagnostic node 1 can generate the random number k2 using the same algorithm as that used to generate sub-private key 1 in S302, or the diagnostic node can call a function to generate the random number k2 via a cryptographic machine.

[0131] In practice, S303 and S302 can be executed synchronously, or S303 can be executed before or after S302.

[0132] S304, Server 1 calculates sub-public key 1 based on sub-private key 1.

[0133] For example, sub-public key 1 (such as P1) can be obtained based on the F() algorithm, for example, P1 = F(k1). More specifically, taking F() as the SM2 algorithm as an example, G is the base point of the elliptic curve C used by the SM2 algorithm, and the k1 times dot product of G on the elliptic curve C is P1.

[0134] S305, Server 1 sends sub-public key 1 to diagnostic node 1.

[0135] S306, Diagnostic node 1 generates public key P based on sub-private key 2 and sub-public key 1.

[0136] For example, the public key, sub-private key 2, and sub-public key 1 satisfy the following relationship: P = k2 -11 *P1-G.

[0137] S307, Diagnostic Node 1 sends its public key P and identification information to the CA.

[0138] S308, CA determines whether diagnostic node 1 is valid.

[0139] For example, the CA queries the server 1 to see if diagnostic node 1 has been registered based on the identification information. If it is determined that diagnostic node 1 has been registered with the server 1, the CA determines that diagnostic node 1 is valid and then executes step S309. If the CA determines that diagnostic node 1 is invalid, the CA ignores the information of diagnostic node 1.

[0140] For example, "diagnostic node is legitimate" in this step can be understood as: the diagnostic node has been registered in the diagnostic node cloud server.

[0141] S309, CA issues certificate 1 for diagnostic node 1.

[0142] For example, the CA uses its private key to sign the public key P, thus obtaining certificate 1.

[0143] In some implementations, certificate 1 may include information that uniquely identifies diagnostic node 1, such as public key P, SN of diagnostic node 1, and the issuing authority (CA) of certificate 1, or certificate 1 may also include information such as the validity period of certificate 1.

[0144] S310, CA sends Certificate 1 to diagnostic node 1.

[0145] S311, Diagnostic node 1 sends certificate 1 to server 1.

[0146] S312, Server 1 stores the correspondence between diagnostic node 1 and certificate 1.

[0147] In some implementations, server 1 can send certificate 1 to vehicles that have a pairing relationship (or binding relationship) with diagnostic node 1.

[0148] It is understandable that server 1 can be regarded as an example of the first server in the method shown in Figure 2, diagnostic node 1 can be regarded as an example of the first diagnostic node in the method shown in Figure 2, and certificate 1 can be regarded as an example of the aforementioned first certificate. Then, sub-private key 1, sub-private key 2, sub-public key 1, and public key P can be regarded as examples of the aforementioned first sub-private key, second sub-private key, first sub-public key, and public key of the first diagnostic node, respectively.

[0149] Figure 4 illustrates another schematic flowchart of the authentication method provided in this application embodiment, which is used to implement the legality verification of the diagnostic node by the diagnostic node cloud server. More specifically, the method includes:

[0150] S401, the vehicle to be diagnosed sends its identifier 1 to server 1.

[0151] For example, the vehicle to be diagnosed sends identifier 1 to server 1 through the vehicle cloud server, that is, the vehicle to be diagnosed sends identifier 1 to the vehicle cloud server, and the vehicle cloud server sends identifier 1 to server 1.

[0152] In some implementations, when the vehicle to be diagnosed detects that the diagnostic interface has been connected to the diagnostic node, relevant information is sent to the vehicle cloud server so that the vehicle cloud server sends identifier 1 to server 1.

[0153] In some implementations, when the vehicle to be diagnosed detects that the diagnostic interface has been connected to the diagnostic node, the vehicle cloud server also sends the vehicle's power-on status to server 1, which indicates whether the vehicle has been powered on.

[0154] S402, the vehicle to be diagnosed sends its identifier 1 to diagnostic node 1.

[0155] For example, the vehicle to be diagnosed sends identifier 1 to diagnostic node 1 through the diagnostic interface.

[0156] S403, Diagnostic Node 1 sends the identifier a of the vehicle to be diagnosed and the identifier b of Diagnostic Node 1 to Server 1.

[0157] Understandably, if diagnostic node 1 is not attacked, identifier 'a' is the same as identifier 1.

[0158] For example, identifier b can be certificate 1 of diagnostic node 1, or identifier b can be information that can uniquely identify diagnostic node 1, such as the serial number (SN), physical fingerprint, or authentication chip information of diagnostic node 1.

[0159] S404, Server 1 determines whether the vehicle corresponding to identifier a has been powered on.

[0160] In one example, server 1 determines whether to receive the power-on status of the vehicle corresponding to identifier a based on identifier a. If server 1 does not receive the power-on status of the vehicle corresponding to identifier a, it can send a request to the vehicle cloud server to request the power-on status of the vehicle with identifier a in the current time period.

[0161] In another example, server 1 has already received information about the power-on status of the vehicle corresponding to identifier 'a'. Based on this information, server 1 determines whether the vehicle corresponding to identifier 'a' is powered on in the current time period. The current time period can be a time interval from the current moment to a moment after the current moment; or, the current time period can also be a time interval from a moment before the current moment to a moment after the current moment. For example, the duration of the current time period can be between 2 and 3 minutes, or it can be any other duration.

[0162] Specifically, when server 1 determines that the vehicle corresponding to identifier a has been powered on, it executes S405; otherwise, it terminates the authentication process and determines that the legality verification of diagnostic node 1 has failed.

[0163] S405, Server 1 determines whether diagnostic node 1 has been registered.

[0164] For example, based on the identification information (such as identifier b) of diagnostic node 1, it is determined whether diagnostic node 1 has been registered in server 1. If the identification information of diagnostic node 1 is recorded in server 1, it is determined that diagnostic node 1 has been registered; otherwise, it is determined that diagnostic node 1 has not been registered.

[0165] Specifically, if server 1 determines that diagnostic node 1 has been registered, it executes S406; otherwise, it terminates the authentication process and determines that the validity verification of diagnostic node 1 has failed.

[0166] S406, Server 1 determines that diagnostic node 1 is included in the disabled list.

[0167] For example, the disabled list records the identification information of diagnostic nodes that are prohibited from use. When the identification information of diagnostic node 1 is included in the disabled list, it is determined that diagnostic node 1 is included in the disabled list.

[0168] Specifically, if server 1 determines that diagnostic node 1 is not included in the disabled list, execute S407; otherwise, end the authentication process and determine that the validity verification of diagnostic node 1 failed.

[0169] S407, Server 1 determines whether a pairing relationship exists between the vehicle and diagnostic node 1.

[0170] Specifically, if there is a pairing relationship between the vehicle corresponding to identifier 'a' and diagnostic node 1, execute step S408; otherwise, end the authentication process and determine that the validity verification of diagnostic node 1 has failed. The method for determining the pairing relationship between the diagnostic node and the vehicle can be referred to the description in the preceding embodiments, and will not be repeated here.

[0171] S408, Server 1 determines whether the number of communication address changes corresponding to Node 1 within a time period of 1 exceeds the threshold 1.

[0172] For example, duration 1 can be a duration of 2 to 3 minutes, or it can be any other duration; threshold 1 can be a value of 3 to 5 times, or it can be any other value.

[0173] For example, if the communication between server 1 and diagnostic node 1 is based on the IP protocol, the communication address of diagnostic node 1 can be an IP address; if the communication between server 1 and diagnostic node 1 is based on other network protocols, the communication address of diagnostic node 1 can be other communication addresses.

[0174] In some implementations, if the communication address of diagnostic node 1 changes too many times within a duration of 1, it can be determined that diagnostic node 1 may be being simulated, and diagnostic node 1 will be added to the disabled list. If the number of communication address changes corresponding to diagnostic node 1 within a duration of 1 does not exceed the threshold 1, then S409 is executed.

[0175] S409, Server 1 determines whether the number of times it receives information from diagnostic node 1 within duration 2 exceeds threshold 2.

[0176] In some implementations, a simulated diagnostic node might attempt to bypass the validity check by modifying the application logic and submitting multiple applications (e.g., executing S403 multiple times). Therefore, if the number of times information from diagnostic node 1 is received within duration 2 exceeds the threshold 2, it can be determined that diagnostic node 1 may be simulated, and diagnostic node 1 will be added to the disabled list. If the number of times information from diagnostic node 1 is received within duration 2 does not exceed the threshold 2, then S410 is executed.

[0177] For example, duration 2 can be one of 2 to 3 minutes, or it can be any other duration; threshold 2 can be one of 3 to 5 times, or it can be any other value.

[0178] S410, Server 1 confirms that Node 1 is valid.

[0179] It is understood that duration 1 can be considered as an example of the first duration in the method shown in Figure 2, threshold 1 can be considered as an example of the first threshold in the method shown in Figure 2, duration 2 can be considered as an example of the second duration in the method shown in Figure 2, and threshold 2 can be considered as an example of the second threshold in the method shown in Figure 2. Identifier a and identifier b can be considered as examples of the aforementioned second identifier and third identifier, respectively.

[0180] Figure 5 shows another schematic flowchart of the authentication method provided in this application embodiment. This method can be regarded as an implementation of verifying the legitimacy of the diagnostic node by the vehicle to be diagnosed. More specifically, the method includes:

[0181] S501, the vehicle to be diagnosed sends its identifier 1 to server 1.

[0182] The method and timing by which the vehicle to be diagnosed sends identifier 1 to server 1 can be referred to the description in S401, and will not be repeated here.

[0183] S502, the vehicle to be diagnosed sends the signature information 1 to the diagnostic node 1.

[0184] For example, the information to be signed 1 can be generated by the vehicle to be diagnosed. For instance, the vehicle to be diagnosed generates a string A, and then performs a hash calculation on string A to obtain the hash value of string A as the information to be signed 1.

[0185] More specifically, the vehicle to be diagnosed sends a signature-pending information 1 to diagnostic node 1 through the diagnostic interface.

[0186] S503, Diagnostic Node 1 sends the pending signature information 1 and the identifier of Diagnostic Node 1 to Server 1.

[0187] In some implementations, diagnostic node 1 in S503 can also send the identifier of the vehicle to be diagnosed to server 1.

[0188] For example, the identifier of diagnostic node 1 can be the digital certificate of diagnostic node 1 (such as certificate 1), or the identifier of diagnostic node 1 can also be information that can uniquely identify diagnostic node 1, such as the serial number (SN) of diagnostic node 1, physical fingerprint, authentication chip related information, etc.

[0189] S504, Server 1 determines whether the validity check has passed.

[0190] For example, the server determines whether the validity check of diagnostic node 1 passes. If the validity check of diagnostic node 1 passes, S505 is executed; otherwise, the authentication process ends, and the event of the validity check of diagnostic node 1 failing is recorded. If the number of times the validity check of diagnostic node 1 fails exceeds a certain number, diagnostic node 1 is added to the aforementioned disabled list. The specific implementation of server 1 determining whether the validity check of diagnostic node 1 passes can be referred to the description in the method shown in Figure 4, and will not be repeated here.

[0191] S505, Server 1 generates sub-signature 1 based on the information to be signed 1 and sub-private key 2.

[0192] For example, server 1 uses sub-private key 2 to sign the information to be signed 1, thus obtaining sub-signature 1.

[0193] In some implementations, taking the signing of server 1 and diagnostic node 1 based on the elliptic curve digital signature algorithm as an example, before executing S503, diagnostic node 1 generates a random number D1, and generates a value Q1 based on the random number D1 and the aforementioned base point G. For example, Q1 = D1 * G. Then, diagnostic node 1 sends the value Q1 to server 1.

[0194] For example, server 1 generates a random number D2 and generates a value Q2 based on the random number D2 and the base point G. Further, server 1 generates a random number D3 and then calculates (x1, y1) = D3 * Q1 + Q2 and r = x1 + emod(n), where e is the information to be signed 1 and n is a positive integer.

[0195] If r is not equal to 0, then calculate s2 = k2 * D3 mod (n) and s3 = k2 * (r + D2) mod (n), where k2 is the sub-private key 2. If r is equal to 0, then repeat the above steps to recalculate r until a non-zero r is obtained. It can be understood that sub-signature 1 includes r, s2, and s3.

[0196] S506, Server 1 sends sub-signature 1 to diagnostic node 1.

[0197] For example, information related to subsignature 1 may include subsignature 1, such as r, s2, and s3.

[0198] S507, Diagnostic node 1 generates signature information A based on sub-signature 1 and sub-private key 1.

[0199] For example, calculate s = (k1*D1)*s2 + k1*s3 - rmod(n), where k1 is the sub-private key 1. If s is not equal to 0 and not equal to nr, then (r, s) is used as the signature information A. If s is equal to 0 or s = nr, then n is recalculated until s is not equal to 0 and not equal to nr.

[0200] S508, Diagnostic Node 1 sends signature information A and the identifier of Diagnostic Node 1 to the vehicle to be diagnosed.

[0201] S509, the vehicle to be diagnosed verifies the legitimacy of diagnostic node 1 based on signature information A.

[0202] For example, the vehicle to be diagnosed determines the public key P of diagnostic node 1 based on the identifier of diagnostic node 1, and then calculates r' and s' based on the public key P, the information to be signed 1, and the aforementioned elliptic curve digital signature algorithm. If r' and s are the same as r and s respectively, then diagnostic node 1 is determined to be valid; otherwise, diagnostic node 1 is considered invalid.

[0203] Figure 6 shows another schematic flowchart of the authentication method provided in the embodiments of this application. This method can be regarded as another implementation of verifying the legitimacy of the diagnostic node by the vehicle to be diagnosed. More specifically, the method includes:

[0204] S601, the vehicle to be diagnosed sends its identifier 1 to server 1.

[0205] The method and timing by which the vehicle to be diagnosed sends identifier 1 to server 1 can be referred to the description in S401, and will not be repeated here.

[0206] S602, Diagnostic node 1 generates signature information 2.

[0207] For example, diagnostic node 1 generates string B, and then performs a hash calculation on string B to obtain the hash value of string B as the information to be signed 2.

[0208] For example, message 2 to be signed is e, which satisfies the following formula: e = hash(M'), M' = Z||M.

[0209] S603, Diagnostic node 1 sends the pending signature information 2, certificate 1, and the identifier 1 of the vehicle to be diagnosed to server 1.

[0210] S603', Diagnostic node 1 sends the pending signature information 2 to the vehicle to be diagnosed.

[0211] The specific implementations of S604 to S609 can be found in the descriptions in S504 to S509, and will not be repeated here.

[0212] In some implementations, after the vehicle to be diagnosed determines that diagnostic node 1 is a legitimate diagnostic node using the method shown in Figure 5 or Figure 6, the vehicle to be diagnosed can send information such as its mileage, energy consumption, tire pressure, and vehicle air quality data to the diagnostic node. Furthermore, after diagnostic node 1 passes 2.7 authentication, it can also obtain an image file of the vehicle to be diagnosed, thereby enabling 2.7 service-based diagnosis of the vehicle. For example, after obtaining the image file of the vehicle to be diagnosed, diagnostic node 1 can send the image file to server 1. If server 1 does not receive the image file from diagnostic node 1 within a certain period after issuing sub-signature 1 or sub-signature 2, server 1 will add diagnostic node 1 to its disabled list.

[0213] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0214] The methods provided by the embodiments of this application have been described in detail above with reference to Figures 1 to 6. The apparatus provided by the embodiments of this application will now be described in detail below with reference to Figures 7 and 8. It should be understood that the descriptions of the apparatus embodiments correspond to the descriptions of the method embodiments; therefore, any content not described in detail can be found in the method embodiments above, and for the sake of brevity, will not be repeated here.

[0215] Figure 7 shows a schematic block diagram of an authentication device 2000 provided in an embodiment of this application. The device 2000 may include units for executing the methods described in the foregoing embodiments. Furthermore, each unit in the device 2000 implements a corresponding process of the above method embodiments. The device 2000 includes a transceiver unit 2010, which can be used to implement corresponding data acquisition or transmission / reception functions. The device 2000 also includes a processing unit 2020, which can be used to implement corresponding processing functions.

[0216] Optionally, the device 2000 further includes a storage unit, which can be used to store instructions and / or data. The processing unit 2020 can read the instructions and / or data in the storage unit so that the device can perform the relevant actions in the aforementioned method embodiments.

[0217] It should be understood that the specific process of each unit performing the above-mentioned corresponding steps has been described in detail in the above method embodiments, and will not be repeated here for the sake of brevity.

[0218] It should also be understood that the device 2000 described herein is embodied in the form of a functional unit. The terms “module” or “unit” may refer to application-specific ASICs, electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, integrated logic circuits, and / or other suitable components that support the described functions.

[0219] The apparatus in this embodiment has the function of implementing the corresponding steps in the aforementioned method. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver unit 2010 can be replaced by a transceiver, and other units, such as the processing unit, can be replaced by a processor, used to execute the relevant processing operations in each method embodiment.

[0220] For example, the transceiver unit 2010 and the processing unit 2020 can be located in the diagnostic node 110 shown in FIG. 1, or they can also be located in the diagnostic node cloud server 120 shown in FIG. 1. The operations performed by the transceiver unit 2010 and the processing unit 2020 can be executed by a single processor, or they can be executed by different processors. In specific implementation, the one or more processors can be processors or chips located in the diagnostic node 110 or the diagnostic node cloud server 120 shown in FIG. 1.

[0221] In the specific implementation process, the units in the above device can be fully or partially integrated together, or they can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SoC).

[0222] Figure 8 is another schematic block diagram of the authentication device provided in the embodiments of this application. The device 2100 shown in Figure 8 may include: a processor 2110, a transceiver 2120, and a memory 2130. The processor 2110, transceiver 2120, and memory 2130 are connected via internal interconnection paths. The memory 2130 is used to store instructions, and the processor 2110 is used to execute the instructions stored in the memory 2130 to implement the methods in the above embodiments. Optionally, the memory 2130 may be coupled to the processor 2110 via an interface or integrated with the processor 2110.

[0223] It should be noted that the transceiver 2120 mentioned above may include, but is not limited to, transceiver devices such as input / output interfaces, to realize communication between device 2100 and other devices or communication networks.

[0224] Memory 2130 can be volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM). For example, RAM can be used as an external cache. By way of example and not limitation, RAM includes various forms such as: static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0225] Transceiver 2120 uses transceiver devices, such as but not limited to transceivers, to enable communication between device 2100 and other devices or communication networks to receive / send data / information for implementing the methods in the above embodiments.

[0226] This application also provides a server, which includes the device 2000 or device 2100 in the above embodiments.

[0227] This application embodiment also provides a diagnostic node (such as a diagnostic instrument or diagnostic platform), which includes the device 2000 or device 2100 in the above embodiments.

[0228] This application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to implement the methods described in the above embodiments of this application.

[0229] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to implement the methods described in the above embodiments of this application.

[0230] This application also provides a chip, including circuitry, for performing the methods described in the above embodiments of this application.

[0231] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0232] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In this application, "at least one" means one or more, and "more" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0233] The use of prefixes such as "first" and "second" in this application embodiment is solely for distinguishing different descriptive objects and does not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is found in the claims or the context of the embodiments, and the use of such prefixes should not constitute unnecessary restrictions.

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

[0235] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0236] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0237] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0238] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An authentication method, characterized in that, include: Receive authentication request information, the authentication request information including a first identifier of a first diagnostic node, the first diagnostic node being used to diagnose the vehicle to be diagnosed; Obtain first information to be signed, which is used by the vehicle to be diagnosed to verify the first diagnostic node. Determine the first sub-private key corresponding to the first diagnostic node based on the first identifier; The first sub-signature is obtained by signing the first information to be signed using the first sub-private key. The first sub-signature is used to generate the first signature. The first signature is used to verify the legitimacy of the first diagnostic node for the vehicle to be diagnosed. Send the first sub-signature to the first diagnostic node.

2. The method according to claim 1, characterized in that, The step of signing the first information to be signed based on the first sub-private key to obtain the first sub-signature includes: When the legitimacy verification of the first diagnostic node is passed, the first information to be signed is signed to obtain the first sub-signature.

3. The method according to claim 2, characterized in that, The method further includes: Receive the third identifier of the vehicle to be diagnosed; Receive the second identifier of the first diagnostic node; The legitimacy of the first diagnostic node is verified based on the second identifier and the third identifier.

4. The method according to claim 3, characterized in that, The method further includes: The validity verification of the first diagnostic node is deemed successful when the following conditions are met based on the second identifier and the third identifier: The vehicle to be diagnosed is powered on. The second identifier and the third identifier are bound together; The number of times the communication address corresponding to the second identifier changes within the first time period does not exceed the first threshold; and The number of times the authentication request information corresponding to the second identifier was received within the second time period did not exceed the second threshold.

5. The method according to any one of claims 1 to 4, characterized in that, The first identifier includes the first certificate of the first diagnostic node, and before receiving the authentication request information, the method further includes: Generate the first sub-private key; A first sub-public key is generated based on the first sub-private key, and the first sub-public key is used to obtain the first certificate; Send the first sub-public key to the first diagnostic node.

6. The method according to claim 5, characterized in that, The method further includes: Store the association between the first sub-private key and the first diagnostic node.

7. The method according to any one of claims 1 to 6, characterized in that, The first sub-signature includes a first part, a second part, and a third part. The step of signing the first information to be signed using the first sub-private key to obtain the first sub-signature includes: Generate a first random number, and calculate a first value based on the base point and the first random number; Generate a second random number, and determine the first part based on the second random number and the first value; The second part is determined based on the first sub-private key and the first part; The third part is determined based on the first sub-private key and the first value.

8. The method according to claim 7, characterized in that, The method further includes: Receive a second value from the first diagnostic node, the second value being generated based on the base point; Determining the first part based on the second random number and the first value includes: The first part is determined based on the first value, the second value, and the second random number.

9. An authentication method, characterized in that, Applied to the first diagnostic node, the method includes: Send authentication request information to the first server, the authentication request information including the first identifier of the first diagnostic node; Receive a first sub-signature from the first server. The first sub-signature is obtained by signing the first information to be signed. The first information to be signed is used to verify the first diagnostic node for the vehicle to be diagnosed. The first information to be signed is signed using the second sub-private key to obtain the first signature, which is used to verify the first diagnostic node. Send the first signature and the first identifier to the vehicle to be diagnosed.

10. The method according to claim 9, characterized in that, The method further includes: Receive the first signature information from the vehicle to be diagnosed.

11. The method according to claim 9, characterized in that, The method further includes: Generate raw data; The raw data is hashed to obtain the first information to be signed.

12. The method according to any one of claims 9 to 11, characterized in that, The first sub-signature includes a first part, a second part, and a third part. The step of signing the first information to be signed using the second sub-private key to obtain the first signature includes: The first signature is obtained based on the second sub-private key, the first part, the second part, and the third part.

13. The method according to claim 12, characterized in that, The method further includes: Generate a third random number, and generate a second value based on the third random number and the base point; The second value is sent to the first server, and the second value is used to generate the first part.

14. The method according to any one of claims 9 to 13, characterized in that, The first identifier includes the first certificate of the first diagnostic node, and the method further includes: Generate the second sub-private key; Receive the first sub-public key from the first server; Generate a first public key based on the second private key and the first public key; Obtain the first certificate based on the first public key.

15. An authentication device, characterized in that, include: The transceiver unit is used to receive authentication request information, which includes a first identifier of a first diagnostic node, the first diagnostic node being used to diagnose the vehicle to be diagnosed. The transceiver unit is further configured to: obtain first information to be signed, the first information to be signed being used by the vehicle to be diagnosed to verify the first diagnostic node; The processing unit is configured to determine a first sub-private key corresponding to the first diagnostic node based on the first identifier; The processing unit is further configured to: sign the first information to be signed according to the first sub-private key to obtain a first sub-signature, the first sub-signature is used to generate a first signature, and the first signature is used by the vehicle to be diagnosed to verify the legality of the first diagnostic node; The transceiver unit is also used to: send the first sub-signature to the first diagnostic node.

16. The apparatus according to claim 15, characterized in that, The processing unit is used for: When the legitimacy verification of the first diagnostic node is passed, the first information to be signed is signed to obtain the first sub-signature.

17. The apparatus according to claim 16, characterized in that, The transceiver unit is also used for: Receive the third identifier of the vehicle to be diagnosed; Receive the second identifier of the first diagnostic node; The processing unit is further configured to: perform legality verification on the first diagnostic node based on the second identifier and the third identifier.

18. The apparatus according to claim 17, characterized in that, The processing unit is also used for: The validity verification of the first diagnostic node is deemed successful when the following conditions are met based on the second identifier and the third identifier: The vehicle to be diagnosed is powered on. The second identifier and the third identifier are bound together; The number of times the communication address corresponding to the second identifier changes within the first time period does not exceed the first threshold. as well as The number of times the authentication request information corresponding to the second identifier was received within the second time period did not exceed the second threshold.

19. The apparatus according to any one of claims 15 to 18, characterized in that, The first identifier includes the first certificate of the first diagnostic node. Before the transceiver unit receives the authentication request information, the processing unit is further configured to: Generate the first sub-private key; A first sub-public key is generated based on the first sub-private key, and the first sub-public key is used to obtain the first certificate; The transceiver unit is also used to: send the first sub-public key to the first diagnostic node.

20. The apparatus according to claim 19, characterized in that, The processing unit is also used for: Store the association between the first sub-private key and the first diagnostic node.

21. The apparatus according to any one of claims 15 to 20, characterized in that, The first sub-signature includes a first part, a second part, and a third part, and the processing unit is further configured to: Generate a first random number, and calculate a first value based on the base point and the first random number; Generate a second random number, and determine the first part based on the second random number and the first value; The second part is determined based on the first sub-private key and the first part; The third part is determined based on the first sub-private key and the first value.

22. The apparatus according to claim 21, characterized in that, The transceiver unit is also used for: Receive a second value from the first diagnostic node, the second value being generated based on the base point; The processing unit is used for: The first part is determined based on the first value, the second value, and the second random number.

23. An authentication device, characterized in that, The device is disposed at the first diagnostic node, and the device includes: A transceiver unit is used to send authentication request information to a first server, the authentication request information including a first identifier of a first diagnostic node; Receive a first sub-signature from the first server. The first sub-signature is obtained by signing the first information to be signed. The first information to be signed is used to verify the first diagnostic node for the vehicle to be diagnosed. The processing unit is used to sign the first information to be signed using the second sub-private key to obtain a first signature, which is used to verify the first diagnostic node. The transceiver unit is also used to: send the first signature and the first identifier to the vehicle to be diagnosed.

24. The apparatus according to claim 23, characterized in that, The transceiver unit is also used for: Receive the first signature information from the vehicle to be diagnosed.

25. The apparatus according to claim 23, characterized in that, The processing unit is also used for: Generate raw data; The raw data is hashed to obtain the first information to be signed.

26. The apparatus according to any one of claims 23 to 25, characterized in that, The first sub-signature includes a first part, a second part, and a third part, and the processing unit is used for: The first signature is obtained based on the second sub-private key, the first part, the second part, and the third part.

27. The apparatus according to claim 12, characterized in that, The processing unit is also used for: Generate a third random number, and generate a second value based on the third random number and the base point; The transceiver unit is further configured to: send the second value to the first server, wherein the second value is used to generate the first part.

28. The apparatus according to any one of claims 23 to 27, characterized in that, The first identifier includes the first certificate of the first diagnostic node, and the processing unit is further configured to: Generate the second sub-private key; The transceiver unit is further configured to: receive a first sub-public key from the first server; Generate a first public key based on the second private key and the first public key; Obtain the first certificate based on the first public key.

29. An authentication device, characterized in that, include: A processor for executing a computer program stored in memory to cause the apparatus to perform the method as described in any one of claims 1 to 8.

30. An authentication device, characterized in that, include: A processor for executing a computer program stored in memory to cause the apparatus to perform the method as described in any one of claims 9 to 14.

31. An authentication system, characterized in that, The system includes the apparatus as described in any one of claims 15 to 22, and the apparatus as described in any one of claims 23 to 28; or, the system includes the apparatus as described in claim 29, and the apparatus as described in claim 30.

32. A computer-readable storage medium, characterized in that, It stores instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 8, or the method as described in any one of claims 9 to 14.

33. A chip, characterized in that, The chip includes circuitry for performing the method as described in any one of claims 1 to 8, or the method as described in any one of claims 9 to 14.

34. A computer program product, characterized in that, The computer program product includes: computer program code, which, when executed by a processor, implements the method as described in any one of claims 1 to 8, or the method as described in any one of claims 9 to 14.

Images