Vehicle-mounted software upgrading method and device and computer program product

Abstract

The invention discloses a vehicle-mounted software upgrading method and device and a computer program product, and the method comprises the steps: generating a feature factor based on vehicle identification information; generating a verification list file; generating an integrity verification file; performing digital signature on the integrity verification file to generate a signature file, and packaging the verification list file, the integrity verification file, the signature file and the public key certificate into a verification file package; the vehicle machine reads the verification file package and verifies the consistency of the hash values in the verification list file and the integrity verification file, the validity of the signature file and the legality of the public key certificate; and when all verification is passed, dynamically calculating the hash value of each firmware sub-packet based on the feature factor, matching the hash value with the hash value of each firmware sub-packet in the verification list file, and if the matching is successful, executing upgrading. According to the method, the feature factors and a centralized verification mechanism are introduced, so that the safety and the convenience of off-line upgrading of the vehicle-mounted USB are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent connected vehicles, and particularly to a vehicle software upgrade method, device and computer program product. Background Art

[0002] With the continuous compression of the function iteration cycle of intelligent connected vehicles, vehicle software upgrade has become the core technical means to improve user experience, repair security vulnerabilities and expand functions. Among them, USB offline upgrade, as a key link in the research and development debugging and after-sales maintenance of the intelligent cockpit system, provides an efficient function deployment channel in scenarios without network environment.

[0003] However, the security mechanism of existing upgrade solutions has the following defects:

[0004] It adopts a full-signature and hash verification strategy, which requires digital signature and integrity verification to be implemented for all files and the overall container in the upgrade package layer by layer, resulting in a long and complex upgrade package construction process, and the verification process needs to strictly follow the layer-by-layer verification order of "from large package to small package". This strongly coupled verification mechanism not only increases the difficulty of key management, but also exposes serious security vulnerabilities in malicious attack scenarios. Attackers can inject forged files or tamper with legitimate package bodies through the upgrade channel, implant backdoor programs by bypassing the layer-by-layer verification mechanism, and then achieve high-risk attacks such as vehicle remote control and function hijacking, directly threatening driving safety and user privacy. Summary of the Invention

[0005] The technical problem to be solved by the embodiments of the present invention is to provide a vehicle software upgrade method, device and computer program product to improve the security and convenience of the upgrade at the same time.

[0006] To solve the above technical problem, the present invention provides a vehicle software upgrade method, including:

[0007] Generating a feature factor based on vehicle identification information;

[0008] Generating a verification list file, where the verification list file includes hash values of each firmware sub-package calculated in combination with the feature factor;

[0009] Generating an integrity verification file, where the integrity verification file includes the hash value of the verification list file and the hash value of the public key certificate calculated respectively in combination with the feature factor;

[0010] Performing digital signature on the integrity verification file to generate a signature file, and encapsulating the verification list file, integrity verification file, signature file and public key certificate into a verification file package;

[0011] The in-vehicle computer reads the verification file package, and respectively verifies the consistency of the hash values in the verification list file and the integrity check file, the validity of the signature file, and the legality of the public key certificate;

[0012] When all verifications pass, calculate the hash values of each firmware sub-package dynamically based on the characteristic factor, and match them with the hash values of each firmware sub-package in the verification list file. If the match is successful, perform the upgrade.

[0013] Preferably, the method of calculating the hash values of each firmware sub-package in combination with the characteristic factor is as follows:

[0014] Splice the characteristic factor to the tail of the original binary data of each firmware sub-package in the form of a byte stream, and calculate the hash value of the spliced data using the SHA-256 algorithm.

[0015] Preferably, the method of calculating the hash value of the verification list file and the public key certificate hash value in combination with the characteristic factor is as follows:

[0016] Splice the characteristic factor to the tail of the verification list file and the public key certificate respectively, and calculate the hash value of the spliced data using the SHA-256 algorithm.

