A vehicle upgrading method and device based on bidirectional authentication, equipment and medium

Abstract

The application discloses a vehicle upgrading method and device based on bidirectional authentication, equipment and medium, and belongs to the technical field of communication authentication. The method comprises the following steps: in the vehicle upgrading interaction, the vehicle and the upgrading service system are mutually authenticated through bidirectional digital certificates, and the upgrading request is initiated after confirming that both parties are legal and trusted; in the message interaction, the double encryption and decryption are realized by using an asymmetric encryption algorithm, the transmission data can be prevented from being intercepted, cracked or tampered with, meanwhile, the single exclusive and non-reusable temporary first and second random numbers are introduced, the consistency check of the second random number in the upgrading response message and the local decryption result of the vehicle end is carried out, and the illegal attacks such as replay and man-in-the-middle are blocked. The application can strongly bind the bidirectional identity authentication, the double encryption and decryption and the random number check with the whole upgrading process, and only when all the verifications are passed, the upgrading data is allowed to be issued and the upgrading is executed, so that the illegal flashing of the vehicle-mounted system and the malicious upgrading are effectively avoided, and the vehicle operation and the stability of the vehicle-mounted system are ensured.

Description

Technical Field

[0001] This application relates to the field of communication authentication technology, and in particular to a vehicle upgrade method, apparatus, device and medium based on two-way authentication. Background Technology

[0002] Upgrading a vehicle typically involves updating the program, optimizing the function, and fixing vulnerabilities of the vehicle's functions or systems. The upgrade process involves building secure authentication and communication mechanisms to ensure vehicle operation safety and prevent unauthorized program rewriting.

[0003] However, when implementing remote vehicle upgrades, traditional technologies typically use one-way authentication or simple encryption for upgrade interactions. For example, the vehicle verifies the legitimacy of the upgrade system and then uses basic encryption with a fixed key. This not only fails to establish a two-way digital certificate mutual verification mechanism between the vehicle and the upgrade service system, but also makes it easy for authentication data and communication during upgrade interactions to be intercepted or tampered with. This allows attackers to carry out man-in-the-middle attacks by replaying historical authentication information or tampering with upgrade instructions.

[0004] Due to the lack of two-way identity verification and anti-attack secure communication protection mechanisms, traditional technologies cannot simultaneously meet the security requirements of identity trust, data anti-tampering and data anti-replay attack during remote vehicle upgrades. This can easily lead to unauthorized flashing or malicious upgrades of the vehicle system, seriously threatening vehicle operation safety and the stable operation of the vehicle system. Summary of the Invention

[0005] The main purpose of this application is to propose a vehicle upgrade method, device, equipment, and medium based on two-way authentication. By strongly binding two-way authentication, dual encryption and decryption, and random number consistency verification to the entire upgrade process, the vehicle is only allowed to request upgrade data from the upgrade service system and perform vehicle function upgrades after all verification steps have passed. This effectively avoids the risk of the vehicle system being illegally flashed or maliciously upgraded, and ensures the safety of vehicle operation and the stable operation of the vehicle system.

[0006] To achieve the above objectives, one aspect of this application proposes a vehicle upgrade method based on two-way authentication, the method comprising: When an upgrade prompt is detected from the upgrade service system, a first random number is randomly generated, and then the vehicle-side digital certificate corresponding to the vehicle and the first random number are encapsulated into an authentication message. The authentication message is sent to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After the verification is successful, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the vehicle's public key. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. Verify the legitimacy of the system-side digital certificate in the response message. After successful verification, decrypt the combined data encrypted once in the response message based on the private key corresponding to the vehicle to generate a first decrypted random number and a second decrypted random number. Encrypt the second decrypted random number a second time based on the public key of the upgrade service system, and encapsulate the second decrypted random number into an upgrade request message. The upgrade request message is sent to the upgrade service system, so that the upgrade service system decrypts the second random number, which is encrypted twice in the upgrade request message, based on the private key of the upgrade service system, encapsulates the second random number after decryption twice into an upgrade response message, and returns the upgrade response message. The second random number decrypted twice in the upgrade response message is verified to be consistent with the second random number decrypted once locally. After the verification is successful, a data delivery request is sent to the upgrade service system. When the upgrade service system delivers the data to be upgraded, the vehicle function corresponding to the data to be upgraded is upgraded.

[0007] Furthermore, in some embodiments, the encapsulated content of the response message further includes: a first hash value; wherein the first hash value is obtained by hashing the first random number and the second random number, and is encapsulated in the response message; Before performing a second encryption on the second random number obtained from the first decryption based on the public key of the upgrade service system, the method further includes: A second hash value is obtained by performing a hash calculation based on the first random number obtained after the first decryption and the second random number obtained after the first decryption. Determine whether the second hash value is equal to the first hash value; If so, then continue with the second encryption operation; If not, the generation of the upgrade request message will be terminated, and the vehicle upgrade process will be terminated.

[0008] Furthermore, in some embodiments, the encapsulated content of the upgrade response message includes: a third hash value; wherein the third hash value is obtained by hashing the second random number after secondary decryption and is encapsulated in the upgrade response message; The step of verifying the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally, and sending a data delivery request to the upgrade service system after successful verification, includes: The second random number, after being decrypted locally once, is hashed to obtain the fourth hash value; When the fourth hash value is determined to be equal to the third hash value in the upgrade response message, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

[0009] Furthermore, in some embodiments, after deriving the fourth hash value, the method further includes: If the fourth hash value is determined to be different from the third hash value in the upgrade response message, an incomplete consistency verification result is generated, the operation of sending the data delivery request is terminated, and the vehicle upgrade process is terminated.

[0010] Furthermore, in some embodiments, the second random number is composed of several binary bits; the encapsulation content of the upgrade response message includes: the first mask sequence corresponding to the second random number after secondary decryption, the first data block feature value, and the tail node of the first one-way hash chain; The step of verifying the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally, and sending a data delivery request to the upgrade service system after successful verification, includes: The second random number, which is decrypted locally once, is divided into several second data blocks based on a preset byte unit. Each second data block corresponds to a number, and the numbers are arranged in ascending order of the splitting sequence. Extract a preset number of target binary bits from the second random number after local decryption, and perform an XOR operation on the target binary bits and a preset fixed value to generate a second mask factor; wherein, the preset number is less than the total number of binary bits in the second random number after local decryption; the generation rule of the first mask factor is the same as the generation rule of the second mask factor. Perform a bitwise AND operation on each bit of the second data block with the second mask factor, and arrange the AND operation results of all the second data blocks into an ordered set according to their numbering order. Output the second mask sequence corresponding to the second random number after local decryption. Perform a continuous bitwise XOR operation on all the second data blocks to generate the feature value of the second data block; The preset starting value is used as the first node of the second one-way hash chain. The preset starting value is XORed with the second data block with the smallest number, and the intermediate hash value corresponding to the second data block with the smallest number is output. Then, each second data block is processed one by one in ascending order of number. The intermediate hash value corresponding to the previous second data block is XORed with the current second data block, and the intermediate hash value corresponding to the current second data block is output. This process continues until the second data block with the largest number is processed. The intermediate hash value corresponding to the second data block with the largest number is used as the tail node of the second one-way hash chain. When it is determined that the first mask sequence and the second mask sequence are equal element by element, the first data block feature value and the second data block feature value are equal, and the tail node of the first one-way hash chain is equal to the tail node of the second one-way hash chain, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

