A certificate fault-tolerant method for vehicle-cloud communication links

Abstract

This invention discloses a certificate fault-tolerance method for vehicle-to-cloud communication links. Based on fault-tolerance considerations, a backup certificate is pre-installed in the OTA component. When the vehicle-side OTA component determines that the certificate has expired, it switches to using the communication certificate directly connected to the OTA server backed up within the OTA component, establishes a connection with the OTA cloud server, and remotely flashes the T-Box using OTA to update the abnormal certificate and restore normal vehicle-to-cloud communication. This method can avoid vehicle recalls caused by certificate failures. It is simple, convenient, and efficient to operate, reducing recall costs. After locating the problem to the certificate anomaly, it effectively resolves user feedback, indirectly improving brand reputation and product influence.

Description

Technical Field

[0001] The present invention belongs to the technical field of vehicle-cloud communication for intelligent connected vehicles, and specifically relates to a certificate fault-tolerant method for a vehicle-cloud communication link. Background Art

[0002] Smart connected vehicles communicate with the TSP cloud (Telematics Service Provider) through the T-Box controller (Telematics Box). For information security, encryption, decryption, and identity authentication are required for the communication link. The key keys supporting these protections, namely certificates, can experience numerous anomalies during actual use. These include certificate expiration and inability to trigger reapplication, certificate verification failure, and accidental tampering with certificate files due to PKI platform frame corruption. These issues can directly lead to disconnection between the vehicle and the cloud, resulting in the failure of vehicle functions that rely on the TSP cloud, potentially causing irreparable losses and user complaints.

[0003] The only solution to this problem currently is to recall the car, have the user return to the 4S store, and flash the software of the T-Box controller to replace the abnormal certificate. However, this method has a significant impact on users and the company's reputation, and car recalls will also consume a lot of compensation costs. Summary of the Invention

[0004] In order to solve the above-mentioned problems existing in the prior art, the present invention provides a certificate fault-tolerant method for the vehicle-to-cloud communication link. Based on fault-tolerance considerations, a backup certificate is pre-set in the OTA component. The OTA component (Over-the-Air Technology) on the vehicle side determines that the certificate is invalid, switches to using the communication certificate directly connected to the OTA server backed up in the OTA component, establishes a connection with the OTA cloud server, and remotely flashes the T-Box using OTA to update the abnormal certificate to restore normal vehicle-to-cloud communication. The present invention can avoid vehicle recalls caused by certificate failures. It is simple to operate, convenient and efficient, reduces the cost caused by recalls, and efficiently solves user feedback problems after the problem is located in the certificate anomaly, indirectly improving brand reputation and product influence.

[0005] The purpose of the present invention is achieved through the following technical solutions:

[0006] A certificate fault-tolerant method for a vehicle-to-cloud communication link includes the following steps:

[0007] Step 1: T-Box sends a car-cloud connection request to TSP, and TSP responds to the TLS connection request; if the TLS connection is established successfully, proceed to step 2; if the TLS connection fails, proceed to step 3;

[0008] Step 2: T-Box establishes a TLS connection with TSP and performs vehicle-to-cloud business communication;

[0009] Step 3: T-Box determines the reason for the TLS connection establishment failure. If the reason is not a certificate abnormality, proceed to step 4; if the reason is a certificate abnormality, proceed to step 5.

[0010] Step 4: If the T-Box determines that the TLS connection establishment failed due to reasons other than certificate anomalies, it will record the fault code and return to step 1 to re-request the car-cloud connection.

[0011] Step 5: If the T-Box determines that the TLS connection establishment failed due to a certificate anomaly, it will first re-apply for a certificate and retry the car-cloud connection. If the TLS connection still cannot be established normally, proceed to step 6.

[0012] Step 6: Switch to using the backup certificate preset in the vehicle-side OTA component to establish a TLS connection with the OTA server. The OTA server remotely flashes the T-Box, updates the abnormal certificate, and uses the new certificate to complete the establishment of the vehicle-cloud link.