[0017] Preferably, the generation of the characteristic factor based on the vehicle identification information specifically includes:

[0018] Extract a preset number of digit characters from the vehicle parts serial number and insert them into a preset position in the vehicle identification number, and splice them to generate the characteristic factor.

[0019] Preferably, the digital signature of the integrity check file is specifically to sign the integrity check file using the RSA 2048 private key preset at the time of vehicle off-line.

[0020] Preferably, the verification file package is encapsulated as a ZIP format file, and is encapsulated together with each firmware sub-package in the whole package upgrade package, and the verification list file exists in both the root directory of the whole package upgrade package and the inner layer of the verification file package.

[0021] Preferably, the method further includes:

[0022] Judge whether the current upgrade package is a whole package upgrade package;

[0023] If the current upgrade package is a whole package upgrade package, extract the verification file package in the whole package upgrade package;

[0024] If the current upgrade package is a single package upgrade package, extract the verification file package under the current upgrade package path. If the verification file package does not exist, terminate the upgrade.

[0025] Preferably, when all verifications pass, calculate the hash values of each firmware sub - package dynamically based on the characteristic factor, and match them with the hash values of each firmware sub - package in the verification list file. If the match is successful, execute the upgrade, specifically including:

[0026] Extract the preset hash value of each firmware sub - package from the verification list file;

[0027] Read the firmware sub - package to be upgraded, splice its original data with the characteristic factor, and calculate the current hash value;

[0028] Then match the calculated current hash value with the preset hash value recorded in the verification list file;

[0029] If the match is successful, enter the upgrade process; otherwise, terminate the upgrade.

[0030] The present invention also provides an in - vehicle software upgrade device, including:

[0031] One or more processors;

[0032] A memory;

[0033] One or more applications, wherein the one or more applications are stored in the memory and are configured to be executed by the one or more processors, and the one or more applications are configured to execute the in - vehicle software upgrade method described above.

[0034] The present invention also provides a computer program product, including computer instructions, and the computer instructions direct a computer device to perform the operations corresponding to the method.

[0035] Implementing the present invention has the following beneficial effects: By introducing a characteristic factor and a centralized verification mechanism, the present invention significantly improves the security and convenience of in - vehicle USB offline upgrade. In terms of efficiency, adopting the mechanism of single - signature covering multiple firmware sub - packages simplifies the cumbersome process of independently signing and verifying each sub - package in the traditional solution into a single global signature operation, greatly reducing the repetitive steps for engineers to make upgrade packages, especially saving operation time in the scenario of multi - module collaborative upgrade. In terms of security, by dynamically generating a characteristic factor strongly bound to the vehicle VIN code and component SN code, it ensures that the hash value of the upgrade package varies uniquely according to the vehicle identity, completely blocking the possibility of cross - device reuse or batch tampering attacks. In addition, the compatibility design supports the smooth transition between old and new in - vehicle systems. The outer - layer verification list file is convenient for the old system to quickly read, and the inner - layer nested structure provides in - depth defense for the new system, taking into account both the flexibility and security requirements of the upgrade, and providing an efficient and reliable full - life - cycle software management solution for intelligent vehicles. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0037] Figure 1 It is a schematic flowchart of a vehicle software upgrade method according to Embodiment 1 of the present invention.

[0038] Figure 2 It is a schematic diagram of the composition of the upgrade package in the embodiment of the present invention. Detailed implementation manners

[0039] The descriptions of the following embodiments refer to the drawings to exemplify specific embodiments in which the present invention can be implemented.

[0040] Please refer to Figure 1 As shown, Embodiment 1 of the present invention provides a vehicle software upgrade method, including:

[0041] Generating a feature factor based on vehicle identification information;

[0042] Generating a verification list file, where the verification list file includes hash values of each firmware sub-package calculated in combination with the feature factor;

[0043] Generating an integrity check file, where the integrity check file includes the hash value of the verification list file and the hash value of the public key certificate calculated respectively in combination with the feature factor;