[0011] Furthermore, in some embodiments, after generating the second mask sequence, the second data block feature value, and the tail node of the second one-way hash chain, the method further includes: If it is determined that the first mask sequence and the second mask sequence are not equal element by element, or the first data block feature value and the second data block feature value are not equal, or the tail node of the first one-way hash chain and the tail node of the second one-way hash chain are not equal, then a result indicating incomplete consistency verification is generated, the operation of sending the data delivery request is terminated, and the current vehicle upgrade process is terminated.

[0012] Furthermore, in some embodiments, the encapsulated content of the upgrade response message further includes: a server-side timestamp generated by the upgrade service system; After completing the consistency verification but before sending the data delivery request to the upgrade service system, the method further includes: Obtain the local current timestamp and calculate the time difference between the local current timestamp and the server timestamp; If the time difference is determined to be within a preset valid time window, the operation of sending a data delivery request to the upgrade service system will continue. If the time difference is determined to exceed the preset valid time window, a timing verification failure result is generated, and the vehicle upgrade process is terminated.

[0013] To achieve the above objectives, another aspect of this application proposes a vehicle upgrade device based on two-way authentication, the device comprising: The authentication message encapsulation module is used to randomly generate a first random number when an upgrade prompt is detected from the upgrade service system, and then encapsulate the vehicle-side digital certificate corresponding to the vehicle and the first random number into an authentication message. The authentication message sending module is used to send the authentication message to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After the verification is successful, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the public key of the vehicle. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. The response message decryption module is used to verify the legitimacy of the system-side digital certificate in the response message. After successful verification, it decrypts the combined data encrypted once in the response message based on the private key corresponding to the vehicle, generating a first decrypted random number and a second decrypted random number. Based on the public key of the upgrade service system, it performs a second encryption on the second decrypted random number and encapsulates the second encrypted random number into an upgrade request message. The upgrade request message sending module is used to send the upgrade request message to the upgrade service system, so that the upgrade service system can decrypt the second random number that has been encrypted twice in the upgrade request message based on the private key of the upgrade service system, encapsulate the second random number that has been decrypted twice into an upgrade response message, and return the upgrade response message. The consistency verification module is used to verify the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally. After the verification is successful, it sends a data delivery request to the upgrade service system. When the upgrade service system delivers the data to be upgraded, it upgrades the vehicle function corresponding to the data to be upgraded.

[0014] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned vehicle upgrade method based on two-way authentication.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned vehicle upgrade method based on two-way authentication.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a vehicle upgrade method, apparatus, device, and medium based on two-way authentication. In the upgrade interaction, the vehicle first sends its own digital certificate to the upgrade service system for the upgrade service system to complete the legitimacy verification. Subsequently, the vehicle verifies the system-side digital certificate in the response message returned by the upgrade service system. Through the above-mentioned two-way digital certificate mutual verification mechanism between the vehicle and the upgrade service system, after confirming that the vehicle is a legitimate authorized terminal and the upgrade service system is a trusted platform, the vehicle initiates a subsequent upgrade request. Furthermore, in the message interaction process of this invention, an asymmetric encryption algorithm is used to achieve double encryption and decryption. When the upgrade service system uses the vehicle's public key for encryption, the vehicle needs to complete the decryption using its own private key. After the vehicle uses the upgrade service system's public key for secondary encryption, the upgrade service system completes the secondary decryption using its own private key. Based on the above-mentioned asymmetric encryption characteristics of public and private key pairing, even if the data is intercepted during transmission, it cannot be cracked or tampered with, fundamentally ensuring the security of the transmitted data. Meanwhile, this invention introduces temporarily randomly generated first and second random numbers during the encrypted interaction process. Since these random numbers are generated randomly during a single upgrade interaction and cannot be reused, and by verifying the consistency between the second random number (obtained through secondary decryption in the upgrade response message) and the second random number obtained through primary decryption on the vehicle side, this invention effectively confirms that the transmitted data has not been replaced or tampered with, thereby directly blocking the implementation path of illegal attacks such as replay attacks and man-in-the-middle attacks. Compared with traditional technologies, this invention strongly binds two-way authentication, dual encryption / decryption, and random number consistency verification to the entire upgrade process. Only after all verification steps are passed is the vehicle side allowed to request upgrade data from the upgrade service system and execute the vehicle function upgrade. This effectively avoids the risk of the vehicle system being illegally flashed or maliciously upgraded, ensuring vehicle operation safety and the stable operation of the vehicle system. Attached Figure Description

[0017] Figure 1 This is a schematic flowchart of a vehicle upgrade method based on two-way authentication provided in an embodiment of this application; Figure 2 This is a schematic diagram of a vehicle upgrade device based on two-way authentication provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0020] As used in this application, the terms "several", "each", etc., "several" include one, two or more, "each" refers to each of the corresponding plurality, and "any" refers to any one of the plurality.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] (1) CA (Certificate Authority) is a security service entity operated by an authoritative and trusted third-party organization to issue, manage, revoke and verify digital certificates. By verifying the identity of the certificate applicant, the CA issues digital certificates containing public keys, identity information and CA signatures to legitimate entities, ensuring the unique binding of the public key to the entity's identity and preventing the public key from being forged, tampered with or misused.

[0024] (2) PKI (Public Key Infrastructure) is a comprehensive information security infrastructure based on asymmetric encryption algorithms, combined with CA certificate authentication system, digital certificates, key management strategies, etc. PKI uses digital certificates to distribute public keys and authenticate identities, ensuring that the identities of the communicating parties are trustworthy, and that data transmission is confidential, complete, and non-repudiable.

[0025] (3) SHA-256 (Secure Hash Algorithm 256) hash algorithm is a one-way hash algorithm in the SHA-2 cryptographic hash function family. It can calculate input data of arbitrary length and output a hash value of fixed length of 256 bits. It has the security characteristics of one-way irreversibility, collision resistance, and the output being completely changed by a small change in the input. It can be used to verify the integrity and authenticity of data.

