Method and device for flashing upgrade package of vehicle

By performing vulnerability scanning, encryption, and signature processing on vehicle upgrade packages, combined with hash value verification, the problem of upgrade packages being tampered with during vehicle software upgrades was solved, thus improving the security and reliability of vehicle software upgrades.

CN121501307APending Publication Date: 2026-02-10LIUZHOU WULING NEW ENERGY VEHICLE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511541886.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-10-27
Publication Date
2026-02-10

AI Technical Summary

Technical Problem

Vehicle software upgrades are susceptible to issues such as tampering with upgrade packages and uneven protection across different scenarios, particularly with security vulnerabilities associated with OTA, OBD, and USB upgrade methods.

Method used

After performing vulnerability scanning on the upgrade package uploaded by the supplier, it is encrypted using a random key and signed using a hash algorithm and PKI system to form an encrypted upgrade package. The certificate chain verification and hash value verification are then performed on the master node to ensure the integrity and legitimacy of the upgrade package.

Benefits of technology

It improves the security of vehicle software upgrades, prevents man-in-the-middle attacks and malicious tampering, ensures the confidentiality and integrity of upgrade packages, and enables reliable updates in multiple scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121501307A_ABST
    Figure CN121501307A_ABST
Patent Text Reader

Abstract

The invention provides a method and a device for flashing an upgrade package of a vehicle, and relates to the technical field of vehicles, in response to the condition that a supplier passes multiple authentications, vulnerability scanning is performed on the upgrade package uploaded by the supplier, if the vulnerability scanning is not abnormal, encryption processing is performed on the upgrade package through a random secret key to obtain encrypted upgrade content, and the encrypted upgrade content is sent to the vehicle. The upgrade package and the random secret key are signed based on a Hash algorithm and a PKI system to obtain an abstract value, an encryption secret key and an upgrade package certificate; transmitting an encrypted upgrade package formed by combining the encrypted upgrade content, the abstract value, the encryption key and the upgrade package certificate to a main node corresponding to the upgrade scene, so that the main node performs certificate chain verification based on a preset root certificate and the upgrade package certificate; and if the hash algorithm verifies that the corresponding first hash value after the abstract value is unsigned is consistent with the second hash value corresponding to the original upgrading content, executing upgrading. Therefore, reliable updating of the vehicle system in a complex upgrading environment is guaranteed.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method and apparatus for flashing and upgrading vehicle upgrade packages. Background Technology

[0002] Vehicle software upgrades can be performed in various ways, such as over-the-air (OTA) updates, OBD interfaces, and USB, but these methods present certain security risks. For example, OTA upgrades are vulnerable to man-in-the-middle attacks; OBD upgrades rely on physical security assumptions that are easily compromised; and USB upgrades allow the USB medium to become a carrier of malicious code. Therefore, vehicle software upgrades are prone to issues such as upgrade package tampering and uneven protection across different scenarios. Summary of the Invention

[0003] In view of this, this application provides a method and apparatus for flashing upgrade packages for vehicles, aiming to improve the security of software upgrades.

[0004] Firstly, this application provides a method for flashing an upgrade package onto a vehicle, the method comprising:

[0005] In response to the supplier passing multiple certifications, vulnerability scans are performed on the upgrade packages uploaded by the supplier.

[0006] If the vulnerability scan finds no abnormalities, the upgrade package is encrypted using a random key to obtain the encrypted upgrade content. The upgrade package and the random key are then signed using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate.

[0007] The encrypted upgrade package, consisting of the merged encrypted upgrade content, digest value, encryption key, and upgrade package certificate, is transmitted to the master node corresponding to the upgrade scenario. The master node performs certificate chain verification based on the preset root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the designed digest value and the second hash value corresponding to the original upgrade content are consistent. If they are consistent, the upgrade is performed based on the original upgrade content, which is the content obtained by decrypting the encrypted upgrade content using the encryption key.

[0008] Optionally, the response to the supplier passing multiple authentications, performing a vulnerability scan on the upgrade package uploaded by the supplier, includes:

[0009] In response to the supplier's two-factor authentication through the OTA management platform, the system obtains the upgrade package uploaded by the supplier and performs a vulnerability scan on the upgrade package; wherein, the two-factor authentication includes U-shield authentication, the supplier's U-shield is provided by the OTA management platform and has minimal authorized functions for the supplier.

[0010] Optionally, the step of encrypting the upgrade package using a random key to obtain encrypted upgrade content, and then signing the upgrade package and the random key based on a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate, includes:

[0011] The upgrade package is encrypted using a random key and an encryption algorithm to obtain the encrypted upgrade content;

[0012] The upgrade package is hashed using a hash algorithm to obtain a first hash value;

[0013] Apply for a certificate private key, certificate public key, and upgrade package certificate from the PKI system;

[0014] The digest value is obtained by signing the first hash value with the certificate private key;