[0044] Performing a digital signature on the integrity check file to generate a signature file, and encapsulating the verification list file, integrity check file, signature file, and public key certificate into a verification file package;

[0045] The vehicle head unit reads the verification file package and verifies the consistency of the hash values in the verification list file and the integrity check file, the validity of the signature file, and the legality of the public key certificate respectively;

[0046] When all verifications pass, dynamically calculate the hash values of each firmware sub-package based on the feature factor, and match them with the hash values of each firmware sub-package in the verification list file. If the match is successful, perform the upgrade.

[0047] From the above steps, it can be seen that the embodiment of the present invention significantly improves the security and efficiency of vehicle software offline upgrade through a dual verification mechanism of constructing a verification list file for centralized storage of firmware sub-package hash values, performing a single digital signature on the integrity check file, and dynamically participating in hash calculation in combination with vehicle feature factors.

[0048] Specifically, in the embodiments of the present invention, first, the serial number (SN) of the corresponding in-vehicle computer and the public key of the Public Key Infrastructure (PKI) certificate are queried from the Telematics Service Provider (TSP) through the Vehicle Identification Number (VIN). It can be understood that the VIN code is the unique identity identification code written by the Original Equipment Manufacturer (OEM) when the vehicle is fully assembled and rolled off the production line. As the only identity credential during the entire life cycle of the vehicle, it is used for identity verification in scenarios such as software upgrades. The SN code is the unique serial number assigned by the automotive parts supplier (Tier1) when the parts are produced and shipped from the factory, used to identify the production batch, model, and traceability information of a single part. When the vehicle is fully assembled and rolled off the production line, the OEM associates the SN code with the VIN code of the vehicle to which it belongs and uploads it to the TSP.

[0049] After obtaining the VIN code and SN code through the query, a feature factor will be generated. The specific process is as follows:

[0050] First, specific parts are extracted from the vehicle VIN code and the SN code of in-vehicle components. For the SN code, take 2^n (e.g., n = 3) characters of its total length. For example, if the SN code is "SN12345678ABCD", then extract the first 8 digits ("SN123456") and insert them into the 3^n (n = 3)th position of the VIN code to form a new string. The complete string after insertion is used as the feature factor. This feature factor is strongly bound to the vehicle and component information and is used for subsequent signature and hash calculation of the upgrade package to ensure that the hash value of each upgrade package is unique for different vehicles, thereby blocking the risk of illegal tampering or cross-vehicle batch upgrades.

[0051] Please refer to Figure 2 As shown, in the embodiments of the present invention, the upgrade package can be in the form of a full.zip package, which includes multiple firmware sub-packages (soc.zip, mcu.zip) and a verification file package (testify.zip). The verification file package encapsulates a verification list file (testify.txt), an integrity check file (cert.sf), a signature file (cert.sign), and a public key certificate (cert.pem). Specifically:

[0052] The firmware sub-packages soc.zip and mcu.zip are software modules to be upgraded;

[0053] The verification list file testify.txt is used to configure some upgrade-related information, which can be customized according to project requirements, and records the hash values of all firmware sub-packages (such as the SHA256 value of soc.zip);

[0054] The integrity verification file cert.sf contains the full file names and their hash values (SHA256 values) of all files except cert.sf and cert.sign;

[0055] The signature file cert.sign is generated by signing the integrity verification file cert.sf;

[0056] The public key certificate cert.pem is the public key certificate issued by the PKI server, which is used to verify the signature of the integrity verification file cert.sf, and the integrity of this public key is verified using the PKI certificate built into the in-vehicle unit.