[0026] Traditional technologies for remote vehicle upgrades lack a two-way digital certificate verification mechanism between the vehicle and the upgrade service system, relying solely on one-way authentication. This fails to simultaneously verify the legitimacy of both parties, posing risks of unauthorized vehicle access and fraudulent upgrade system access. Furthermore, the use of simple encryption methods like fixed keys for message exchange makes transmitted data vulnerable to interception, cracking, or tampering, compromising data transmission security. This increases the risk of unblockable replay attacks, man-in-the-middle attacks, and tampering with upgrade commands. Therefore, traditional technologies are susceptible to unauthorized flashing and malicious upgrades of the vehicle system, compromising vehicle operation and system stability.

[0027] In view of this, this application provides a vehicle upgrade method, apparatus, device and medium based on two-way authentication, which can strongly bind two-way authentication, dual encryption and decryption, random number consistency verification and upgrade execution process. Only when all verifications pass can the request to send upgrade data and execute vehicle function upgrade be allowed, thereby preventing the vehicle system from being illegally flashed or maliciously upgraded, and ensuring the safety of vehicle operation and the stable operation of the vehicle system.

[0028] Figure 1 This is an optional flowchart of a vehicle upgrade method based on two-way authentication provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S1 to S5: Step S1: When an upgrade prompt is detected from the upgrade service system, a first random number is randomly generated, and then the vehicle-side digital certificate corresponding to the vehicle and the first random number are encapsulated into an authentication message. Step S2: Send the authentication message to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After verification, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the vehicle's public key. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. Step S3: Verify the legality of the system-side digital certificate in the response message. After successful verification, decrypt the combined data encrypted once in the response message based on the private key corresponding to the vehicle to generate a first decrypted random number and a second decrypted random number. Encrypt the second decrypted random number a second time based on the public key of the upgrade service system, and encapsulate the second decrypted random number into an upgrade request message. Step S4: Send the upgrade request message to the upgrade service system, so that the upgrade service system decrypts the second random number that has been encrypted twice in the upgrade request message twice based on the private key of the upgrade service system, encapsulates the second random number that has been decrypted twice into an upgrade response message, and returns the upgrade response message. Step S5: Verify the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally. After the verification is successful, send a data delivery request to the upgrade service system. When the upgrade service system delivers the data to be upgraded, upgrade the vehicle function corresponding to the data to be upgraded.

[0029] Steps S1 to S5 as shown in the embodiments of this application enable the vehicle terminal to actively encapsulate the vehicle terminal digital certificate corresponding to the vehicle into the authentication message after detecting the upgrade prompt; optionally, the vehicle terminal digital certificate is a unique identity identifier pre-set when the vehicle leaves the factory, which may contain key information such as the vehicle unique code, validity period and encrypted signature, to prove the legal authorized identity of the vehicle. In step S2, after receiving the authentication message, the upgrade service system first verifies the legality of the vehicle-side digital certificate. Optionally, the verification content includes the validity of the certificate signature, the validity period, and the authenticity of the vehicle code. Only after the verification is passed can subsequent interactions proceed, effectively preventing unauthorized vehicles, such as vehicles without a valid vehicle-side digital certificate or with an expired certificate, from accessing the upgrade system. Furthermore, after receiving the response message from the upgrade service system, the vehicle verifies the legitimacy of the system-side digital certificate contained in the message. For example, the system-side digital certificate is the unique identity credential of the upgrade service system, and it also contains information such as system code and official signature. Only after the verification is passed will subsequent decryption and encryption operations be performed, effectively preventing fake upgrade systems from impersonating the official platform and issuing malicious commands.

[0030] Through the above-mentioned two-way digital certificate mutual verification, the embodiments of this application can simultaneously confirm that the vehicle is a legitimate authorized terminal and the upgrade service system is a trusted platform, which solves the problem that traditional one-way authentication technology cannot confirm the legitimacy of both parties, cuts off the illegal access path from the source of identity, and eliminates the risk of illegal vehicles accessing or fake upgrade systems accessing the system.

[0031] Furthermore, the data transmission security during the upgrade process is directly related to the integrity and confidentiality of upgrade commands and data. Traditional technologies use simple encryption methods such as fixed keys, but these keys remain unchanged for a long time and are easily cracked, making it easy for transmitted data to be intercepted or tampered with, thus failing to guarantee data transmission security. In contrast, the upgrade service system of this application verifies the legitimacy of the vehicle-side digital certificate and then encrypts the combination of the first and second random numbers based on the vehicle's public key. The vehicle's public key and the vehicle-side private key are a pair of paired asymmetric keys. The public key can be publicly used for encryption, while only the corresponding private key can be used for decryption. In step S3, after receiving the response message, the vehicle terminal decrypts the encrypted combined data using its own private key. Only after successful decryption can the first and second random numbers be obtained, ensuring that only legitimate vehicle terminals can parse the combined data. Subsequently, the vehicle terminal encrypts the decrypted second random number a second time using the public key of the upgrade service system. The public key and the system private key of the upgrade service system are also paired asymmetric keys. Furthermore, after receiving the upgrade request message, the upgrade service system can decrypt the second random number a second time using its own private key, thereby completing the two-way encryption and decryption interaction.

[0032] In this embodiment of the invention, based on the asymmetric encryption characteristic of public-private key pairing, encrypted data can only be decrypted with the corresponding private key. Furthermore, this embodiment of the application adopts a dual encryption mechanism to further enhance the security of data transmission. Even if the data is intercepted during transmission, the attacker will not be able to crack or tamper with the data because they do not have the corresponding private key. This completely solves the security risks of traditional fixed key encryption being easily cracked and data being easily tampered with, and ensures the integrity and confidentiality of upgraded interactive data from the transmission level.

[0033] Furthermore, in order to block the implementation path of illegal attacks such as replay attacks or man-in-the-middle attacks and to prevent the upgrade instructions from being tampered with, this application embodiment constructs a sound anti-attack mechanism through random number generation in steps S1 and S2 and consistency verification in step S5.

[0034] In step S1, the vehicle terminal randomly generates a first random number, and in step S2, the upgrade service system randomly generates a second random number. Both the first and second random numbers are generated exclusively for each upgrade interaction and are characterized by being non-reusable and highly random. Each upgrade interaction generates a completely new random number, which can prevent attackers from launching attacks by replaying historical authentication information. Finally, in step S5, the vehicle terminal performs a consistency check between the second random number decrypted twice in the upgrade response message and the second random number obtained by decryption once locally. If the two are inconsistent, it indicates that the transmitted data has been tampered with or replaced, and the upgrade process will be terminated immediately. If the two are consistent, it confirms that the data has not been tampered with, and the subsequent upgrade data distribution stage can proceed.