[0015] The random key is signed using the certificate's public key to obtain the encryption key.

[0016] Optionally, in the case of an OTA upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: transmitting the encrypted upgrade package to the TBOX via a bidirectional link between the OTA operation platform and the SDK in the TBOX;

[0017] In the case of a USB upgrade, the encrypted upgrade package is transmitted to the master node corresponding to the upgrade scenario, including: downloading it to the transmission medium through the OTA operation platform and transmitting it to the vehicle host HU through the transmission medium;

[0018] In the case of an OBD upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: pushing the encrypted upgrade package to the diagnostic platform, and transmitting the encrypted upgrade package to the diagnostic instrument through a bidirectional link between the diagnostic platform and the diagnostic instrument.

[0019] Optionally, before verifying the upgrade package certificate based on the preset root certificate, the method further includes:

[0020] The master node requests a terminal certificate and a decryption private key from the PKI system, and uses the terminal certificate as the pre-set root certificate.

[0021] Optionally, the steps for obtaining the original upgrade content include:

[0022] The encryption key is decrypted using the decryption private key to obtain a random key;

[0023] The encrypted upgrade content is decrypted based on the encryption algorithm and the random key to obtain the original upgrade content.

[0024] Optionally, the step of verifying whether the first hash value corresponding to the decrypted digest value and the second hash value corresponding to the original upgrade content are consistent based on the hash algorithm, and if they are consistent, then performing the upgrade based on the original upgrade content, includes:

[0025] The digest value is designed using the public key of the upgrade package certificate to obtain the first hash value;

[0026] The original upgrade content is hashed using a hash algorithm to obtain a second hash value;

[0027] If the first hash value matches the second hash value, then the upgrade is performed based on the original upgrade content.

[0028] Optionally, in the case of an OTA upgrade or an OBD upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes:

[0029] The encrypted upgrade package and upgrade instructions are transmitted to the master node corresponding to the upgrade scenario. The upgrade instructions are used to instruct the target controller to be upgraded.

[0030] Optionally, the upgrade based on the original upgrade content includes:

[0031] In the case of an OTA upgrade, if the target controller does not include a TBOX, the TBOX transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a TBOX, the TBOX performs a self-upgrade based on the original upgrade content and transmits the original upgrade content to a first controller to upgrade the first controller, where the first controller is the target controller other than the TBOX.

[0032] In the case of a USB upgrade, the vehicle-mounted unit (HU) performs a self-upgrade based on the original upgrade content.

[0033] In the case of an OBD upgrade, if the target controller does not include a diagnostic tool, the diagnostic tool transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a diagnostic tool, the diagnostic tool performs a self-upgrade based on the original upgrade content, and accesses the gateway through the 27 service to upgrade the gateway and the second controller based on the original upgrade content, wherein the second controller is another controller of the target controller besides the diagnostic tool.

[0034] Secondly, this application provides an apparatus for flashing an upgrade package onto a vehicle, the apparatus comprising:

[0035] The scanning module is used to perform vulnerability scanning on the upgrade packages uploaded by suppliers in response to suppliers passing multiple certifications.

[0036] The encryption module is used to encrypt the upgrade package with a random key to obtain encrypted upgrade content if the vulnerability scan shows no abnormalities, and to sign the upgrade package and the random key based on a hash algorithm and a PKI system to obtain a digest value, an encryption key and an upgrade package certificate.

[0037] The upgrade module transmits an encrypted upgrade package, consisting of merged encrypted upgrade content, a digest value, an encryption key, and an upgrade package certificate, to the master node corresponding to the upgrade scenario. The master node performs a certificate chain verification based on a pre-set root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the digest value and the second hash value corresponding to the original upgrade content are consistent. If they are consistent, the upgrade is performed based on the original upgrade content, which is obtained by decrypting the encrypted upgrade content using the encryption key.

[0038] Thirdly, this application provides an apparatus comprising a memory and a processor, the memory for storing instructions or code, and the processor for executing the instructions or code to cause the apparatus to perform a method for flashing an upgrade package for a vehicle as described in any of the first aspects above.

[0039] Fourthly, this application provides a computer storage medium storing code, wherein when the code is executed, a device running the code implements a method for flashing an upgrade package for a vehicle as described in any of the first aspects above.