[0057] It should also be noted that considering the compatibility requirements of the old in-vehicle unit system, in the embodiments of the present invention, the verification list file also exists in the root directory of the upgrade package full.zip (i.e., the outer layer of the verification file package). If the old in-vehicle unit only supports directly reading the verification list file testify.txt from the root directory of the upgrade package for firmware hash verification and cannot parse the nested files in the verification file package testify.zip, then the testify.txt located in the outer layer can support the old system to continue using the original verification logic (only verifying the firmware hash) to achieve a smooth transition. The new in-vehicle unit preferentially uses the verification list file testify.txt in the verification file package testify.zip to avoid directly trusting the outer layer files, thereby defending against the risk of tampering.

[0058] As an improvement to the prior art, the embodiments of the present invention embed the feature factor factor generated based on the vehicle identification information into the process of constructing the upgrade package, which is specifically described as follows:

[0059] (1) Feature factor factor splicing

[0060] The feature factor factor is spliced to the end of the upgrade package data (including the original binary data of all firmware sub-packages (soc.zip, mcu.zip) and the verification list file testify.txt). As an example, the splicing method is to append in the form of a byte stream.

[0061] (2) Calculating the firmware sub-package hash value according to the feature factor factor

[0062] The software modules to be upgraded (such as the in-vehicle unit system SOC, microcontroller MCU) are respectively packaged into independent firmware sub-packages (for example, soc.zip, mcu.zip).

[0063] After associating the data of the firmware sub - package with the characteristic factor "factor", calculate its hash value using the SHA - 256 algorithm. The specific form of data association is: in the form of a byte stream, append the characteristic factor "factor" to the tail of the original binary data of each firmware sub - package. For example:

[0064] Hash value of soc.zip: sha256(soc + factor)

[0065] Hash value of mcu.zip: sha256(mcu + factor)

[0066] (3) Generate the verification list file testify.txt

[0067] Create a verification list file testify.txt in JSON format, recording the name, hash value, and version information of each firmware sub - package, as follows:

[0068]

[0069] (4) Generate the integrity check file cert.sf

[0070] Calculate the SHA - 256 hash values of the verification list file testify.txt and the public key certificate cert.pem after appending the characteristic factor "factor" respectively, and write the results into the integrity check file cert.sf. For example:

[0071] {

[0072] "cert.testify.hash": "sha256(testify.txt + factor)"

[0073] "cert.pem.hash": "sha256(cert.pem + factor)"

[0074] }

[0075] (5) Generate the signature file cert.sign

[0076] Sign cert.sf using the RSA 2048 private key to generate the signature file cert.sign.

[0077] Use the private key of the PKI certificate pre - set when the vehicle is off - line to perform RSA2048 signature on the integrity check file cert.sf to generate the signature file cert.sign.

[0078] (6) Package to form the full - package upgrade package full.zip

[0079] Package the firmware sub-packages (soc.zip, mcu.zip), verification list file testify.txt, integrity check file cert.sf, signature file cert.sign, and public key certificate cert.pem into full.zip.

[0080] As can be seen from the above, in the embodiments of the present invention, the hash value of each file (firmware sub-package, verification list file testify.txt, public key certificate cert.pem) is calculated based on the concatenation of its original data and the feature factor factor, and the feature factor factor is strongly correlated with the vehicle and its components, thereby ensuring that all key files are uniquely bound to the vehicle and improving the verification security.

[0081] In addition to the full package upgrade package, when making a single package upgrade package that only upgrades a single firmware sub-package (such as only soc.zip or mcu.zip), each single package upgrade package also comes with a dedicated verification file package testify.zip. This verification file package testify.zip also includes the verification list file testify.txt, integrity check file cert.sf, signature file cert.sign, and public key certificate cert.pem. The verification list file testify.txt stores the hash value of this single firmware sub-package calculated in combination with the feature factor factor, and the integrity check file cert.sf stores the hash value of the verification list file testify.txt calculated in combination with the feature factor factor; and the hash value of the public key certificate cert.pem calculated in combination with the feature factor factor. The generation process is the same as that when making the full package upgrade package and will not be elaborated here.