[0035] Therefore, by designing temporary random numbers for single-use and verifying their consistency, the embodiments of the present invention can directly block the implementation path of illegal attacks, prevent upgrade instructions from being tampered with, ensure the security of the upgrade interaction process, and solve the defects of traditional technologies in terms of weak anti-attack capabilities.

[0036] This application embodiment sets strict verification thresholds at each stage of the upgrade process. For example, if the two-way digital certificate mutual verification in steps S1 to S3 fails, the upgrade interaction will be terminated; if the double encryption and decryption in steps S2 to S4 fails and a valid random number cannot be obtained, the upgrade process will be terminated; moreover, if the second random number consistency check in step S5 fails, the request to send upgrade data will be rejected. Only when all verification steps are passed can the vehicle send a data sending request to the upgrade service system to obtain the data to be upgraded and perform the vehicle function upgrade.

[0037] The embodiments of the present invention can ensure that only legally authorized vehicles, supported by a trusted upgrade service system, and provided that the transmitted data has not been tampered with, can perform upgrade operations. This avoids the risk of the vehicle system being illegally flashed or maliciously upgraded, and effectively protects the vehicle's operational safety and the stable operation of the vehicle system.

[0038] For step S1, in some embodiments, both the vehicle-side digital certificate and the system-side digital certificate of the upgrade service system (hereinafter referred to as the OTA system) need to be applied for and issued through a Certificate Authority (CA) to build a complete PKI (Public Key Infrastructure) system and provide basic support for two-way identity authentication. The specific process is as follows: Both the vehicle-side and OTA systems submit certificate applications to a Certificate Authority (CA). The application materials must include the vehicle's own identity information. For example, the vehicle-side system must provide the vehicle's unique identification code, the model of the vehicle controller, and its own generated public key. The OTA system must provide the system's unique code, the service provider's qualifications, and its own generated public key.

[0039] After receiving an application, the Certificate Authority (CA) rigorously verifies the applicant's identity information. Upon successful verification, the CA integrates the applicant's public key, identity information, certificate validity period, and other relevant information, digitally signs this information using its own private key, generates a digital certificate, and issues it to the applicant. The certificate obtained by the vehicle is the vehicle-side digital certificate, and the certificate obtained by the OTA system is the system-side digital certificate. Both types of certificates contain the corresponding entity's public key, identity information, and CA digital signature, which can be used to verify the legitimacy of the identity in subsequent interactions, ensuring the authenticity and integrity of the certificate and preventing its forgery or tampering.

[0040] For illustration purposes, the public key generated on the vehicle side is PubCar and the private key is PriCar. After submitting a CA application, the obtained vehicle-side digital certificate includes PubCar, vehicle identification number, certificate validity period, and CA signature. The public key generated by the OTA system is PubOTA and the private key is PriOTA. The obtained system-side digital certificate includes PubOTA, OTA system code, certificate validity period, and CA signature.

[0041] Meanwhile, in the generation process of the first random number in this embodiment of the invention, an encrypted random number generation algorithm is used to ensure the randomness and unpredictability of the random number and avoid being guessed by attackers. For example, when the vehicle detects an upgrade prompt from the OTA system, such as receiving a prompt for "Vehicle navigation system V2.0 upgrade," it randomly generates a first random number R1 using an encrypted random number generation algorithm; optionally, R1 = 0x123456789ABCDEF0. The vehicle-side digital certificate is then encapsulated together with R1 into an authentication message. The encapsulation format follows the vehicle Ethernet SOME / IP protocol specification to ensure that the OTA system can parse it correctly.

[0042] This embodiment provides a reliable basis for identity authentication between the vehicle and the OTA system through a digital certificate issued by a CA, solving the problems of traditional technologies lacking standardized identity credentials and being easily forged. Furthermore, it generates the first random number through encrypted random number generation, providing a foundation for subsequent anti-replay attack and data encryption. At the same time, this embodiment of the invention simplifies the key management process. The vehicle and the OTA system do not need to exchange keys separately; they can complete secure interaction by simply obtaining each other's certificates, avoiding the complexity of symmetric key management.

[0043] For step S2, in some embodiments, to further improve the integrity of data transmission and prevent data from being tampered with, the encapsulated content of the response message further includes: a first hash value; wherein the first hash value is obtained by hashing the first random number and the second random number, and is encapsulated in the response message.

[0044] As an illustration, after receiving the authentication message sent by the vehicle, the OTA system first extracts the vehicle's digital certificate from the message and verifies its legality, such as verifying whether the CA signature is valid, whether the certificate is within its validity period, and whether the vehicle identification number is valid. After the verification is passed, a second random number is randomly generated using the same encryption-level random number generation algorithm as the vehicle. Optionally, R2=0x0FEDCBA987654321. Then, based on the vehicle's public key PubCar, the combined data of R1 and R2 is encrypted once, resulting in: Based on the previous R1=0x123456789ABCDEF0 and R2=0x0FEDCBA987654321, the combined data after encrypting the two can be: Enc1(Pub Car, R1+R2).

[0045] Simultaneously, the OTA system employs a hash algorithm to perform hash calculations on the combined data of R1 and R2, yielding a first hash value H1 = Hash(R1+R2) = 0xABCDEF1234567890. Subsequently, the system-side digital certificate, the encrypted data Enc1(PubCar, R1+R2), and the first hash value H1 are encapsulated together into a response message, which is returned to the vehicle according to the protocol specifications, completing the authentication response operation. Optionally, the SHA-256 hash algorithm can be used.

[0046] In this embodiment, each upgrade interaction generates a completely new random number. For example, the next upgrade will generate a completely different random number. The random number has the characteristics of being non-reusable, highly random, and unpredictable. Even if an attacker intercepts R1, R2, and encrypted data of this interaction, they cannot participate in the next upgrade interaction by replaying the data because the random number of the next interaction has been updated, and the decrypted data cannot pass the subsequent verification. This invention can block the implementation path of replay attacks.

[0047] As a component of encrypted data, the randomness of random numbers directly determines the difficulty of cracking the encryption. This embodiment employs an encryption-level random number generation algorithm to ensure that R1 and R2 cannot be guessed or predicted by attackers, thus preventing the encryption data from being cracked due to predictable random numbers. For example, if R1 and R2 were simple ordered values, attackers could easily guess and crack the encrypted data; however, in this embodiment, R1 and R2 are hexadecimal random strings, which, combined with the encryption-level algorithm, further increase the difficulty of cracking, ensuring the confidentiality of the encrypted data.

[0048] Furthermore, in step S3, in some embodiments, before performing a second encryption on the second random number after the first decryption based on the public key of the upgrade service system, the method further includes: A second hash value is obtained by performing a hash calculation based on the first random number obtained after the first decryption and the second random number obtained after the first decryption. Determine whether the second hash value is equal to the first hash value; If so, then continue with the second encryption operation; If not, the generation of the upgrade request message will be terminated, and the vehicle upgrade process will be terminated.