[0040] This application provides a method and apparatus for flashing upgrade packages for vehicles. First, in response to multiple successful authentications by the supplier, a vulnerability scan is performed on the upgrade package uploaded by the supplier. Then, if the vulnerability scan finds no anomalies, the upgrade package is encrypted using a random key to obtain encrypted upgrade content. The upgrade package and the random key are then signed using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate. Finally, the encrypted upgrade package, formed by merging the encrypted upgrade content, digest value, encryption key, and upgrade package certificate, is transmitted to the master node corresponding to the upgrade scenario. The master node performs certificate chain verification based on a pre-set root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the de-signed digest value matches the second hash value corresponding to the original upgrade content. If they match, the upgrade is performed based on the original upgrade content, which is obtained by decrypting the encrypted upgrade content using the encryption key. In this way, the application ensures the authenticity of the supplier's identity and the security of the code through login legitimacy authentication and vulnerability scanning of the upgrade package during upload. Furthermore, the upgrade package is encrypted and signed before being transmitted to the master node, ensuring confidentiality during transmission. Subsequently, the master node decrypts and unsigns the package, along with hash value verification, to ensure the integrity of the upgrade package before and after transmission, effectively resisting man-in-the-middle attacks, malicious tampering, and unauthorized injection. In addition, digital signature verification is implemented through a PKI system to prevent forged certificates and key leaks, while the dynamic generation of random keys enhances the unpredictability of encryption. The master node's multi-layered verification process ensures that the flashing operation is only allowed after all security verifications have passed, significantly improving the security of vehicle upgrades in various scenarios and guaranteeing reliable updates to the vehicle system in complex upgrade environments. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 A flowchart illustrating a method for flashing an upgrade package for a vehicle, provided in an embodiment of this application;

[0043] Figure 2 This is a schematic diagram illustrating an encryption and signature process provided in an embodiment of this application.

[0044] Figure 3 This application provides a schematic diagram of the transmission process for uploading to the master node on an OTA operation platform.

[0045] Figure 4 A schematic diagram illustrating a decryption and designing process provided in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of a device for flashing and upgrading vehicle upgrade packages, provided in an embodiment of this application. Detailed Implementation

[0047] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0048] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0049] Unless otherwise stated, the term "multiple" means two or more. In embodiments of this disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B. The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0051] See Figure 1 , Figure 1 This is a flowchart illustrating a method for flashing an upgrade package for a vehicle, as provided in an embodiment of this application. The method includes:

[0052] S101. In response to the supplier passing multiple certifications, perform vulnerability scanning on the upgrade package uploaded by the supplier.

[0053] Optionally, the above authentication methods can be two-factor authentication. Two-factor authentication (2FA) is an authentication method that requires users to provide two different types of proof, such as a USB key and a password, to improve account security.

[0054] The aforementioned USB Key is a physical hardware security device used to store digital certificates and private keys, serving as a key carrier for achieving strong authentication and digital signatures.

[0055] The aforementioned vulnerability scanning uses automated tools to perform static or dynamic analysis on software packages to detect the presence of known security vulnerabilities (such as high-risk vulnerabilities), malicious code, or compliance issues.

[0056] The vulnerability scan results will serve as a crucial basis for the upgrade package to proceed with subsequent processes. Upgrade packages that fail the scan will be automatically blocked, and the OEM user will return the upgrade package and provide feedback to the vendor regarding the anomaly and relevant remediation suggestions. Subsequently, after the vendor completes the remediation, they can log in again to upload the upgrade package. Once the scan passes, the upgrade package will proceed to the next stage of the process.

[0057] Thus, step S101 above uses two-factor authentication and a USB key to perform strong identity authentication for suppliers, and combines this with vulnerability scanning to filter risks from both personnel entry points and software sources.

[0058] S102. If the vulnerability scan shows no abnormalities, the upgrade package is encrypted using a random key to obtain the encrypted upgrade content. The upgrade package and the random key are then signed using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate.

[0059] The aforementioned random key is randomly generated by the OTA management platform.

[0060] Optionally, the above encryption process can employ the AES-128 algorithm to encrypt the upgrade package, ensuring the confidentiality and integrity of the data during transmission. The AES-128 algorithm is a symmetric encryption algorithm that uses a 128-bit random key to encrypt and decrypt data, guaranteeing data confidentiality.

[0061] The aforementioned PKI (Public Key Infrastructure) system is a general term for a system that provides public key encryption and digital signature services, and is responsible for managing the lifecycle of keys and certificates, including generation, distribution, and revocation.

[0062] The aforementioned signing process involves encrypting the hash value of the data using the sender's private key to generate a digest value (Signature), which is used by the recipient to verify the authenticity and integrity of the data source.

[0063] The signing process, step S102, involves encrypting the hash value of the upgrade package using a private key to generate a digital signature, ensuring data integrity and credible origin. When uploading the upgrade package, the supplier must use the private key stored in their uniquely bound USB key to perform the signing operation. The OTA management platform then uses the corresponding public key to verify the signature's validity. If signature verification fails, the process is immediately terminated and a security event is recorded. This mechanism, combined with a PKI system, achieves end-to-end identity authentication and non-repudiation, ensuring the upgrade package is traceable and tamper-proof from its source to the vehicle.

[0064] Thus, step S102 above, which encrypts and combines the PKI system's signature-based hybrid security encapsulation upgrade package, ensures the confidentiality of subsequent transmission processes and the authenticity and integrity of the source.