[0082] When performing an offline upgrade by inserting the packaged upgrade package into the in-vehicle computer through an external storage device such as a USB flash drive, it will first determine whether it is a full package upgrade. If it is a full package upgrade, it will obtain the testify.zip file in the upgrade package; if it is a single package upgrade, it will obtain the verification file package testify.zip in the current single package path. If testify.zip does not exist, it will prompt that testify.zip is missing.

[0083] Unzip the obtained verification file package testify.zip to get the verification list file testify.txt, integrity check file cert.sf, signature file cert.sign, and public key certificate cert.pem, and then perform the following multi-level verification process respectively:

[0084] (1) Hash consistency verification

[0085] Parse the integrity verification file cert.sf and obtain the hash value (cert.testify.hash) of the verification list file testify.txt stored in it;

[0086] Combine the feature factor factor and calculate the hash value (testify.hash) of the decompressed verification list file testify.txt through the SHA-256 algorithm;

[0087] If the current hash value (testify.hash) of the calculated verification list file testify.txt is consistent with the hash value (cert.testify.hash) recorded in the integrity verification file cert.sf, that is, testify.hash = cert.testify.hash, then the verification passes; otherwise, it is determined that the file has been tampered with and the upgrade is terminated.

[0088] Through the above hash consistency verification, the integrity of testify.txt can be verified to ensure that the hash values of each firmware sub-package recorded in it have not been tampered with.

[0089] (2) Signature validity verification

[0090] Use the public key in the public key certificate cert.pem to perform RSA2048 signature verification on the content of the integrity verification file cert.sf;

[0091] If the signature file cert.sign matches the content of the integrity verification file cert.sf, the verification passes; otherwise, it is determined that the source of the upgrade package is illegal (package authenticity verify fail) and the upgrade is terminated.

[0092] Through the above signature validity verification, the integrity and authenticity of the integrity verification file cert.sf can be verified to ensure that it has not been tampered with and is issued by a legal entity.

[0093] (3) Public key certificate legality verification

[0094] Call the PKI (Public Key Infrastructure) interface pre-installed in the vehicle to verify the legality of the public key certificate cert.pem, including: whether the certificate issuer is trusted, whether the certificate is within the validity period, whether the certificate has not been revoked, etc. If the verification passes, the public key is determined to be trusted; otherwise, the certificate is determined to be illegal (cert.pem authenticity verify fail) and the upgrade is terminated.

[0095] Through the above public key certificate legality verification, it can be ensured that the public key certificate cert.pem used for signature verification is legal itself, preventing attackers from forging certificates.

[0096] After completing the multi-level verification process, the embodiments of the present invention will dynamically calculate the hash values of each firmware sub-package based on the feature factor factor, and match them with the hash values of each firmware sub-package in the verification list file testify.txt. If the match is successful, the upgrade will be executed. The specific description is as follows:

[0097] First, the in-vehicle computer extracts the file name (such as soc, mcu) and its preset hash value (update.hash) of each firmware sub-package from the verification list file testify.txt.

[0098] Then, the in-vehicle computer reads the firmware sub-package to be upgraded (such as soc_update.zip), splices its original data with factor, and calculates the SHA-256 hash value to obtain soc.update.hash.

[0099] Next, the calculated soc.update.hash is matched with the update.hash recorded in the verification list file testify.txt:

[0100] If the match is successful, it indicates that the firmware sub-package has not been tampered with and is bound to the current vehicle, allowing entry into the upgrade process. It can be understood that the hash value (update.hash) of the firmware sub-package recorded in the verification list file testify.txt is the result calculated based on the same feature factor factor during the generation of the upgrade package. The in-vehicle computer needs to dynamically calculate the same hash value to pass the match verification.

[0101] If the match fails, it is determined that the firmware sub-package is illegal (possibly tampered with or not dedicated to this vehicle), and the upgrade is terminated with an error message.