[0049] As an illustration, after receiving the response message, the vehicle first extracts the system-side digital certificate from the message and verifies its legality, such as verifying the validity of the CA signature, the validity period of the certificate, and the legality of the OTA system code. After the verification is successful, it decrypts the encrypted data Enc1(Pub Car, R1+R2) based on its own private key Pri Car. After successful decryption, it obtains a decrypted R1' and a decrypted R2'.

[0050] To verify that the decrypted data has not been tampered with, the vehicle uses the same hash algorithm as the OTA system to perform hash calculations on R1' and R2' after one decryption. To illustrate, the second hash value H2 = Hash(R1' + R2') is obtained and compared with H1 encapsulated in the response message. If H1 and H2 are equal, it means the decrypted data is complete and has not been tampered with, and the subsequent secondary encryption operation continues. If H1 and H2 are not equal, it means the data has been tampered with or replaced during transmission, and the generation of the upgrade request message is immediately terminated, as well as the current vehicle upgrade process, to prevent malicious data from entering subsequent stages.

[0051] After H1 and H2 pass the verification, the vehicle uses the OTA system's public key Pub OTA to perform a second encryption on the decrypted R2', obtaining the second-encrypted data Enc2(Pub OTA, R2'), and encapsulates this second-encrypted data into an upgrade request message, which is then sent to the OTA system.

[0052] In step S4, after receiving the upgrade request message, the OTA system decrypts the secondary encrypted data Enc2(Pub OTA, R2') based on its own private key Pri OTA. After successful decryption, R2'' is obtained. Then, the decrypted R2'' is encapsulated into an upgrade response message and returned to the vehicle, completing the two-way encryption and decryption interaction.

[0053] In this embodiment, by adding a hash value verification step, the integrity of data transmission is further guaranteed, solving the problem that traditional technologies rely solely on encryption without data integrity verification, making it easy for data to be tampered with without being detected. At the same time, this invention also combines two-way encryption and decryption with hash verification, forming dual protection of encryption and random number verification, further improving the security of upgrade interactions. In addition, through the application of the PKI system, key management is simplified. The vehicle and OTA systems do not need to maintain symmetric keys separately; they can obtain each other's public keys simply through CA certificates, reducing the risk of key leakage and cumbersome management.

[0054] In a preferred embodiment, after H1 and H2 pass the verification, the vehicle-side device uses the public key Pub OTA of the OTA system to perform secondary encryption on the decrypted R2' to obtain the secondary encrypted data Enc2(Pub OTA, R2'), and calculates the hash value of R2'. Then, the hash value of R2' and the secondary encrypted data are encapsulated into an upgrade request message and sent to the OTA system.

[0055] After successfully decrypting R2'' using its private key, the OTA system calculates the hash value of R2'' and compares it with the hash value of R2' in the upgrade request message sent by the vehicle. If they are equal, the OTA system verifies the vehicle's identity and can then send upgrade data to the vehicle. Upon receiving the upgrade data, the vehicle uses the OTA system's public key to verify the data, ensuring its integrity and authenticity.

[0056] For step S5, in some embodiments, the encapsulated content of the upgrade response message includes: a third hash value; wherein the third hash value is obtained by hashing the second random number after secondary decryption and is encapsulated in the upgrade response message; Then, the second random number decrypted twice in the upgrade response message is compared with the second random number decrypted once locally. Upon successful verification, a data delivery request is sent to the upgrade service system, including: The second random number, after being decrypted locally once, is hashed to obtain the fourth hash value; When the fourth hash value is determined to be equal to the third hash value in the upgrade response message, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

[0057] After obtaining the fourth hash value, the embodiments of the present invention further include: If the fourth hash value is determined to be different from the third hash value in the upgrade response message, an incomplete consistency verification result is generated, the operation of sending the data delivery request is terminated, and the vehicle upgrade process is terminated.

[0058] Indicatively, in step S4, the OTA system decrypts the second-encrypted data a second time to obtain the decrypted R2''. Then, it uses the SHA-256 hash algorithm to perform hash calculation on R2'', obtaining a third hash value H3=Hash(R2). Finally, the decrypted R2'' and H3 are encapsulated together as an upgrade response message and returned to the vehicle.

[0059] In step S5, after receiving the upgrade response message, the vehicle first extracts the third hash value H3=Hash(R2), and at the same time calls the locally stored R2' which has been decrypted once in step S3, and performs SHA-256 hash calculation on the locally decrypted R2' to obtain the fourth hash value H4=Hash(R2).

[0060] The vehicle compares H4 with H3 encapsulated in the upgrade response message. If H4 and H3 are equal, it means that R2'' in the upgrade response message is consistent with the R2' decrypted locally, and the data has not been tampered with. The consistency verification is then completed, and a data delivery request is sent to the OTA system. If H4 and H3 are not equal, it means that R2'' in the upgrade response message has been tampered with or replaced. Immediately generate a result that has not completed the consistency verification, terminate the data distribution request sending operation, and terminate this vehicle upgrade process, thereby blocking the subsequent spread of malicious data.

[0061] This embodiment further enhances the accuracy of data consistency verification by performing hash verification on R2'' again. At the same time, it echoes the hash verification in step S3, constructing a full-process hash verification, effectively preventing illegal acts such as data tampering, further improving the security of the upgrade process, and solving the defect of weak anti-attack capability of traditional technology.

[0062] In some embodiments, to further enhance the rigor of consistency verification and address the risk of data tampering in complex network environments, both the first random number generated by the vehicle and the second random number generated by the OTA system are composed of several binary bits.

[0063] Furthermore, the encapsulated content of the upgrade response message generated by the OTA system actually includes the data content after processing the second random number, which is: the first mask sequence corresponding to the second random number after secondary decryption, the first data block feature value, and the tail node of the first one-way hash chain; Wherein, the first mask sequence is an ordered set composed of the results of bitwise AND operation between each first data block and the first mask factor after the upgrade service system divides the second random number after secondary decryption into blocks according to a preset byte unit; the feature value of the first data block is the result of the upgrade service system performing continuous bitwise XOR operation on all first data blocks; the tail node of the first one-way hash chain is the final result generated by the upgrade service system performing successive XOR calculations with the first data block based on a preset starting value; Understandably, the OTA system processes the second random number R2'' after secondary decryption in order to transform the single random number into three types of data with multiple dimensions and fine-grained verification capabilities, such as the first mask sequence, the first data block feature value, and the tail node of the first one-way hash chain. This improves the rigor of subsequent vehicle-side consistency verification and addresses security risks in complex network environments.

[0064] The overall processing logic of the OTA system can be as follows: First, the second random number is divided into blocks according to preset rules. Then, based on the block results, masking operation, feature extraction and hash chain calculation are performed respectively to finally generate three types of verification data, which are encapsulated in the upgrade response message to provide the vehicle with multi-dimensional verification basis.

[0065] The process of the vehicle end verifying the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally, and sending a data delivery request to the upgrade service system after successful verification, specifically includes: The second random number, which is decrypted locally once, is divided into several second data blocks based on a preset byte unit. Each second data block corresponds to a number, and the numbers are arranged in ascending order of the splitting sequence. Extract a preset number of target binary bits from the second random number after local decryption, and perform an XOR operation on the target binary bits and a preset fixed value to generate a second mask factor; wherein, the preset number is less than the total number of binary bits in the second random number after local decryption; the generation rule of the first mask factor is the same as the generation rule of the second mask factor. Perform a bitwise AND operation on each bit of the second data block with the second mask factor, and arrange the AND operation results of all the second data blocks into an ordered set according to their numbering order. Output the second mask sequence corresponding to the second random number after local decryption. Perform a continuous bitwise XOR operation on all the second data blocks to generate the feature value of the second data block; The preset starting value is used as the first node of the second one-way hash chain. The preset starting value is XORed with the second data block with the smallest number, and the intermediate hash value corresponding to the second data block with the smallest number is output. Then, each second data block is processed one by one in ascending order of number. The intermediate hash value corresponding to the previous second data block is XORed with the current second data block, and the intermediate hash value corresponding to the current second data block is output. This process continues until the second data block with the largest number is processed. The intermediate hash value corresponding to the second data block with the largest number is used as the tail node of the second one-way hash chain. When it is determined that the first mask sequence and the second mask sequence are equal element by element, the first data block feature value and the second data block feature value are equal, and the tail node of the first one-way hash chain is equal to the tail node of the second one-way hash chain, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

[0066] Furthermore, after generating the second mask sequence, the second data block feature value, and the tail node of the second one-way hash chain, embodiments of the present invention may further include: If it is determined that the first mask sequence and the second mask sequence are not equal element by element, or the first data block feature value and the second data block feature value are not equal, or the tail node of the first one-way hash chain and the tail node of the second one-way hash chain are not equal, then a result indicating incomplete consistency verification is generated, the operation of sending the data delivery request is terminated, and the current vehicle upgrade process is terminated.

[0067] Indicatively, in this embodiment of the invention, the processing procedure on the OTA system side can be as follows: The preset byte unit is obtained, which is 4 bytes (32 bits). The OTA system divides the decrypted R2'' (0x0FEDCBA987654321) into 4-byte blocks to obtain two first data blocks; optionally, first data block 1 (number 1) = 0x0FEDCBA9 and first data block 2 (number 2) = 0x87654321. Extract the first 8 bits (preset number is 8) from the 64-bit binary of R2'', i.e. 00001111, and XOR it with the preset fixed value 01010101 to obtain the first mask factor = 01011010; Perform a bitwise AND operation between the first data block 1 and the first data block 2 and the first mask factor respectively. The result of the AND operation between the first data block 1 and the first data block 2 is 0x0FEDCBA9&0x5A=0x0A. The result of the AND operation between the first data block 2 and the first data block 2 is 0x87654321&0x5A=0x42. Then, the first mask sequence can be formed in the order of the numbers as [0x0A, 0x42]. Performing a series of bitwise XOR operations on the first data block 1 and the first data block 2, the characteristic value of the first data block can be: 0x0FEDCBA9 ^ 0x87654321=0x88888888; Set the preset starting value to 0x00000000 and the first node to 0x00000000; XOR the first node with the first data block 1 to get the intermediate hash value 1 = 0x00000000 ^ 0x0FEDCBA9 = 0x0FEDCBA9; XOR the intermediate hash value 1 with the first data block 2 to get the first one-way hash chain tail node = 0x0FEDCBA9 ^ 0x87654321 = 0x88888888; Furthermore, after obtaining the above three types of data, the OTA system encapsulates the decrypted R2'', the first mask sequence [0x0A, 0x42], the first data block feature value 0x88888888, and the first one-way hash chain tail node 0x88888888 together into an upgrade response message and returns it to the vehicle.

[0068] The processing procedure for the vehicle end side is as follows: The vehicle-side processing of the second mask sequence, the second data block feature value, and the tail node of the second one-way hash chain is consistent with the rules of the OTA system when generating the first mask sequence, the first data block feature value, and the tail node of the first one-way hash chain. Specifically, the vehicle terminal can divide the second random number after local decryption into 4-byte blocks to obtain two second data blocks: second data block 1 and second data block 2 (number 2). Following the same rules as the first mask factor, the first 8 bits are extracted from the second random number after local decryption, and XORed with a preset fixed value to obtain the second mask factor; Perform bitwise AND operations between the second data block 1 and the second data block 2 and the second mask factor respectively, and then arrange the results into the second mask sequence according to the number order. Perform a continuous bitwise XOR operation on the second data block 1 and the second data block 2 on the characteristic value of the second data block; Get the preset starting value = 0x00000000 (consistent with the OTA system), then obtain the corresponding first node; XOR the first node with the second data block 1 to obtain the corresponding intermediate hash value, and then XOR the obtained intermediate hash value with the second data block 2 to obtain the tail node of the second one-way hash chain; The vehicle compares the first mask sequence with the second mask sequence element by element, compares the feature value of the first data block with the feature value of the second data block, and compares the tail node of the first one-way hash chain with the tail node of the second one-way hash chain. If all three are found to be the same, the consistency verification is deemed successful, and a data delivery request is sent to the OTA system.

[0069] If any comparison item is not equal, such as if the first mask sequence is different, an incomplete consistency verification result is generated, the data delivery request is terminated, and the upgrade process is terminated.

[0070] Therefore, in this embodiment, by using the triple verification of the mask sequence, data block feature value, and one-way hash chain tail node, data tampering behavior can be identified more accurately, such as partial byte tampering or data block order tampering, which can further improve the anti-attack capability and ensure the integrity and authenticity of the upgrade response message.

[0071] In some embodiments, to further prevent replay attacks and avoid attackers from intercepting the upgrade response message and replaying it at different times to bypass verification, the encapsulation content of the upgrade response message may also include: a server-side timestamp generated by the upgrade service system; Therefore, after the vehicle completes the consistency verification but before sending a data delivery request to the upgrade service system, the method further includes: Obtain the local current timestamp and calculate the time difference between the local current timestamp and the server timestamp; If the time difference is determined to be within a preset valid time window, the operation of sending a data delivery request to the upgrade service system will continue. If the time difference is determined to exceed the preset valid time window, a timing verification failure result is generated, and the vehicle upgrade process is terminated.

[0072] The illustrative, specific implementation process is as follows: In step S4, when the OTA system generates an upgrade response message, it synchronously generates a server-side timestamp, such as 2024-05-20 14:30:00.123. This server-side timestamp, along with the decrypted 2'' and hash value (or verification information such as mask sequence), is encapsulated in the upgrade response message and returned to the vehicle.

[0073] After the vehicle completes the consistency verification, such as passing the hash check or triple check, it obtains the local current timestamp, such as 2024-05-20 14:30:00.156, and then calculates the time difference between the two: 00:00:00.033, which gives a time difference of 33 milliseconds.

[0074] At this point, the preset effective time window is limited to 50 milliseconds. In practice, it can be adjusted according to the latency characteristics of vehicle communication. Since 33 milliseconds is within the effective time window of 50 milliseconds, the timing verification is deemed to be successful, and the operation of sending a data transmission request to the OTA system continues. If the local current timestamp is 2024-05-20 14:30:00.200, the time difference is 77 milliseconds, which exceeds the preset valid time window, then a timestamp verification failure result will be generated, and the current vehicle upgrade process will be terminated immediately.

[0075] This embodiment further improves the anti-replay attack mechanism by adding time stamp verification. Since the server time stamp is updated in real time, the server time stamp contained in the upgrade response message intercepted by the attacker will exceed the valid time window over time. Even if the consistency verification passes, the time stamp verification will fail. Thus, this invention can further improve the security of remote vehicle upgrades.

[0076] In summary, the first and second random numbers used in each authentication process are generated exclusively for each instance, and are verified in conjunction with time stamps. Attackers cannot bypass the authentication mechanism by intercepting and replaying authentication messages or upgrade response messages. Even if an attacker intercepts the relevant messages, due to the uniqueness of the random numbers and the timeliness of the time stamps, the replayed messages will fail in hash verification, consistency verification, or time stamp verification, thus effectively preventing replay attacks.

[0077] Furthermore, this invention enables the vehicle and OTA systems to verify each other's identities through two-way digital certificate mutual verification, combined with processes such as random number encryption and hash verification. This ensures that both parties are legitimate communication entities and effectively prevents the risk of unauthorized vehicles accessing the upgrade system or impersonating the OTA system to issue malicious commands.

[0078] In this invention, the use of the PKI system enables the vehicle-side and OTA system to communicate and authenticate securely simply by obtaining each other's public key certificates through the CA, without the need for separate exchange and maintenance of symmetric keys. The distribution and management of public key certificates are relatively simple, and the authenticity and integrity of the certificates are guaranteed by the CA's digital signature, avoiding the problems of complex and easily leaked symmetric key management.

[0079] Therefore, this invention uses mechanisms such as dual asymmetric encryption, multiple hash verification, mask sequence and hash chain verification to ensure that data during the upgrade process is not intercepted, cracked or tampered with; at the same time, each verification step is equipped with a termination mechanism, and the upgrade process is terminated immediately if the verification fails, thus ensuring that the vehicle system is not illegally flashed or maliciously upgraded from the whole process, and ensuring the safety of vehicle operation and the stability of the vehicle system.

[0080] Please see Figure 2This application also provides a vehicle upgrade device based on two-way authentication, which can implement the above-described vehicle upgrade method based on two-way authentication. The device includes: The authentication message encapsulation module 601 is used to randomly generate a first random number when an upgrade prompt is detected by the upgrade service system, and then encapsulate the vehicle-side digital certificate corresponding to the vehicle and the first random number into an authentication message. The authentication message sending module 602 is used to send the authentication message to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After the verification is successful, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the public key of the vehicle. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. The response message decryption module 603 is used to verify the legality of the system-side digital certificate in the response message. After the verification is successful, it decrypts the combined data encrypted once in the response message based on the private key corresponding to the vehicle, and generates a first random number and a second random number after decryption. It then encrypts the second random number after decryption a second time based on the public key of the upgrade service system, and encapsulates the second random number after decryption a second time into an upgrade request message. The upgrade request message sending module 604 is used to send the upgrade request message to the upgrade service system, so that the upgrade service system can perform a second decryption on the second random number encrypted twice in the upgrade request message based on the private key of the upgrade service system, encapsulate the second random number after the second decryption into an upgrade response message, and return the upgrade response message. The consistency verification module 605 is used to verify the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally. After the verification is successful, it sends a data delivery request to the upgrade service system. When the upgrade service system delivers the data to be upgraded, it upgrades the vehicle function corresponding to the data to be upgraded.

[0081] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0082] It should be noted that the device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0083] Those skilled in the art will clearly understand that, for convenience and simplicity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0084] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned vehicle upgrade method based on two-way authentication. This electronic device can include any smart terminal such as a tablet computer or an in-vehicle computer.