[0013] Furthermore, in step 1, the T-Box requests a four-way handshake from the TSP to establish a TLS connection, and the TSP responds to the TLS connection request and performs identity authentication.

[0014] Furthermore, the step 2 includes:

[0015] 2.1) Use the secure channel and session key established by TLS for vehicle-to-cloud business communication;

[0016] 2.2) When either party ends the communication and the T-Box goes into sleep mode, the TLS connection is disconnected.

[0017] Furthermore, in step five, the T-Box re-applies for the certificate within a preset number of times and time interval, and retries the vehicle-cloud connection.

[0018] Preferably, the time interval is 60 seconds, and the number of applications is limited to a maximum of 10 times within one power-on cycle.

[0019] Furthermore, the step six includes:

[0020] 6.1) Use the backup certificate pre-installed in the vehicle-side OTA component to establish a TLS connection with the OTA server, and report any abnormalities after the connection is successful;

[0021] 6.2) After receiving the exception, the OTA server will feedback to the T-Box engineer and manually issue a communication certificate on the PKI server. The manually issued communication certificate will be used to create the T-Box software and perform OTA push;

[0022] 6.3) After receiving the OTA push, the vehicle-side OTA component displays an OTA prompt to guide the user to complete the OTA update;

[0023] 6.4) After the OTA update, the T-Box uses the new certificate to complete the establishment of the car-cloud link.

[0024] Compared with the prior art, the present invention has the following advantages:

[0025] The present invention mainly targets the situation where, during the vehicle-cloud connection process, an abnormal T-Box communication certificate has been found, and the certificate abnormality problem can only be solved by flashing the T-Box controller. There are two flashing methods: one is to flash the software by connecting to the controller entity through a specific device, and the other is a remote OTA upgrade (Over-the-Air Technology). However, remote OTA upgrades often rely on the establishment of vehicle-cloud communication, transmitting information from the vehicle to the TSP, which then forwards it to the OTA server. Based on fault tolerance considerations, the present invention pre-sets a backup certificate in the OTA component. The OTA component (Over-the-Air Technology) on the vehicle side determines that the certificate is invalid, switches to using the communication certificate directly connected to the OTA server backed up in the OTA component, establishes a connection with the OTA cloud server, and remotely flashes the T-Box in an OTA manner to update the abnormal certificate to restore normal vehicle-cloud communication. This technology can avoid vehicle recalls caused by certificate failures. It is simple to operate, convenient and efficient, and reduces the cost of recalls. After the problem is located at the certificate abnormality, it efficiently solves the problem reported by users, indirectly improving brand reputation and product influence. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings used in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the contents of the embodiments of the present invention and these drawings without any creative work.

[0027] Figure 1 This is a flow chart of a certificate fault-tolerant method for a vehicle-to-cloud communication link described in an embodiment of the present invention. DETAILED DESCRIPTION

[0028] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0029] A certificate fault-tolerant method for a vehicle-to-cloud communication link includes the following steps:

[0030] Step 1: T-Box sends a car-cloud connection request to TSP, and TSP responds to the TLS connection request; if the TLS connection is established successfully, proceed to step 2; if the TLS connection fails, proceed to step 3;

[0031] Step 2: T-Box establishes a TLS connection with TSP and performs vehicle-to-cloud business communication;

[0032] Step 3: T-Box determines the reason for the TLS connection establishment failure. If the reason is not a certificate abnormality, proceed to step 4; if the reason is a certificate abnormality, proceed to step 5.

[0033] Step 4: If the T-Box determines that the TLS connection establishment failed due to reasons other than certificate anomalies, it will record the fault code and return to step 1 to re-request the car-cloud connection.

[0034] Step 5: If the T-Box determines that the TLS connection establishment failed due to a certificate anomaly, it will first re-apply for a certificate and retry the car-cloud connection. If the TLS connection still cannot be established normally, proceed to step 6.

[0035] Step 6: Switch to using the backup certificate preset in the vehicle-side OTA component to establish a TLS connection with the OTA server. The OTA server remotely flashes the T-Box, updates the abnormal certificate, and uses the new certificate to complete the establishment of the vehicle-cloud link.