[0065] S103. The encrypted upgrade package formed by merging the encrypted upgrade content, digest value, encryption key, and upgrade package certificate is transmitted to the master node corresponding to the upgrade scenario, so that the master node can perform certificate chain verification based on the preset root certificate and the upgrade package certificate. If the verification passes, the first hash value corresponding to the digest value after designing is verified based on the hash algorithm to see if it is consistent with the second hash value corresponding to the original upgrade content. If they are consistent, the upgrade is performed based on the original upgrade content, wherein the original upgrade content is the content obtained by decrypting the encrypted upgrade content based on the encryption key.

[0066] In one example, when the upgrade scenario is an OTA upgrade, the master node is a TBOX; where TBOX (Telematics Box) is a remote information processor, an in-vehicle wireless communication module, responsible for securely communicating with the OTA platform through bidirectional links such as 4G / 5G to download the upgrade package.

[0067] In one example, in the case of a USB upgrade, the master node is the vehicle head unit (HU), where HU is the head unit of the vehicle infotainment system.

[0068] In one example, where the upgrade scenario is an OBD upgrade, the master node is the diagnostic tool. OBD (On-Board Diagnostics) is an interface that connects to the vehicle via a diagnostic tool for upgrades or fault diagnosis.

[0069] The above-mentioned verification is the process of verifying the validity of a digital signature, and it is the reverse process of signing.

[0070] The root certificate mentioned above is a self-signed certificate from a certificate authority (CA). It is the starting point of the entire trust chain and is usually pre-installed in the device.

[0071] The aforementioned Certificate Chain Validation verifies the validity of the issuing certificates level by level, starting from a single certificate, up to the trusted root certificate, to ensure that the terminal certificate is legitimate and trustworthy.

[0072] Thus, based on the trust chain transmission of the PKI system, a trust foundation is built throughout the entire process, from certificate verification of the pre-set root certificate to signing, designing, and two-way hash value authentication, ensuring the legitimacy of the upgrade package's origin. Furthermore, this application can transmit the encrypted upgrade package to the master node corresponding to the upgrade scenario, allowing the master node to decrypt and design it, and verify the integrity of the upgrade package through hash value verification, ensuring it has not been tampered with.

[0073] In the embodiments of this application, the above Figure 1 There are several possible implementations of step S101, which will be described below. It should be noted that the implementations given below are merely illustrative examples and do not represent all implementations of the embodiments of this application.

[0074] In one possible implementation, step S101 above is that after the upgrade task is initiated, the OTA operation platform responds to the supplier's two-factor authentication through the platform, obtains the upgrade package uploaded by the supplier, and performs a vulnerability scan on the upgrade package; wherein, the two-factor authentication includes U-shield authentication, and the supplier's U-shield is provided by the OTA management platform and has minimal functions authorized for the supplier.

[0075] The aforementioned minimal authorization feature is a security strategy where the system grants users only the minimum permissions necessary to perform their tasks, thereby reducing internal risks. It ensures that vendors can only upload upgrade packages and cannot access other system functions, effectively preventing abuse of permissions.

[0076] In the embodiments of this application, the above Figure 1 There are several possible implementations of step S102, which will be described below. It should be noted that the implementations given below are merely illustrative examples and do not represent all implementations of the embodiments of this application.

[0077] Furthermore, after completing the vulnerability scan in step S101, the OTA management platform refers to... Figure 2The diagram illustrates an encryption and signature process. In step S102, the upgrade package is encrypted using a random key to obtain encrypted upgrade content. Then, the upgrade package and the random key are signed using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate. This process may include:

[0078] Step A1: Encrypt the upgrade package using a random key and an encryption algorithm to obtain the encrypted upgrade content.

[0079] Optionally, the above encryption algorithm can be a symmetric encryption algorithm, such as AES-128, which uses a 128-bit random key to encrypt and decrypt the data to ensure the confidentiality of the data.

[0080] Optional, such as Figure 2 The aforementioned random key is a random key randomly generated by the OTA management platform.

[0081] Step A2: Perform a hash calculation on the upgrade package using a hash algorithm to obtain the first hash value.

[0082] In one example, the original packet is hashed using SHA-256 to obtain the first hash value, HASH-A. SHA-256 is a cryptographic hash function that can calculate a unique hash value of fixed length from data of any length. Any minor modification will cause the hash value to change, thus verifying data integrity.

[0083] Step A3: Obtain the certificate private key, certificate public key, and upgrade package certificate from the PKI system;

[0084] like Figure 2 The system obtains the certificate private key, certificate public key, and upgrade package certificate from the PKI system. The private key is the strictly confidential part of an asymmetric key pair, used for digital signatures or data decryption. The public key is the publicly distributed part of the asymmetric key pair, used for verifying signatures or encrypting data. The upgrade package certificate is a digital certificate issued by the PKI system, used to bind the public key to the holder's identity information.

[0085] Step A4: Sign the first hash value using the certificate private key to obtain the digest value.