[0102] The embodiments of the present invention achieve double verification through the above dynamic hash verification: one is integrity: the firmware sub-package data has not been tampered with; the other is exclusivity: the firmware sub-package is only applicable to the current vehicle (based on the uniqueness of the feature factor factor).

[0103] It should be noted that existing in-vehicle software upgrade solutions need to perform digital signature and hash verification on each firmware sub-package separately. For example, when there are three firmware modules, the signature and verification processes need to be executed for each module separately. This decentralized verification mechanism not only increases the time cost of building the upgrade package, but also raises the complexity of key management due to multiple signature operations.

[0104] As described above, the present invention compresses the multi-module verification dependency into a single signature verification by introducing the integrity verification file cert.sf. Specifically, the generated verification list file testify.txt in the upgrade package completely records the hash values of all firmware sub-packages. The integrity verification file cert.sf contains the hash value of the verification list file testify.txt. Therefore, performing a digital signature on the integrity verification file cert.sf can cover all firmware sub-packages, indirectly protecting all firmware sub-packages. If an attacker tampers with any firmware sub-package, the hash value of the verification list file testify.txt will change, resulting in a mismatch with the hash value recorded in the integrity verification file cert.sf, causing the signature verification to fail and the upgrade to terminate.

[0105] The present invention also introduces a characteristic factor factor that is strongly bound to vehicle information. This factor is dynamically generated through the vehicle VIN code and the component hardware SN code and is embedded in all hash calculation processes. For example, the hash value of the firmware sub-package is not directly generated based on the file content, but is calculated after splicing the file data with factor. This makes the same upgrade package have completely different hash values in different vehicles. Even if the upgrade package is illegally copied or leaked, it cannot pass the verification on other vehicles. This "one vehicle, one package" mechanism completely eliminates the possibility of batch tampering attacks, and at the same time does not rely on the network environment to verify the identity in real time, adapting to the offline upgrade scenario.

[0106] Corresponding to the vehicle software upgrade method described in the first embodiment of the present invention, the second embodiment of the present invention further provides a vehicle software upgrade device, including:

[0107] One or more processors;

[0108] A memory;

[0109] One or more applications, where the one or more applications are stored in the memory and are configured to be executed by the one or more processors, and the one or more applications are configured to execute the vehicle software upgrade method described in the first embodiment of the present invention.

[0110] Corresponding to the vehicle software upgrade method described in the first embodiment of the present invention, the third embodiment of the present invention further provides a computer program product, including computer instructions, where the computer instructions instruct a computer device to perform the operations corresponding to the vehicle software upgrade method described in the first embodiment of the present invention.

[0111] Preferably, the processor may be a Central Processing Unit (CPU), or may also be 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 the processor may also be any conventional processor. The processor is the control center of the device, and connects various parts of the device through various interfaces and circuits.

[0112] The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function, etc., and the data storage area can store relevant data, etc. In addition, the memory may be a high-speed random access memory, or may also be a non-volatile memory, such as a plug-in hard disk, a SmartMedia Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., or the memory may also be other volatile solid-state storage devices.

[0113] It should be noted that the above device may include but is not limited to a processor and a memory, which can be understood by those skilled in the art.

[0114] For the working principles and processes of the above embodiments, please refer to the description of Embodiment 1 of the present invention above, and details are not described herein again.

[0115] As can be seen from the above description, compared with the prior art, the beneficial effects of the present invention are as follows: By introducing the feature factor and the centralized verification mechanism, the present invention significantly improves the security and convenience of in-vehicle USB offline upgrade. In terms of efficiency, the mechanism of using a single signature to cover multiple firmware sub-packages simplifies the cumbersome process of independently signing and verifying each sub-package in the traditional solution into a single global signature operation, greatly reducing the repetitive steps for engineers to create upgrade packages, especially saving operation time in the scenario of multi-module collaborative upgrade. In terms of security, by dynamically generating a feature factor strongly bound to the vehicle VIN code and the component SN code, it ensures that the hash value of the upgrade package varies uniquely according to the vehicle identity, completely blocking the possibility of cross-device reuse or batch tampering attacks. In addition, the compatibility design supports the smooth transition between old and new in-vehicle systems. The outer verification list file is convenient for the old system to quickly read, and the inner nested structure provides in-depth defense for the new system, taking into account the requirements of upgrade flexibility and security, and providing an efficient and reliable full-life cycle software management solution for intelligent vehicles.