[0036] Furthermore, in step 1, the T-Box requests a four-way handshake from the TSP to establish a TLS connection, and the TSP responds to the TLS connection request and performs identity authentication.

[0037] Preferably, the step 1 specifically includes:

[0038] First handshake:

[0039] 1.1) T-Box says HELLO, along with the TLS version, client random number, and client-supported algorithm suite.

[0040] Second handshake:

[0041] 1.2) TSP responds to the T-Box with the algorithm suite selected and sends the server-side random number;

[0042] 1.3) TSP sends the TSP server certificate, and T-Box verifies the validity of the certificate based on its own pre-set root certificate chain;

[0043] 1.4) TSP requests the T-Box certificate;

[0044] 1.5) TSP indicates that the second handshake is complete and the negotiation is complete;

[0045] 1.6) T-Box sends its own certificate, and TSP verifies the validity of the certificate using the root certificate chain;

[0046] Third handshake:

[0047] 1.7) T-Box generates a random number premaster secret, encrypts it using the public key in the TSP certificate, and sends it to the TSP;

[0048] 1.8) T-Box signs the above message using its private key and sends it to TSP for verification. After TSP passes the verification, it proceeds to the following steps;

[0049] 1.9) T-Box and TSP simultaneously use the algorithm specified in the TLS protocol to calculate the client random number, server random number, and premaster secret to generate a session key Master Secret;

[0050] 1.10) T-Box tells TSP to use session key for encrypted communication;

[0051] 1.11) T-Box calculates the digest of all previous messages, encrypts them with the session key and sends them to TSP. TSP decrypts them to confirm whether they are consistent.

[0052] Fourth handshake:

[0053] 1.12) TSP tells T-Box to use session key for encrypted communication;

[0054] 1.13) TSP calculates the digest of all previous messages, encrypts them with the session key and sends them to T-Box, which decrypts them to confirm whether they are consistent;

[0055] The above four-way handshake is completed. If all the above steps are executed correctly and verified, step 2 is executed.

[0056] Furthermore, the step 2 includes:

[0057] 2.1) Use the secure channel and session key established by TLS for vehicle-to-cloud business communication;

[0058] 2.2) When either party ends the communication and the T-Box goes into sleep mode, the TLS connection is disconnected.

[0059] Furthermore, in step five, the T-Box re-applies for the certificate within a preset number of times and time interval, and retries the vehicle-cloud connection.

[0060] Preferably, the time interval is 60 seconds, and the number of applications is limited to a maximum of 10 times within one power-on cycle.

[0061] Furthermore, the step six includes:

[0062] 6.1) Use the backup certificate pre-installed in the vehicle-side OTA component to establish a TLS connection with the OTA server, and report any abnormalities after the connection is successful;

[0063] 6.2) After receiving the exception, the OTA server will feedback to the T-Box engineer and manually issue a communication certificate on the PKI server. The manually issued communication certificate will be used to create the T-Box software and perform OTA push;

[0064] 6.3) After receiving the OTA push, the vehicle-side OTA component displays an OTA prompt to guide the user to complete the OTA update;

[0065] 6.4) After the OTA update, the T-Box uses the new certificate to complete the establishment of the car-cloud link.

[0066] Example

[0067] like Figure 1 As shown, a certificate fault tolerance method for a vehicle-to-cloud communication link includes the following steps:

[0068] Step 1: T-Box sends a car-cloud connection request to TSP, and TSP responds to the TLS connection request; if the TLS connection is established successfully, proceed to step 2; if the TLS connection fails, proceed to step 3;

[0069] Step 2: T-Box establishes a TLS connection with TSP and performs vehicle-to-cloud business communication;

[0070] Step 3: T-Box determines the reason for the TLS connection establishment failure. If the reason is not a certificate abnormality, proceed to step 4; if the reason is a certificate abnormality, proceed to step 5.