[0086] Signing involves encrypting the hash value of the data using the sender's private key to generate a digest value (Signature). This digest value is used by the master node in subsequent step S103 to design the data and verify its authenticity and integrity.

[0087] Step A5: Sign the random key using the certificate public key to obtain the encryption key.

[0088] Step A6: Combine the above digest value, encrypted upgrade content, encryption key, and upgrade package certificate to form an encrypted upgrade package.

[0089] Based on the above steps A1-A6, the relevant content after encryption and signing (encryption upgrade content, encryption key, digest value and upgrade package certificate) is encapsulated and merged to generate a complete encryption upgrade package, ensuring that the data of each part remains consistent and complete during transmission.

[0090] Based on the above embodiments, see Figure 3 The diagram illustrates a transmission process for uploading to the master node on an OTA (Over-The-Air) operation platform. This encrypted upgrade package can be securely distributed to the master node, preventing man-in-the-middle tampering or theft of upgrade content, achieving secure end-to-end transmission. Specific steps may include:

[0091] In the case of an OTA upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: transmitting the encrypted upgrade package to the TBOX via a bidirectional link between the OTA operation platform and the SDK in the TBOX.

[0092] In one specific example, when the OTA upgrade is performed, the ECU supplier user submits the upgrade package to the OEM side. The OEM user uploads the upgrade package to the OTA management platform for encryption and signature processing to form the encrypted upgrade package. Then, it is transmitted to the master node TBOX through a two-way authentication link so that the TBOX can design and verify the authenticity and integrity of the upgrade package and send the upgrade package to other target controllers for upgrade.

[0093] In the case of a USB upgrade, the encrypted upgrade package is transmitted to the master node corresponding to the upgrade scenario, including: downloading it to the transmission medium via the OTA operation platform, and transmitting it to the vehicle host (HU) via the transmission medium.

[0094] In a specific example, such as Figure 2 As shown, the aforementioned transmission medium can be a USB flash drive. During a USB upgrade, after the OTA operation platform requests the download of the upgrade package, the aforementioned encrypted upgrade package is downloaded to the USB flash drive and then transmitted to the vehicle host (HU) via the USB flash drive.

[0095] In the case of an OBD upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: pushing the encrypted upgrade package to the diagnostic platform, and transmitting the encrypted upgrade package to the diagnostic instrument through a bidirectional link between the diagnostic platform and the diagnostic instrument.

[0096] In a specific example, such as Figure 3 As shown, during OBD upgrades, the OTA operation platform transmits the encrypted upgrade package to the diagnostic platform through a bidirectional interface call. Then, a one-way HTTPS verification is achieved between the diagnostic instrument and the diagnostic platform through a bidirectional link. After the verification is successful, the diagnostic instrument downloads the encrypted upgrade package.

[0097] The Diagnostic Platform is a back-end system used by OEMs to manage vehicle diagnostic data and upgrade tasks.

[0098] In one possible implementation, based on the above embodiments, after the encrypted upgrade package is transmitted to the master node, it is decrypted and unsigned by the master node to obtain the original upgrade package. The master node or other target controllers outside the master node are then upgraded based on the original upgrade package. Therefore, optionally, the OTA operation platform can generate the original upgrade package while simultaneously setting an upgrade command for the target controller to be upgraded, and then transmit the encrypted upgrade package and the upgrade command to the master node corresponding to the upgrade scenario.

[0099] In one possible implementation, based on the above embodiments, see [link to relevant documentation]. Figure 4 The flowchart shown may include, prior to step S103, the following:

[0100] The master node requests a terminal certificate and a decryption private key from the PKI system, and uses the terminal certificate as the pre-set root certificate.

[0101] The aforementioned root certificate is a self-signed certificate from a Certificate Authority (CA) and serves as the starting point of the entire trust chain. Optionally, the root certificate is pre-installed in the TBOX, and it can also be applied for and pre-installed in the TBOX by connecting to the PKI system during the production line stage.

[0102] Based on this, the authentication process for decryption and designing, using the pre-installed root certificate, can be as follows:

[0103] First, a legality verification is performed.

[0104] A certificate chain verification is performed between the pre-installed root certificate and the upgrade package certificate in the encrypted upgrade package. If the certificate chain verification passes, the validity of the encrypted upgrade package is verified. If the certificate chain verification fails, the process exits.

[0105] Then, the authenticity was verified.

[0106] The digest value is designed using the public key of the upgrade package certificate to obtain the first hash value (HASH-A), thereby verifying the authenticity of the source of the encrypted upgrade package.

[0107] Finally, perform integrity verification.