[0085] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0086] Please see Figure 3 , Figure 3 This illustrates the hardware structure of an electronic device according to another embodiment, the electronic device comprising: The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 702 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 702 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this application are implemented through software or firmware, the relevant program code is stored in the memory 702 and is called and executed by the processor 701. The input / output interface 703 is used to implement information input and output; The communication interface 704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.). Bus 705 transmits information between various components of the device (e.g., processor 701, memory 702, input / output interface 703, and communication interface 704); The processor 701, memory 702, input / output interface 703 and communication interface 704 are connected to each other within the device via bus 705.

[0087] The processor 701 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. This processor is the control center of the terminal device, connecting various parts of the terminal device via various interfaces and lines.

[0088] The memory 702 can be used to store the computer program. The processor implements various functions of the terminal device by running or executing the computer program stored in the memory and calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device or other volatile solid-state storage device.

[0089] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described vehicle upgrade method based on two-way authentication.

[0090] It is understood that the content of the above method embodiments is applicable to the present computer storage medium embodiments. The specific functions implemented by the present computer storage medium embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0091] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described vehicle upgrade method based on two-way authentication.

[0092] It is understood that the content of the above method embodiments is applicable to the embodiments of this computer program product. The specific functions implemented by the embodiments of this computer program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0093] Those skilled in the art will understand that all or some of the steps, apparatuses, or functional modules / units in the methods disclosed above can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0094] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A vehicle upgrade method based on two-way authentication, characterized in that, The method includes: When an upgrade prompt is detected from the upgrade service system, a first random number is randomly generated, and then the vehicle-side digital certificate corresponding to the vehicle and the first random number are encapsulated into an authentication message. The authentication message is sent to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After the verification is successful, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the vehicle's public key. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. Verify the legitimacy of the system-side digital certificate in the response message. After successful verification, decrypt the combined data encrypted once in the response message based on the private key corresponding to the vehicle to generate a first decrypted random number and a second decrypted random number. Encrypt the second decrypted random number a second time based on the public key of the upgrade service system, and encapsulate the second decrypted random number into an upgrade request message. The upgrade request message is sent to the upgrade service system, so that the upgrade service system decrypts the second random number, which is encrypted twice in the upgrade request message, based on the private key of the upgrade service system, encapsulates the second random number after decryption twice into an upgrade response message, and returns the upgrade response message. The second random number decrypted twice in the upgrade response message is verified to be consistent with the second random number decrypted once locally. After the verification is successful, a data delivery request is sent to the upgrade service system. When the upgrade service system delivers the data to be upgraded, the vehicle function corresponding to the data to be upgraded is upgraded.