[0071] Step 4: If the T-Box determines that the TLS connection establishment failed due to reasons other than certificate anomalies, it will record the fault code and return to step 1 to re-request the car-cloud connection.

[0072] Step 5: If the T-Box determines that the TLS connection establishment failed due to a certificate anomaly, it will first re-apply for a certificate and retry the car-cloud connection. If the TLS connection still cannot be established normally, proceed to step 6.

[0073] Step 6: Switch to using the backup certificate preset in the vehicle-side OTA component to establish a TLS connection with the OTA server. The OTA server remotely flashes the T-Box, updates the abnormal certificate, and uses the new certificate to complete the establishment of the vehicle-cloud link.

[0074] Furthermore, in step 1, the T-Box requests a four-way handshake from the TSP to establish a TLS connection, and the TSP responds to the TLS connection request and performs identity authentication.

[0075] Preferably, the step 1 specifically includes:

[0076] First handshake:

[0077] 1.1) T-Box says HELLO, along with the TLS version (1.3), the client random number (plain text), and the algorithm suite supported by the client.

[0078] Second handshake:

[0079] 1.2) TSP responds to the T-Box with the algorithm suite selected and sends the server-side random number;

[0080] 1.3) TSP sends the TSP server certificate, and T-Box verifies the validity of the certificate based on its own pre-set root certificate chain;

[0081] 1.4) TSP requests the T-Box certificate;

[0082] 1.5) TSP indicates that the second handshake is complete and the negotiation is complete;

[0083] 1.6) T-Box sends its own certificate, and TSP verifies the validity of the certificate using the root certificate chain.

[0084] Third handshake:

[0085] 1.7) T-Box generates a random number premaster secret, encrypts it using the public key in the TSP certificate, and sends it to the TSP;

[0086] 1.8) To ensure that the TSP has received the correct certificate, the T-Box signs the above message using its private key and sends it to the TSP for verification. After the TSP passes the verification, it can proceed to the following steps;

[0087] 1.9) The T-Box and TSP simultaneously use an algorithm specified in the TLS protocol to calculate the client random number, the server random number, and the premaster secret to generate a session key - the Master Secret;

[0088] 1.10) T-Box informs TSP that I can use the session key for encrypted communication;

[0089] 1.11) T-Box calculates the digest of all previous messages, encrypts them with the session key and sends them to TSP, which decrypts them to confirm whether they are consistent.

[0090] Fourth handshake:

[0091] 1.12) TSP tells T-Box that I can use the session key for encrypted communication;

[0092] 1.13) TSP calculates the digest of all previous messages, encrypts them with the session key and sends them to T-Box, which decrypts them to confirm whether they are consistent.

[0093] The TLS four-way handshake is complete. If all the above steps are executed correctly and verified, proceed to step 2.

[0094] Explanation of technical terms in the above steps:

[0095] A. Asymmetric encryption: Also known as public-key cryptography, it is a cryptographic algorithm that requires two keys: a public key and a private key. As the name suggests, the public key can be freely distributed; the private key, on the other hand, must be kept strictly confidential by the user and never provided to anyone through any means, nor disclosed to the other party, even if the party is trusted.

[0096] In asymmetric encryption, both parties possess their own public-private key pair, but only one of them is used in actual communication. For example, the sender encrypts with their private key, and the receiver decrypts with the sender's public key; or the sender encrypts with the recipient's public key, and the recipient decrypts with their private key. In practice, either public or private key can be used for encryption, while the other is used for decryption. However, the key transmitted publicly is called the public key. Encrypting plaintext with one key can only yield ciphertext with the corresponding key, and even the original encryption key cannot be used for decryption. This is the most important characteristic of asymmetric encryption.

[0097] Furthermore, it must be impossible to derive the private key from the public key. At the very least, it must be computationally infeasible to derive the private key from the public key, otherwise security is compromised. Common solutions involve solving unsolved mathematical problems, such as factoring large prime numbers. Although the two keys are mathematically related, knowing the public key does not allow the private key to be calculated. Therefore, the public key can be made public, while the private key is kept private and never shared with anyone through any means.