[0108] First, the original upgrade content is obtained. Specifically, the encryption key is decrypted using the decryption private key to obtain a random key. The encrypted upgrade content is then decrypted using the encryption algorithm and the random key to obtain the original upgrade content. Next, the original upgrade content is hashed using a hash algorithm to obtain a second hash value (HASH-B). Then, the first hash value and the second hash value are checked for consistency. If they match (HASH-A = HASH-B), the original upgrade content is confirmed to be intact and unaltered, and subsequent upgrade operations can continue. If they do not match, it is determined that the upgrade package has been damaged or maliciously tampered with during transmission, the decryption process is terminated, and a security anomaly is reported.

[0109] like Figure 4 The decryption and designature process sequentially completes legality verification, authenticity verification, and integrity verification, forming a multi-layered security verification and protection system to ensure that the upgrade package originates from a trustworthy source and that the data is complete.

[0110] Based on the above embodiments, such as Figure 3 After successfully obtaining the original upgrade package, each master node can perform the upgrade, and the specific process is as follows:

[0111] In the case of an OTA upgrade, if the target controller does not include a TBOX, the TBOX transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a TBOX, the TBOX performs a self-upgrade based on the original upgrade content and transmits the original upgrade content to a first controller to upgrade the first controller, where the first controller is the target controller other than the TBOX.

[0112] Optionally, the aforementioned first controller may also include, but is not limited to, vehicle controllers such as battery management system, motor controller, and body controller.

[0113] In the case of a USB upgrade, the vehicle-mounted unit (HU) performs a self-upgrade based on the original upgrade content.

[0114] In the case of an OBD upgrade, if the target controller does not include a diagnostic tool, the diagnostic tool transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a diagnostic tool, the diagnostic tool performs a self-upgrade based on the original upgrade content, and accesses the gateway through the 27 service to upgrade the gateway and the second controller based on the original upgrade content, wherein the second controller is another controller of the target controller besides the diagnostic tool.

[0115] Optionally, the aforementioned second controller may also include, but is not limited to, vehicle-mounted controllers such as battery management systems, motor controllers, and body controllers.

[0116] The aforementioned Service 27 (Security Access) is a secure access service that follows the UDS protocol and is used to authenticate the diagnostic instrument and unlock the controller before performing sensitive operations (such as flashing).

[0117] Based on the above embodiments, this application constructs a comprehensive security system covering the entire process of upgrade package upload, signing and encryption, transmission, and decryption / designature. The supplier logs into the OTA platform via two-factor authentication and uploads the upgrade package. After security is confirmed through vulnerability scanning, the signing and encryption process begins. Specifically, a first hash value is generated using SHA-256 and signed with the certificate's private key. Then, a random key is used to encrypt the upgrade package using AES-128. Finally, the signed signature, ciphertext, encryption key, and upgrade package certificate are combined into an encrypted upgrade package. During transmission, two-way authentication ensures link security. During decryption / designature, the certificate chain is verified level by level, decryption is performed, and hash values ​​are compared to ensure the upgrade package's legitimate origin, authenticity, complete content, and lack of tampering. Ultimately, the upgrade of controllers in each scenario is securely executed.

[0118] The above describes some specific implementations of a vehicle flashing upgrade package method provided in this application. Based on this, this application also provides a corresponding device. The device provided in this application will be described below from the perspective of functional modularity.

[0119] See Figure 5 The diagram shows a structural schematic of a vehicle flashing and upgrade package application. The application includes:

[0120] The scanning module 501 is used to perform vulnerability scanning on the upgrade package uploaded by the supplier in response to the supplier passing multiple certifications.

[0121] The encryption module 502 is used to encrypt the upgrade package with a random key to obtain encrypted upgrade content if the vulnerability scan shows no abnormalities, and to sign the upgrade package and the random key based on a hash algorithm and a PKI system to obtain a digest value, an encryption key and an upgrade package certificate.

[0122] Upgrade module 503 is used to transmit an encrypted upgrade package, consisting of merged encrypted upgrade content, digest value, encryption key, and upgrade package certificate, to the master node corresponding to the upgrade scenario. The master node then performs certificate chain verification based on a pre-set root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the digest value and the second hash value corresponding to the original upgrade content are consistent. If they are consistent, it performs an upgrade based on the original upgrade content, where the original upgrade content is obtained by decrypting the encrypted upgrade content using the encryption key.

[0123] Based on the aforementioned device, this application combines encryption and signature before transmission to the master node to ensure the confidentiality of the upgrade package during transmission. Subsequently, the master node decrypts and unsigns the package, and verifies it using hash values ​​to ensure the legitimacy, authenticity, and integrity of the upgrade package before and after transmission, effectively resisting man-in-the-middle attacks, malicious tampering, and unauthorized injection. Furthermore, digital signature verification is implemented through a PKI system to prevent forged certificates and key leaks, while the dynamic generation of random keys enhances the unpredictability of encryption. The master node's multi-factor verification process only allows the flashing operation after all security verifications have passed, significantly improving the security of vehicle upgrades in various scenarios and ensuring reliable updates of the vehicle system in complex upgrade environments.