[0116] The above-disclosed are only the preferred embodiments of the present invention. Of course, the scope of the rights of the present invention cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. A vehicle-mounted software upgrade method, characterized in that, including: generating a feature factor based on vehicle identification information; generating a verification list file, where the verification list file includes hash values of each firmware sub-package calculated in combination with the feature factor; generating an integrity verification file, where the integrity verification file includes the hash value of the verification list file and the public key certificate hash value calculated respectively in combination with the feature factor; performing a digital signature on the integrity verification file to generate a signature file, and encapsulating the verification list file, integrity verification file, signature file, and public key certificate into a verification file package; the in-vehicle unit reads the verification file package and respectively verifies the consistency of the hash values in the verification list file and the integrity verification file, the validity of the signature file, and the legality of the public key certificate; when all verifications pass, dynamically calculate the hash values of each firmware sub-package based on the feature factor, and match them with the hash values of each firmware sub-package in the verification list file. If the match is successful, perform the upgrade.

2. The method according to claim 1, wherein The method of calculating the hash value of each firmware sub-package in combination with the feature factor is: concatenate the feature factor in the form of a byte stream to the tail of the original binary data of each firmware sub-package, and calculate the hash value of the concatenated data using the SHA-256 algorithm.

3. The method according to claim 1, characterized in that The method of calculating the hash value of the verification list file and the public key certificate hash value in combination with the feature factor is: respectively concatenate the feature factor to the tails of the verification list file and the public key certificate, and calculate the hash value of the concatenated data using the SHA-256 algorithm.

4. The method according to any one of claims 1 to 3, characterized in that, The generating the feature factor based on vehicle identification information specifically includes: extracting a preset number of digits from the vehicle part serial number and inserting them into a preset position in the vehicle identification number, and concatenating to generate the feature factor.

5. The method according to claim 1, wherein The performing the digital signature on the integrity verification file specifically uses the RSA 2048 private key preset when the vehicle is offline to sign the integrity verification file.

6. The method according to claim 1, characterized in that, The verification file package is encapsulated as a ZIP format file, and is encapsulated together with each firmware sub-package in the whole package upgrade package, and the verification list file exists in both the root directory of the whole package upgrade package and the inner layer of the verification file package.

7. The method according to claim 6, wherein also including: judging whether the current upgrade package is a whole package upgrade package; if the current upgrade package is a whole package upgrade package, extract the verification file package in the whole package upgrade package; if the current upgrade package is a single package upgrade package, extract the verification file package under the current upgrade package path. If the verification file package does not exist, terminate the upgrade.

8. The method according to claim 1, characterized in that, The when all verifications pass, dynamically calculate the hash values of each firmware sub-package based on the feature factor, and match them with the hash values of each firmware sub-package in the verification list file. If the match is successful, perform the upgrade, specifically includes: extracting the preset hash value of each firmware sub-package from the verification list file; reading the firmware sub-package to be upgraded, concatenating its original data with the feature factor, and calculating the current hash value; then matching the calculated current hash value with the preset hash value recorded in the verification list file; if the match is successful, enter the upgrade process; otherwise, terminate the upgrade.

9. A vehicle-mounted software upgrade device, characterized in that, including: one or more processors; a memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to execute the vehicle software upgrade method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, Comprising computer instructions, the computer instructions instructing the computer device to perform operations corresponding to the method according to any one of claims 1 to 8.

Images