[0098] Based on the above, it can be seen that the public and private key pairs used in asymmetric encryption can uniquely identify the user's identity. That is to say, if the encrypted message I received can be decrypted with your public key, then I am sure that the message is from you, or if the encrypted message I received can be decrypted with my private key, it proves that the message is intended for me.

[0099] B. Digital Signature: Similar to the signature we use when signing a document, a digital signature uniquely identifies the signatory. Identity identification is essentially authentication, so the principle behind digital signatures is asymmetric encryption. Encrypting an entire message is expensive, so a message digest is typically calculated and then asymmetric encryption is performed on this digest.

[0100] Digest calculation, also often called hash calculation or hash value calculation, simply means taking a long message and padding it, grouping it, calculating it, and performing an XOR operation on it to produce a shorter value, typically 128 or 256 bits. This calculation is one-way, and identical messages produce the same digest value. This way, the sender calculates the digest value for the entire message before sending it and appends it to the end of the message. The receiver then calculates the digest value for the received message and compares it with the appended digest value to verify whether the message has been tampered with.

[0101] The digest value was originally used primarily to ensure integrity in information security. However, in asymmetric encryption, due to the low computational efficiency of commonly used asymmetric algorithms and the excessive resources required to asymmetrically encrypt an entire message, the current common practice is to asymmetrically encrypt the message digest value. The result of this asymmetric encryption is what we often call a digital signature, which verifies both message integrity and non-repudiation.

[0102] Furthermore, the step 2 includes:

[0103] 2.1) Use the secure channel and session key established by TLS for vehicle-to-cloud business communication;

[0104] 2.2) When either party ends the communication and the T-Box goes into sleep mode, the TLS connection is disconnected.

[0105] Furthermore, in step five, the T-Box re-applies for the certificate within a preset number of times and time interval, and retries the vehicle-cloud connection solution.

[0106] Preferably, the time interval is 60 seconds, and the number of applications is limited to a maximum of 10 times within one power-on cycle.

[0107] Furthermore, the step six includes:

[0108] 6.1) Use the backup certificate pre-installed in the vehicle-side OTA component to establish a TLS connection with the OTA server, and report any abnormalities after the connection is successful;

[0109] 6.2) After receiving the exception, the OTA server will feedback to the T-Box engineer and manually issue a communication certificate on the PKI server. The manually issued communication certificate will be used to create the T-Box software and perform OTA push;

[0110] 6.3) After receiving the OTA push, the vehicle-side OTA component displays an OTA prompt to guide the user to complete the OTA update;

[0111] 6.4) After the OTA update, the T-Box uses the new certificate to complete the establishment of the car-cloud link.

[0112] The working principle of this embodiment is described below:

[0113] 1. Vehicle-to-cloud communication under normal circumstances:

[0114] 1. T-Box establishes a TLS connection with TSP;

[0115] 2. After the connection is successful, normal business communication is carried out;

[0116] 3. Until the T-Box goes into sleep mode and actively disconnects the link after the communication is completed.

[0117] 2. TLS connection establishment fails under abnormal circumstances:

[0118] 1. The T-Box determines the cause of the exception and reports the fault code. In addition to certificate exceptions, other possible causes of TLS connection failure include TSP service exceptions, network signal exceptions, PKI server exceptions, etc. These problems can be solved by retrying the connection after external conditions are restored;

[0119] 2. Certificate anomalies can be classified into the following situations:

[0120] (1) Communication certificate lost: The communication certificate is deleted for unknown reasons;

[0121] (2) The communication certificate has expired;

[0122] (3) The communication certificate has been revoked: The communication certificate has been revoked on the PKI server and its validity is abnormal;

[0123] (4) Communication certificate application link abnormality: The link where T-Box applies for a communication certificate from the PKI server is abnormal;

[0124] (5) Other unforeseen reasons;