[0124] In one possible implementation, the scanning module 501 is specifically used to obtain the upgrade package uploaded by the supplier and perform vulnerability scanning on the upgrade package in response to the supplier's two-factor authentication through the OTA management platform; wherein, the two-factor authentication includes U-shield authentication, and the supplier's U-shield is provided by the OTA management platform and has minimal functions authorized for the supplier.

[0125] In one possible implementation, the encryption module 502 is specifically used to encrypt the upgrade package using a random key combined with an encryption algorithm to obtain encrypted upgrade content; perform hash calculation on the upgrade package using a hash algorithm to obtain a first hash value; apply for a certificate private key, a certificate public key, and an upgrade package certificate from the PKI system; sign the first hash value using the certificate private key to obtain the digest value; and sign the random key using the certificate public key to obtain the encryption key.

[0126] In one possible implementation, when the upgrade scenario is an OTA upgrade, the upgrade module 503 is specifically used to transmit the encrypted upgrade package to the TBOX via a bidirectional link between the OTA operation platform and the SDK in the TBOX.

[0127] In the case of a USB upgrade, the upgrade module 503 is specifically used to download to the transmission medium via the OTA operation platform and transmit to the vehicle host HU via the transmission medium.

[0128] In the case of an OBD upgrade, the upgrade module 503 is specifically used to push the encrypted upgrade package to the diagnostic platform and transmit the encrypted upgrade package to the diagnostic instrument through a bidirectional link between the diagnostic platform and the diagnostic instrument.

[0129] In one possible implementation, the aforementioned master node is also used to apply to the PKI system for a terminal certificate and a decryption private key, and to use the terminal certificate as the pre-set root certificate.

[0130] In one possible implementation, the upgrade module 503 is further configured to decrypt the encryption key based on the decryption private key to obtain a random key; and to decrypt the encrypted upgrade content based on the encryption algorithm and the random key to obtain the original upgrade content.

[0131] In one possible implementation, the upgrade module 503 is specifically used to design the digest value using the certificate public key of the upgrade package certificate to obtain a first hash value; perform a hash calculation on the original upgrade content using a hash algorithm to obtain a second hash value; if the first hash value and the second hash value are consistent, then perform an upgrade based on the original upgrade content.

[0132] In one possible implementation, when the upgrade scenario is an OTA upgrade or an OBD upgrade, the upgrade module 503 is specifically used to transmit the encrypted upgrade package and upgrade instructions to the master node corresponding to the upgrade scenario, wherein the upgrade instructions are used to instruct the target controller to be upgraded.

[0133] In one possible implementation, upgrade module 503 is specifically configured to, in the case of an OTA upgrade, if the target controller does not include a TBOX, then the TBOX transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a TBOX, then the TBOX performs a self-upgrade based on the original upgrade content and transmits the original upgrade content to a first controller to upgrade the first controller, wherein the first controller is another controller of the target controller besides the TBOX.

[0134] Upgrade module 503 is specifically used to perform self-upgrade based on the original upgrade content when the upgrade scenario is a USB upgrade.

[0135] Upgrade module 503 is specifically used in the case of OBD upgrade, if the target controller does not include a diagnostic tool, the diagnostic tool transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a diagnostic tool, the diagnostic tool performs a self-upgrade based on the original upgrade content, and upgrades the gateway and the second controller based on the original upgrade content through the 27 service access gateway, wherein the second controller is the target controller other than the diagnostic tool.

[0136] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.

[0137] The device includes a memory and a processor. The memory stores instructions or code, and the processor executes the instructions or code to enable the device to perform a vehicle flashing and upgrade package method according to any embodiment of this application.

[0138] The computer storage medium stores code. When the code is executed, the device running the code implements a method for flashing and upgrading a vehicle according to any embodiment of this application.

[0139] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0140] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0141] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0142] The above description is merely an exemplary implementation of this application and is not intended to limit the scope of protection of this application.

Claims

1. A method for flashing an upgrade package onto a vehicle, characterized in that, The method includes: In response to the supplier passing multiple certifications, vulnerability scans are performed on the upgrade packages uploaded by the supplier. If the vulnerability scan finds no abnormalities, the upgrade package is encrypted using a random key to obtain the encrypted upgrade content. The upgrade package and the random key are then signed using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate. The encrypted upgrade package, consisting of the merged encrypted upgrade content, digest value, encryption key, and upgrade package certificate, is transmitted to the master node corresponding to the upgrade scenario. The master node performs certificate chain verification based on the preset root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the designed digest value and the second hash value corresponding to the original upgrade content are consistent. If they are consistent, the upgrade is performed based on the original upgrade content, which is the content obtained by decrypting the encrypted upgrade content using the encryption key.