2. The vehicle upgrade method based on two-way authentication according to claim 1, characterized in that, The encapsulated content of the response message further includes: a first hash value; wherein the first hash value is obtained by hashing the first random number and the second random number, and is encapsulated in the response message; Before performing a second encryption on the second random number obtained from the first decryption based on the public key of the upgrade service system, the method further includes: A second hash value is obtained by performing a hash calculation based on the first random number obtained after the first decryption and the second random number obtained after the first decryption. Determine whether the second hash value is equal to the first hash value; If so, then continue with the second encryption operation; If not, the generation of the upgrade request message will be terminated, and the vehicle upgrade process will be terminated.

3. The vehicle upgrade method based on two-way authentication according to claim 2, characterized in that, The encapsulated content of the upgrade response message includes: a third hash value; wherein the third hash value is obtained by hashing the second random number after secondary decryption and is encapsulated in the upgrade response message; The step of verifying the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally, and sending a data delivery request to the upgrade service system after successful verification, includes: The second random number, after being decrypted locally once, is hashed to obtain the fourth hash value; When the fourth hash value is determined to be equal to the third hash value in the upgrade response message, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

4. The vehicle upgrade method based on two-way authentication according to claim 3, characterized in that, After deriving the fourth hash value, the method further includes: If the fourth hash value is determined to be different from the third hash value in the upgrade response message, an incomplete consistency verification result is generated, the operation of sending the data delivery request is terminated, and the vehicle upgrade process is terminated.