[0125] Of the five situations mentioned above, the first three can be solved by automatically triggering the T-Box to re-apply for the certificate and retrying the car-cloud connection. It is worth noting that the number and time limits for the certificate application process should be set, such as a 60-second interval between each application and a maximum of ten applications within a power-on cycle. Otherwise, the PKI server will receive a large number of certificate applications from this T-Box, which is likely to cause the PKI server to crash.

[0126] 3. The last two exceptions mentioned in point 2 cannot be resolved by re-applying for a certificate through the T-Box. After the OTA component detects such an exception, it needs to use the preset communication certificate to establish a TLS connection with the OTA server and report the exception after the connection is successful.

[0127] 4. After receiving the exception, the OTA backend will report it to the T-Box engineer for analysis. A communication certificate that can be used normally will be manually issued on the PKI server, and the repaired T-Box software package with the normal communication certificate will be pushed OTA.

[0128] 5. After the vehicle-side OTA component receives the OTA push, it displays an OTA prompt to guide the user to complete the OTA upgrade. After the upgrade is successful, the T-Box uses the new certificate to complete the establishment of the vehicle-cloud link. If the link still cannot be completed, repeat steps 3 to 5.

[0129] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A certificate fault-tolerant method for a vehicle-to-cloud communication link, characterized in that: The following steps are involved: Step 1: T-Box sends a car-cloud connection request to TSP, and TSP responds to the TLS connection request; if the TLS connection is established successfully, proceed to step 2; if the TLS connection fails, proceed to step 3; Step 2: T-Box establishes a TLS connection with TSP and performs vehicle-to-cloud business communication; Step 3: T-Box determines the reason for the TLS connection establishment failure. If the reason is not a certificate abnormality, proceed to step 4; if the reason is a certificate abnormality, proceed to step 5. Step 4: If the T-Box determines that the TLS connection establishment failed due to reasons other than certificate anomalies, it will record the fault code and return to step 1 to re-request the car-cloud connection; Step 5: If the T-Box determines that the TLS connection establishment failed due to a certificate anomaly, it will first re-apply for a certificate and retry the car-cloud connection. If the TLS connection still cannot be established normally, proceed to step 6. Step 6: Switch to using the backup certificate preset in the vehicle-side OTA component to establish a TLS connection with the OTA server. The OTA server remotely flashes the T-Box, updates the abnormal certificate, and uses the new certificate to complete the establishment of the vehicle-cloud link.

2. A certificate fault-tolerant method for a vehicle-to-cloud communication link according to claim 1, characterized in that: In step 1, the T-Box requests a four-way handshake from the TSP to establish a TLS connection. The TSP responds to the TLS connection request and performs identity authentication.

3. A certificate fault tolerance method for a vehicle-to-cloud communication link according to claim 1, characterized in that: The second step includes: 2.1) Use the secure channel and session key established by TLS for vehicle-to-cloud business communication; 2.2) When either party ends the communication and the T-Box goes into sleep mode, the TLS connection is disconnected.

4. A certificate fault-tolerant method for a vehicle-to-cloud communication link according to claim 1, characterized in that: In step 5, the T-Box re-applies for the certificate within the preset number of times and time interval, and retries the vehicle-cloud connection.

5. A certificate fault tolerance method for a vehicle-to-cloud communication link as claimed in claim 4, characterized in that: The time interval is 60 seconds, and the number of applications is limited to a maximum of 10 times within one power-on cycle.

6. A certificate fault-tolerant method for a vehicle-to-cloud communication link according to claim 1, characterized in that: The step six comprises: 6.1) Use the backup certificate pre-installed in the vehicle-side OTA component to establish a TLS connection with the OTA server, and report any abnormalities after the connection is successful; 6.2) After receiving the exception, the OTA server will feedback to the T-Box engineer and manually issue a communication certificate on the PKI server. The manually issued communication certificate will be used to create the T-Box software and perform OTA push; 6.3) After receiving the OTA push, the vehicle-side OTA component displays an OTA prompt to guide the user to complete the OTA update; 6.4) After the OTA update, the T-Box uses the new certificate to complete the establishment of the car-cloud link.

Images