2. The method according to claim 1, characterized in that, The response to the supplier passing multiple certifications involves performing a vulnerability scan on the upgrade package uploaded by the supplier, including: In response to the supplier's two-factor authentication through the OTA management platform, the system obtains the upgrade package uploaded by the supplier and performs a vulnerability scan on the upgrade package; wherein, the two-factor authentication includes U-shield authentication, the supplier's U-shield is provided by the OTA management platform and has minimal authorized functions for the supplier.

3. The method according to claim 1, characterized in that, The process involves encrypting the upgrade package using a random key to obtain encrypted upgrade content, and then signing the upgrade package and the random key using a hash algorithm and a PKI system to obtain a digest value, an encryption key, and an upgrade package certificate, including: The upgrade package is encrypted using a random key and an encryption algorithm to obtain the encrypted upgrade content; The upgrade package is hashed using a hash algorithm to obtain a first hash value; Apply for a certificate private key, certificate public key, and upgrade package certificate from the PKI system; The digest value is obtained by signing the first hash value with the certificate private key; The random key is signed using the certificate's public key to obtain the encryption key.

4. The method according to claim 3, characterized in that, In the case of an OTA upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: transmitting the encrypted upgrade package to the TBOX via a bidirectional link between the OTA operation platform and the SDK in the TBOX; In the case of a USB upgrade, the encrypted upgrade package is transmitted to the master node corresponding to the upgrade scenario, including: downloading it to the transmission medium through the OTA operation platform and transmitting it to the vehicle host HU through the transmission medium; In the case of an OBD upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: pushing the encrypted upgrade package to the diagnostic platform, and transmitting the encrypted upgrade package to the diagnostic instrument through a bidirectional link between the diagnostic platform and the diagnostic instrument.

5. The method according to claim 4, characterized in that, Before verifying the upgrade package certificate based on the preset root certificate, the method further includes: The master node requests a terminal certificate and a decryption private key from the PKI system, and uses the terminal certificate as the pre-set root certificate.

6. The method according to claim 5, characterized in that, The steps for obtaining the original upgrade content include: The encryption key is decrypted using the decryption private key to obtain a random key; The encrypted upgrade content is decrypted based on the encryption algorithm and the random key to obtain the original upgrade content.

7. The method according to claim 6, characterized in that, The step of verifying whether the first hash value corresponding to the decrypted digest value and the second hash value corresponding to the original upgrade content are consistent based on a hash algorithm, and if they are consistent, then performing the upgrade based on the original upgrade content, includes: The digest value is designed using the public key of the upgrade package certificate to obtain the first hash value; The original upgrade content is hashed using a hash algorithm to obtain a second hash value; If the first hash value matches the second hash value, then the upgrade is performed based on the original upgrade content.

8. The method according to claim 7, characterized in that, In the case of an OTA upgrade or an OBD upgrade, transmitting the encrypted upgrade package to the master node corresponding to the upgrade scenario includes: The encrypted upgrade package and upgrade instructions are transmitted to the master node corresponding to the upgrade scenario. The upgrade instructions are used to instruct the target controller to be upgraded.

9. The method according to claim 8, characterized in that, The upgrade based on the original upgrade content includes: In the case of an OTA upgrade, if the target controller does not include a TBOX, the TBOX transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a TBOX, the TBOX performs a self-upgrade based on the original upgrade content and transmits the original upgrade content to a first controller to upgrade the first controller, where the first controller is the target controller other than the TBOX. In the case of a USB upgrade, the vehicle-mounted unit (HU) performs a self-upgrade based on the original upgrade content. In the case of an OBD upgrade, if the target controller does not include a diagnostic tool, the diagnostic tool transmits the original upgrade content to the target controller to upgrade the target controller; if the target controller includes a diagnostic tool, the diagnostic tool performs a self-upgrade based on the original upgrade content, and accesses the gateway through the 27 service to upgrade the gateway and the second controller based on the original upgrade content, wherein the second controller is another controller of the target controller besides the diagnostic tool.

10. A device for flashing and upgrading vehicle upgrade packages, characterized in that, The device includes: The scanning module is used to perform vulnerability scanning on the upgrade packages uploaded by suppliers in response to suppliers passing multiple certifications. The encryption module is used to encrypt the upgrade package with a random key to obtain encrypted upgrade content if the vulnerability scan shows no abnormalities, and to sign the upgrade package and the random key based on a hash algorithm and a PKI system to obtain a digest value, an encryption key and an upgrade package certificate. The upgrade module is used to transmit the encrypted upgrade package, which is formed by merging the encrypted upgrade content, digest value, encryption key, and upgrade package certificate, to the master node corresponding to the upgrade scenario. The master node performs certificate chain verification based on the preset root certificate and the upgrade package certificate. If the verification passes, it checks whether the first hash value corresponding to the digest value and the second hash value corresponding to the original upgrade content are consistent based on the hash algorithm. If they are consistent, the upgrade is performed based on the original upgrade content, wherein the original upgrade content is the content obtained by decrypting the encrypted upgrade content based on the encryption key.