5. The vehicle upgrade method based on two-way authentication according to claim 1, characterized in that, The second random number consists of several binary bits; the encapsulated content of the upgrade response message includes: the first mask sequence corresponding to the second random number after secondary decryption, the first data block feature value, and the tail node of the first one-way hash chain; The step of verifying the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally, and sending a data delivery request to the upgrade service system after successful verification, includes: The second random number, which is decrypted locally once, is divided into several second data blocks based on a preset byte unit. Each second data block corresponds to a number, and the numbers are arranged in ascending order of the splitting sequence. Extract a preset number of target binary bits from the second random number after local decryption, and perform an XOR operation on the target binary bits and a preset fixed value to generate a second mask factor; wherein, the preset number is less than the total number of binary bits in the second random number after local decryption; the generation rule of the first mask factor is the same as the generation rule of the second mask factor. Perform a bitwise AND operation on each bit of the second data block with the second mask factor, and arrange the AND operation results of all the second data blocks into an ordered set according to their numbering order. Output the second mask sequence corresponding to the second random number after local decryption. Perform a continuous bitwise XOR operation on all the second data blocks to generate the feature value of the second data block; The preset starting value is used as the first node of the second one-way hash chain. The preset starting value is XORed with the second data block with the smallest number, and the intermediate hash value corresponding to the second data block with the smallest number is output. Then, each second data block is processed one by one in ascending order of number. The intermediate hash value corresponding to the previous second data block is XORed with the current second data block, and the intermediate hash value corresponding to the current second data block is output. This process continues until the second data block with the largest number is processed. The intermediate hash value corresponding to the second data block with the largest number is used as the tail node of the second one-way hash chain. When it is determined that the first mask sequence and the second mask sequence are equal element by element, the first data block feature value and the second data block feature value are equal, and the tail node of the first one-way hash chain is equal to the tail node of the second one-way hash chain, the consistency verification is completed, and then a data delivery request is sent to the upgrade service system.

6. The vehicle upgrade method based on two-way authentication according to claim 5, characterized in that, After generating the second mask sequence, the second data block feature value, and the tail node of the second one-way hash chain, the method further includes: If it is determined that the first mask sequence and the second mask sequence are not equal element by element, or the first data block feature value and the second data block feature value are not equal, or the tail node of the first one-way hash chain and the tail node of the second one-way hash chain are not equal, then a result indicating incomplete consistency verification is generated, the operation of sending the data delivery request is terminated, and the current vehicle upgrade process is terminated.

7. The vehicle upgrade method based on two-way authentication according to claim 6, characterized in that, The encapsulated content of the upgrade response message also includes: the server-side timestamp generated by the upgrade service system; After completing the consistency verification but before sending the data delivery request to the upgrade service system, the method further includes: Obtain the local current timestamp and calculate the time difference between the local current timestamp and the server timestamp; If the time difference is determined to be within a preset valid time window, the operation of sending a data delivery request to the upgrade service system will continue. If the time difference is determined to exceed the preset valid time window, a timing verification failure result is generated, and the vehicle upgrade process is terminated.

8. A vehicle upgrade device based on two-way authentication, characterized in that, The device includes: The authentication message encapsulation module is used to randomly generate a first random number when an upgrade prompt is detected from the upgrade service system, and then encapsulate the vehicle-side digital certificate corresponding to the vehicle and the first random number into an authentication message. The authentication message sending module is used to send the authentication message to the upgrade service system so that the upgrade service system can verify the legality of the vehicle-side digital certificate. After the verification is successful, a second random number is randomly generated, and the combination of the first random number and the second random number is encrypted once based on the public key of the vehicle. The system-side digital certificate corresponding to the upgrade service system and the encrypted combination data are encapsulated into a response message and the response message is returned. The response message decryption module is used to verify the legitimacy of the system-side digital certificate in the response message. After successful verification, it decrypts the combined data encrypted once in the response message based on the private key corresponding to the vehicle, generating a first decrypted random number and a second decrypted random number. Based on the public key of the upgrade service system, it performs a second encryption on the second decrypted random number and encapsulates the second encrypted random number into an upgrade request message. The upgrade request message sending module is used to send the upgrade request message to the upgrade service system, so that the upgrade service system can decrypt the second random number that has been encrypted twice in the upgrade request message based on the private key of the upgrade service system, encapsulate the second random number that has been decrypted twice into an upgrade response message, and return the upgrade response message. The consistency verification module is used to verify the consistency between the second random number decrypted twice in the upgrade response message and the second random number decrypted once locally. After the verification is successful, it sends a data delivery request to the upgrade service system. When the upgrade service system delivers the data to be upgraded, it upgrades the vehicle function corresponding to the data to be upgraded.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements a vehicle upgrade method based on two-way authentication as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements a vehicle upgrade method based on two-way authentication as described in any one of claims 1 to 7.

Images