Upgrade package substitution signature and verification method and device, electronic equipment and computer storage medium

Abstract

The invention provides an upgrade package substitution signature and verification method and device, electronic equipment and a computer storage medium, and relates to the technical field of vehicle control. The method comprises the steps that a main node controller responds to an upgrading request and obtains a signed upgrading package containing a container format upgrading package and a corresponding digital signature file; the format compliance of the signature file is verified first, and then signature verification is executed by using a preset public key; after the signature verification is passed, the upgrade package is decompressed and differentiated distribution is carried out according to the private key use condition: for the slave node multiplexing the private key of the master node, the upgrade content is extracted, and a CRC verification value is calculated and issued; and directly transmitting the original signature file and the upgrade package to the slave node using the private key of the slave node. And after receiving the data, the slave node executes verification and feeds back a result. According to the method, through a master node centralized signature verification and differentiation distribution mechanism, on the premise of ensuring safety, the signature verification burden of the resource-limited slave nodes is effectively reduced, and the upgrading efficiency and the system compatibility are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle control technology, and in particular to an upgrade package signing and verification method, device, electronic device, and computer storage medium. Background Technology

[0002] With the increasing prevalence of in-vehicle software upgrades, a secure and reliable upgrade process has become a basic industry requirement. Currently, in-vehicle controllers typically employ high-strength digital signature schemes for verification during upgrades to ensure the integrity and authenticity of the software source. However, for resource-constrained slave node controllers (such as vehicle infotainment screens), their limited computing power and storage resources make it difficult to independently complete complex signature verifications, severely impacting upgrade efficiency and overall system performance.

[0003] Since vehicle-side controllers come from different vendors, exhibiting heterogeneous hardware platforms and various signature verification standards, allowing resource-constrained slave nodes to independently perform high-strength signature verification would result in significant computational overhead and time delays, potentially leading to upgrade failures or security vulnerabilities. Therefore, existing solutions often rely on the master node to perform unified signature verification, supplemented by CRC checksums, before distributing the signatures to slave nodes. However, this method has weak anti-forgery capabilities, and in multi-vendor environments, key management and signature verification processes are complex and difficult to implement uniformly.

[0004] To address the aforementioned issues, there is an urgent need for a lightweight upgrade package signing and verification method that can both ensure the security of the upgrade process and effectively reduce the signing burden on resource-constrained terminals. Summary of the Invention

[0005] The purpose of this invention is to provide an upgrade package signing and verification method, device, electronic device, and computer storage medium. By using a centralized signature verification and differentiated distribution mechanism of the master node, combined with the reuse of the master node's private key and CRC verification, it provides an efficient, reliable, and easy-to-deploy lightweight solution for vehicle-side software upgrades, significantly improving upgrade efficiency and system compatibility.

[0006] In a first aspect, the present invention provides a method for verifying and signing upgrade packages, comprising: In response to an upgrade request, the master node controller obtains an upgrade file group; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node private key is reused for signing; The master node controller determines whether the signed upgrade package contains a container format upgrade package and a digital signature file; If so, the master node controller calls the public key preset in the secure storage area to verify the format of the digital signature file to ensure that the digital signature file conforms to the preset encoding rules; If the format verification passes, the master node controller performs signature verification on the digitally signed file based on the public key. After the signature is verified, the container format upgrade package is decompressed to obtain the upgrade content of the node controller to be upgraded, and differentiated distribution is performed based on the private key category corresponding to the signed upgrade package. The differentiated distribution includes: for slave nodes that reuse the master node's private key for signing, extracting their upgrade content and calculating the cyclic redundancy check value for distribution; for slave nodes that use their own slave node's private key for signing, passing through the paired container format upgrade package and digital signature file. The node controller to be upgraded receives the upgrade content and CRC check value, or receives the transparently transmitted signed upgrade package, performs the verification, and returns the result.

[0007] In some preferred embodiments of the present invention, differentiated distribution further includes: For upgrades to the master node controller itself, the upgrade content is transferred to the internal upgrade module for upgrade and self-test execution.

[0008] In some preferred embodiments of the present invention, before the step of the master node controller obtaining the upgrade file group in response to an upgrade request, the method further includes: Convert the initial software package into a containerized upgrade package; Match the corresponding private key based on the controller name identified in the container format upgrade package; The container format upgrade package is hashed and asymmetric encrypted using the matching private key to generate the corresponding digital signature file. Package the container format upgrade package and the corresponding digital signature file together to identify the signed upgrade package.

[0009] In some preferred embodiments of the present invention, the master node controller performs a signature verification step on the digitally signed file based on the public key, including: The hash calculation of the container format upgrade package and the decryption verification of the digital signature file are performed in parallel, and the signature verification is deemed successful when the hash calculation result matches the hash value obtained from decryption.

[0010] In some preferred embodiments of the present invention, the method further includes: After the entire upgrade is completed, the master node controller securely erases the temporary key and intermediate calculation results stored in memory, and writes the upgrade process, timestamps, and operation results into the encrypted log system.

[0011] In some preferred embodiments of the present invention, the method further includes: If any step in the format verification, signature verification, or verification of the node controller to be upgraded fails, the current and subsequent upgrade processes will be terminated, and a security rollback mechanism will be triggered to restore all affected controllers to the software version before the upgrade.

[0012] In some preferred embodiments of the present invention, the controller using the master node private key includes: a vehicle master controller, a screen controller, and an augmented reality head-up display controller; the controller using the slave node private key includes: an in-vehicle telematics controller, an emergency call controller, and an automatic parking assist controller; wherein, the master node controller is the vehicle master controller.

[0013] Secondly, the present invention provides an upgrade package signature verification device, comprising: The upgrade package acquisition module is used to acquire the upgrade file group in response to the upgrade request from the master node controller. The upgrade file group includes at least one signed upgrade package. The signed upgrade package consists of a paired container format upgrade package and a digital signature file. The digital signature file is generated by hashing and asymmetric encryption of the container format upgrade package using a private key that matches the controller type. For resource-constrained slave node controllers, the master node private key is reused for signing. The signature integrity verification module is used by the master node controller to determine whether the signed upgrade package contains a container format upgrade package and a digital signature file. The compliance verification module is used by the master node controller to call the public key preset in the secure storage area to verify the format of the digital signature file, so as to ensure that the digital signature file conforms to the preset encoding rules. The signature verification module is used by the master node controller to perform signature verification on the digitally signed file based on the public key if the format verification passes. The upgrade package distribution module is used to decompress the container format upgrade package after the signature verification is passed to obtain the upgrade content of the node controller to be upgraded, and to perform differentiated distribution based on the private key category corresponding to the signed upgrade package. The differentiated distribution includes: for slave nodes that reuse the master node's private key for signing, extracting their upgrade content and calculating the cyclic redundancy check value for distribution; for slave nodes that use their own slave node's private key for signing, transparently transmitting the paired container format upgrade package and digital signature file. The execution module is used by the node controller to be upgraded to perform verification and return the result after receiving the issued upgrade content and CRC check value, or after receiving the transparently transmitted signed upgrade package.

[0014] Thirdly, the present invention provides an electronic device, including a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the upgrade package signature verification method provided in the first aspect above.

[0015] Fourthly, the present invention provides a computer storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the upgrade package signature verification method provided in the first aspect above.

[0016] This invention brings the following beneficial effects: This invention provides a method, apparatus, electronic device, and computer storage medium for signing and verifying upgrade packages. The method includes: in response to an upgrade request, a master node controller obtains an upgrade file group; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container-format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container-format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node's private key is reused for signing; the master node controller determines whether the signed upgrade package contains a container-format upgrade package and a digital signature file; if so, the master node controller calls a public key preset in a secure storage area to verify the format of the digital signature file to ensure that the digital signature file conforms to preset encoding rules; if the format verification passes, the master node controller... The digital signature file is verified using a public key. Upon successful verification, the container-format upgrade package is decompressed to obtain the upgrade content for the node controller to be upgraded. Differential distribution is then performed based on the private key category corresponding to the signed upgrade package. This differential distribution includes: for slave nodes that reuse the master node's private key for signing, extracting their upgrade content and calculating a cyclic redundancy check value before distribution; for slave nodes that use their own slave node's private key for signing, transmitting the paired container-format upgrade package and digital signature file. The node controller to be upgraded receives the transmitted upgrade content and CRC check value, or receives the transmitted signed upgrade package, performs verification, and provides feedback on the result. Through the master node's centralized verification and differential distribution mechanism, combined with the reuse of the master node's private key and CRC check, an efficient, reliable, and easily deployable lightweight solution for vehicle-side software upgrades is provided, significantly improving upgrade efficiency and system compatibility. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A flowchart of an upgrade package signature verification method provided in an embodiment of the present invention; Figure 2A key allocation logic diagram provided for an embodiment of the present invention; Figure 3 A logic diagram for generating a container format upgrade package file is provided in an embodiment of the present invention; Figure 4 A logic diagram for generating a signed upgrade package file is provided in this embodiment of the invention; Figure 5 A master node proxy signature logic diagram provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an upgrade package signature verification device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0019] Icons: 310 - Upgrade package acquisition module; 320 - Signature integrity verification module; 330 - Compliance verification module; 340 - Signature verification module; 350 - Upgrade package distribution module; 360 - Execution module; 400 - Memory; 401 - Processor; 402 - Bus; 403 - Communication interface. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0023] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this invention is in use. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. In addition, the terms "first," "second," "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] Furthermore, terms such as "horizontal," "vertical," and "sag" do not imply that components must be absolutely horizontal or suspended, but rather that they can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal relative to "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0025] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0027] Example 1 See Figures 1 to 5 The accompanying drawings illustrate an embodiment of the present invention that provides a method for verifying and signing upgrade packages, comprising: In step S102, in response to the upgrade request, the master node controller obtains an upgrade file group; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node private key is reused for signing.

[0028] Specifically, when a vehicle detects an upgrade request (e.g., inserting a USB drive containing the upgrade package), the master node controller (usually the vehicle's main controller) reads the upgrade file group from a designated storage medium. The core of this file group is the "signed upgrade package," which consists of a paired "container-format upgrade package" (e.g., a CBF file) and a "digital signature file" (e.g., a .rsa file). The generation of the signature file relies on a private key that strictly matches the target controller type and employs hashing and asymmetric encryption techniques. Specifically, for resource-constrained slave node controllers (e.g., vehicle infotainment screens), the master node controller's private key is reused for signing. This high-strength signature ensures the authenticity and integrity of the software from the source, complying with regulatory requirements. Simultaneously, allowing slave nodes to reuse the master node's key avoids complex key storage and management within resource-constrained terminals, significantly reducing the complexity and cost of unified security management in multi-vendor heterogeneous hardware environments, paving the way for subsequent lightweight verification.

[0029] Furthermore, in some preferred embodiments of the present invention, before the step of the master node controller obtaining the upgrade file group in response to the upgrade request, the method further includes: converting the initial software package into a container format upgrade package; matching the corresponding private key according to the controller name identified in the container format upgrade package; performing hash operation and asymmetric encryption on the container format upgrade package using the matched private key to generate a corresponding digital signature file; and packaging the container format upgrade package and the corresponding digital signature file to determine it as a signed upgrade package.

[0030] Specifically, firstly, the various initial software packages provided by the vendor (such as S19, hex, bin, etc.) need to be converted into standardized container format upgrade packages (CBF) after filling in the necessary controller metadata (such as name and version) using a dedicated tool. This solves the compatibility problem of multiple source formats. Then, the key management system automatically matches the corresponding signing private key by parsing the controller name in the CBF file. For slave node controllers, due to resource constraints, their signature reuses the master node's private key. Next, the matched private key is used to perform hash operations (such as SHA512) and RSA encryption (such as RSA4096 with PSS) on the CBF file, generating the corresponding digital signature file (.rsa) within the Hardware Security Module (HMS). Finally, the CBF file and the .rsa file are paired and packaged to form a complete signed upgrade package. This process, through centralized and automated key matching and signature generation, ensures the strength and consistency of the signature. At the same time, the key reuse strategy greatly simplifies the key distribution and management system, laying a reliable foundation for efficient and unified signature verification at the vehicle end.

[0031] In step S104, the master node controller determines whether the signed upgrade package contains a container format upgrade package and a digital signature file.

[0032] Specifically, after receiving the upgrade file group, the master node controller does not immediately begin complex cryptographic verification. Instead, it first performs a lightweight but critical file integrity check: confirming that each "signed upgrade package" contains both its required "container format upgrade package" (e.g., .cbf) and "digital signature file" (e.g., .rsa). If either file is missing, the entire upgrade process is immediately terminated. This effectively intercepts incomplete data packets caused by transmission errors, storage corruption, or malicious tampering, preventing the system from wasting resources on incomplete or invalid data (such as calculating hashes or attempting signature verification). As a fail-fast mechanism, it improves the robustness and efficiency of the upgrade process, ensuring that only structurally complete data packets can proceed to the more resource-intensive verification stages.

[0033] Step S106: If yes, the master node controller calls the public key preset in the secure storage area to verify the format of the digital signature file, so as to ensure that the digital signature file conforms to the preset encoding rules.

[0034] Specifically, after the master node controller confirms the file's completeness, it invokes the corresponding public key, pre-securely stored within the hardware security area, to perform format verification on the digital signature file (.rsa). This verification primarily checks whether the signature file conforms to predetermined encoding rules, such as the compliance of the PSS (Probabilistic Signature Scheme) padding scheme. The purpose of format verification is to identify and reject signature files that, although present, have obvious structural errors or non-compliant encoding. Compared to the complete signature verification operation, the computational overhead of format verification is minimal. This step is equivalent to setting up a fast "pre-check" channel before the expensive formal "security check" (signature verification), which can filter out low-level format errors in advance, avoiding the waste of valuable computing resources on complex decryption and hash comparison operations that are bound to fail later, thereby optimizing the resource utilization efficiency and execution speed of the entire signature verification process.

[0035] Step S108: If the format verification passes, the master node controller performs signature verification on the digital signature file based on the public key.

[0036] Specifically, once the digital signature file passes format verification, the master node controller verifies the signature using the corresponding public key. The standard verification process includes: calculating a hash value H1 on the container format upgrade package (.cbf) using the same hash algorithm; simultaneously, decrypting the digital signature file (.rsa) using the public key to obtain the original hash value H2 embedded in the signature; and finally comparing H1 and H2 for complete consistency. If they match, it proves that the upgrade package content has been complete since the signature was made and was indeed issued by the authorized party holding the corresponding private key, thus the verification is successful. Centralizing the execution of high-strength cryptographic verification required by regulations (such as RSA4096) on the relatively resource-rich master node controller ensures the reliability of the security baseline while completely relieving resource-constrained slave nodes of the burden of performing such heavy computations, which is key to achieving the "lightweight" goal.

[0037] Furthermore, in some preferred embodiments of the present invention, the step of the master node controller performing signature verification on the digital signature file based on the public key includes: performing hash calculation on the container format upgrade package and decryption verification on the digital signature file in parallel, and determining that the signature verification is successful when the hash calculation result is consistent with the hash value obtained from decryption.

[0038] Specifically, compared to traditional signature verification methods that may involve sequential hash calculations and decryption verification, in this embodiment of the invention, the master node controller can execute two subtasks in parallel: first, perform hash calculations on the container format upgrade package (.cbf); second, use the public key to decrypt the digital signature file (.rsa) to extract the embedded hash value. Once both tasks are completed, the results are directly compared. This parallel processing method fully utilizes the multi-core or pipelined capabilities of modern processors, transforming the originally sequential time aggregation into parallel time overlap, effectively shortening the overall time from the start of signature verification to obtaining the result. This is particularly beneficial for batch upgrade scenarios involving multiple large upgrade packages, significantly compressing the centralized signature verification time of the master node, thereby accelerating the entire vehicle-side software upgrade process and improving upgrade efficiency.

[0039] Step S110: After the signature verification is successful, the container format upgrade package is decompressed to obtain the upgrade content of the node controller to be upgraded, and differentiated distribution is performed based on the private key category corresponding to the signed upgrade package; wherein, the differentiated distribution includes: for the slave node that reuses the master node's private key for signing, its upgrade content is extracted and a cyclic redundancy check value is calculated and distributed; for the slave node that uses its own slave node's private key for signing, the paired container format upgrade package and digital signature file are transparently transmitted.

[0040] Specifically, once the signature verification is successful, the master node controller decompresses the container-format upgrade package (.cbf) and extracts the specific upgrade content (such as binary data and configuration files) tailored to different controllers. Then, based on the type of private key used to initially sign the upgrade package, a "differentiated distribution" is performed: for slave nodes that reuse the master node's private key for signing (such as screens and AR-HUDs), the master node extracts its unique upgrade content, calculates a lightweight Cyclic Redundancy Check (CRC) value, and then distributes the "upgrade content + CRC check value"; for slave nodes that use their own independent private key for signing (such as TBOX), the master node maintains the integrity of its original .cbf and .rsa file pairs, without decompression or content extraction, and directly passes them to the target controller. The ingenuity of this differentiated mechanism lies in matching security responsibility with computational burden: resource-constrained nodes only need to perform simple CRC checks, while nodes with full signature verification capabilities receive the original signed package and verify it themselves. This ensures the security and trustworthiness of the entire chain while achieving optimal allocation of the overall system's computational load.

[0041] Furthermore, in some preferred embodiments of the present invention, differentiated distribution also includes: for upgrades to the master node controller itself, transferring the upgrade content to the internal upgrade module for upgrade and self-test execution.

[0042] Specifically, for the master node controller's own software upgrade, after decompressing the .cbf file and obtaining the corresponding upgrade content, the distribution logic directly transfers this content to the software upgrade management module within the master node. This internal module is responsible for performing specific operations such as erasing and writing to its own storage area and updating programs. After the upgrade is completed, it executes a preset self-check program to ensure its own functionality is normal. This process modularizes and closes the upgrade process of the master node itself, clearly separating its upgrade logic from the distribution logic of other nodes, which is beneficial for a clear system architecture and reliable management of the upgrade process. It ensures that the master node controller, as the "brain" of the entire upgrade process, can also safely and orderly complete its own update after completing the security verification and distribution to other nodes.

[0043] Step S112: The node controller to be upgraded receives the sent upgrade content and CRC check value, or receives the transparently transmitted signed upgrade package, performs verification, and feeds back the result.

[0044] Specifically, for the slave node (reusing the master node's key) receiving "upgrade content + CRC checksum", after receiving the data, it recalculates the CRC value for the upgrade content and compares it with the sent CRC checksum, using I... 2The C-type bus feeds back the verification results to the master node. For slave nodes receiving the transparently transmitted "original .cbf + .rsa file pair" (using their own keys), they invoke their built-in signature verification module, using their locally pre-set public key to perform a complete digital signature verification of the original signature packet, and then feed back the result. This hierarchical verification mechanism ensures that regardless of the path taken, each controller undergoes a final verification matching its security requirements and resource capabilities before applying new software. This allows resource-constrained nodes to complete the final confirmation of data integrity with extremely low computational overhead (CRC calculation), while functionally complex nodes maintain strong end-to-end security verification, thus achieving comprehensive and reliable security at the system level with minimal overall resource consumption.

[0045] Furthermore, in some preferred embodiments of the present invention, the method further includes: after all upgrades are completed, the master node controller securely erases the temporary key and intermediate calculation results stored in memory, and writes the upgrade process, timestamps and operation results into the encrypted log system.

[0046] Specifically, firstly, after all upgrade and verification operations are completed, the master node controller proactively and securely erases sensitive intermediate data generated during temporary storage or computation in memory, such as temporarily loaded keys and hash calculation results. Following the security principle of "minimizing data retention," this eliminates the risk of sensitive information remaining in volatile storage and being maliciously extracted, enhancing system runtime security. Secondly, key events throughout the upgrade process (such as start, signature verification results, distribution actions, terminal feedback, and failure rollback), along with precise timestamps and operation results, are recorded in an encrypted log system. This provides an immutable traceability basis for problem diagnosis and system maintenance, and also meets the automotive industry's compliance requirements for auditable and traceable software update processes, constituting a complete upgrade security lifecycle management system.

[0047] Furthermore, in some preferred embodiments of the present invention, the method further includes: if any step in format verification, signature verification, or verification of the node controller to be upgraded fails, terminating the current and subsequent upgrade process, and triggering a security rollback mechanism to restore all controllers involved to the software version before the upgrade.

[0048] Specifically, if any of the three core security steps—format verification, master node signature verification, or final verification by any terminal controller—fail, the entire upgrade process will be immediately terminated. Furthermore, the system will trigger a pre-defined "security rollback mechanism," which aims to restore the software state of all controllers involved in this upgrade (including the master node and partially upgraded slave nodes) to the exact version prior to the start of the upgrade attempt. This "one-vote veto" and "automatic rollback" mechanism ensures the atomicity and security of the upgrade process. It effectively prevents the entire vehicle system from being in a dangerous "half-upgrade" state due to the failure of a single component upgrade, greatly improving the reliability of OTA or USB upgrades and the security of the entire vehicle system, avoiding the risk of system bricking.

[0049] Furthermore, in some preferred embodiments of the present invention, the controller using the master node private key includes: a vehicle master controller, a screen controller, and an augmented reality head-up display controller; the controller using the slave node private key includes: an in-vehicle telematics controller, an emergency call controller, and an automatic parking assist controller; wherein, the master node controller is the vehicle master controller.

[0050] Specifically, in vehicle upgrade scenarios, controllers using the master node's private key (i.e., reused key) typically include the vehicle's main controller (Host, which is also the master node), the display controller, and the augmented reality head-up display controller (AR-HUD). These controllers often have high real-time requirements or relatively limited hardware resources, and reused keys simplify their security design. Controllers using their own slave node private keys typically include in-vehicle telematics controllers (TBOX), emergency call controllers (ECALL), and automatic parking assist controllers (APA). These controllers usually come from different specialized suppliers, have independent security chips or strong processing capabilities, and their functional modules may involve more stringent external compliance certifications. Therefore, maintaining their independent end-to-end signature verification chain is more appropriate. This classification key management strategy based on controller functions, resources, and supply chain characteristics allows this lightweight signature verification method to flexibly adapt to the complex heterogeneous electronic and electrical architecture within vehicles, achieving optimal overall efficiency while ensuring security.

[0051] This invention provides a method for signing and verifying upgrade packages, comprising: in response to an upgrade request, a master node controller obtains an upgrade file group; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container-format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container-format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node's private key is reused for signing; the master node controller determines whether the signed upgrade package contains a container-format upgrade package and a digital signature file; if so, the master node controller calls a public key preset in a secure storage area to verify the format of the digital signature file to ensure that the digital signature file conforms to preset encoding rules; if the format verification passes, the master node controller performs digital signature based on the public key. The file undergoes signature verification. Upon successful verification, the container-format upgrade package is decompressed to obtain the upgrade content for the node controller to be upgraded. Differential distribution is then performed based on the private key category corresponding to the signed upgrade package. This differential distribution includes: for slave nodes that reuse the master node's private key for signing, extracting their upgrade content and calculating a cyclic redundancy check value before distribution; for slave nodes that use their own slave node's private key for signing, transparently transmitting the paired container-format upgrade package and digital signature file; the node controller to be upgraded receives the distributed upgrade content and CRC check value, or, upon receiving the transparently transmitted signed upgrade package, performs verification and returns the result. Through the master node's centralized signature verification and differential distribution mechanism, combined with the reuse of the master node's private key and CRC check, an efficient, reliable, and easily deployable lightweight solution for vehicle-side software upgrades is provided, significantly improving upgrade efficiency and system compatibility.

[0052] Example 2 Based on the above embodiments, this invention provides an upgrade package signature verification device, see [link to relevant documentation]. Figure 6 The diagram shown is a structural schematic of an upgrade package signature verification device provided in an embodiment of the present invention. The device includes: The upgrade package acquisition module 310 is used to acquire an upgrade file group in response to an upgrade request; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node private key is reused for signing.

[0053] The signature integrity verification module 320 is used by the master node controller to determine whether the signed upgrade package contains the container format upgrade package and the digital signature file.

[0054] The compliance verification module 330 is used, if so, for the master node controller to call the public key preset in the secure storage area to perform format verification on the digital signature file, so as to ensure that the digital signature file conforms to the preset encoding rules.

[0055] The signature verification module 340 is used to perform signature verification on the digital signature file based on the public key if the format verification passes.

[0056] The upgrade package distribution module 350 is used to decompress the container format upgrade package after the signature verification is passed to obtain the upgrade content of the node controller to be upgraded, and to perform differentiated distribution based on the private key category corresponding to the signed upgrade package; wherein, the differentiated distribution includes: for slave nodes that reuse the master node's private key signature, extracting its upgrade content and calculating the cyclic redundancy check value and distributing it; for slave nodes that use their own slave node private key signature, transparently transmitting the paired container format upgrade package and digital signature file.

[0057] The execution module 360 ​​is used to perform verification and feedback the result after the upgraded node controller receives the sent upgrade content and CRC check value, or after receiving the transparently transmitted signed upgrade package.

[0058] Furthermore, in some preferred embodiments of the present invention, the upgrade package distribution module 350 is also used for upgrading the master node controller itself, transferring the upgrade content to the internal upgrade module for upgrade and self-test.

[0059] Furthermore, in some preferred embodiments of the present invention, the apparatus further includes: an upgrade package processing module, configured to convert the initial software package into a container format upgrade package; match the corresponding private key according to the controller name identified in the container format upgrade package; perform hash operation and asymmetric encryption on the container format upgrade package using the matched private key to generate a corresponding digital signature file; and package the container format upgrade package and the corresponding digital signature file into a signed upgrade package.

[0060] Furthermore, in some preferred embodiments of the present invention, the signature verification module 340 is used to perform hash calculation of the container format upgrade package and decryption verification of the digital signature file in parallel, and to determine that the signature verification is successful when the hash calculation result is consistent with the hash value obtained from decryption.

[0061] Furthermore, in some preferred embodiments of the present invention, the apparatus further includes: a post-processing module, used to securely erase the temporary key and intermediate calculation results stored in memory after all upgrades are completed, and write the upgrade process, timestamp and operation results into the encrypted log system.

[0062] Furthermore, in some preferred embodiments of the present invention, the apparatus further includes: an upgrade rollback module, used to terminate the current and subsequent upgrade process and trigger a security rollback mechanism to restore all controllers involved to the software version before the upgrade when any step in format verification, signature verification or verification of the node controller to be upgraded fails.

[0063] Furthermore, in some preferred embodiments of the present invention, the controller using the master node private key includes: a vehicle master controller, a screen controller, and an augmented reality head-up display controller; the controller using the slave node private key includes: an in-vehicle telematics controller, an emergency call controller, and an automatic parking assist controller; wherein, the master node controller is the vehicle master controller.

[0064] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the upgrade package signing and verification device described above can be referred to the corresponding process in the aforementioned embodiments of the upgrade package signing and verification method, and will not be repeated here.

[0065] Example 3 This invention also provides an electronic device for running an upgrade package signature verification method; see [link to related documentation]. Figure 7 The schematic diagram of an electronic device provided by the embodiment of the present invention shown below includes a memory 400 and a processor 401. The memory 400 is used to store one or more computer instructions, which are executed by the processor 401 to implement the above-mentioned upgrade package signature verification method.

[0066] Furthermore, Figure 7 The electronic device shown also includes a bus 402 and a communication interface 403. The processor 401, the communication interface 403 and the memory 400 are connected via the bus 402.

[0067] The memory 400 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 403 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 402 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0068] Processor 401 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 401 or by instructions in software form. Processor 401 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 400, and processor 401 reads information from memory 400 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0069] This invention also provides a computer storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned upgrade package signature verification method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0070] The computer program product of the upgrade package signing and verification method, apparatus and electronic device provided in the embodiments of the present invention includes a computer storage medium storing program code. The instructions included in the program code can be used to execute the methods in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

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

[0072] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0073] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying and signing upgrade packages, characterized in that, include: In response to an upgrade request, the master node controller obtains an upgrade file group; wherein the upgrade file group includes at least one signed upgrade package; wherein the signed upgrade package consists of a paired container format upgrade package and a digital signature file; the digital signature file is generated by hashing and asymmetric encryption of the container format upgrade package using a private key matching the controller type; for resource-constrained slave node controllers, the master node private key is reused for signing; The master node controller determines whether the signed upgrade package contains the container format upgrade package and the digital signature file; If so, the master node controller calls the public key preset in the secure storage area to perform format verification on the digital signature file to ensure that the digital signature file conforms to the preset encoding rules; If the format verification passes, the master node controller performs signature verification on the digital signature file based on the public key; After the signature verification is successful, the container format upgrade package is decompressed to obtain the upgrade content of the node controller to be upgraded, and differentiated distribution is performed based on the private key category corresponding to the signed upgrade package; wherein, the differentiated distribution includes: for slave nodes that reuse the master node's private key for signing, extracting their upgrade content and calculating the cyclic redundancy check value for distribution; for slave nodes that use their own slave node's private key for signing, transparently transmitting the paired container format upgrade package and digital signature file; The node controller to be upgraded receives the issued upgrade content and CRC check value, or receives the transparently transmitted signed upgrade package, performs verification, and feeds back the result.

2. The upgrade package signature verification method according to claim 1, characterized in that, The differentiated distribution also includes: For upgrades to the master node controller itself, the upgrade content is transferred to the internal upgrade module for upgrade and self-test execution.

3. The upgrade package signature verification method according to claim 1, characterized in that, Before the step of the master node controller obtaining the upgrade file group in response to the upgrade request, the method further includes: Convert the initial software package into the container format upgrade package; Match the corresponding private key based on the controller name identified in the container format upgrade package; The container format upgrade package is hashed and asymmetric encrypted using the matching private key to generate a corresponding digital signature file; The container format upgrade package and the corresponding digital signature file are packaged together to form the signed upgrade package.

4. The upgrade package signature verification method according to claim 1, characterized in that, The master node controller performs a signature verification step on the digital signature file based on the public key, including: The hash calculation of the container format upgrade package and the decryption verification of the digital signature file are performed in parallel, and the signature verification is deemed successful when the hash calculation result is consistent with the hash value obtained from decryption.

5. The upgrade package signature verification method according to claim 1, characterized in that, The method further includes: After the entire upgrade is completed, the master node controller securely erases the temporary key and intermediate calculation results stored in memory, and writes the upgrade process, timestamps and operation results into the encrypted log system.

6. The upgrade package signature verification method according to claim 1, characterized in that, The method further includes: If any step in the format verification, signature verification, or verification of the node controller to be upgraded fails, the current and subsequent upgrade process will be terminated, and a security rollback mechanism will be triggered to restore all controllers involved to the software version before the upgrade.

7. The upgrade package signature verification method according to any one of claims 1 to 6, characterized in that, The controllers using the master node's private key include: the vehicle master controller, the screen controller, and the augmented reality head-up display controller; the controllers using the slave node's private key include: the vehicle telematics controller, the emergency call controller, and the automatic parking assist controller; wherein, the master node controller is the vehicle master controller.

8. A device for verifying and signing upgrade packages, characterized in that, include: The upgrade package acquisition module is used to acquire an upgrade file group from the master node controller in response to an upgrade request. The upgrade file group includes at least one signed upgrade package. Each signed upgrade package consists of a paired container-format upgrade package and a digital signature file. The digital signature file is generated by hashing and asymmetric encryption of the container-format upgrade package using a private key matching the controller type. For resource-constrained slave node controllers, the master node's private key is reused for signing. A signature integrity verification module is used by the master node controller to determine whether the signed upgrade package contains the container format upgrade package and the digital signature file. The compliance verification module is used, if so, for the master node controller to call the public key preset in the secure storage area to perform format verification on the digital signature file, so as to ensure that the digital signature file conforms to the preset encoding rules; The signature verification module is used so that if the format verification passes, the master node controller performs signature verification on the digital signature file based on the public key. The upgrade package distribution module is used to decompress the container format upgrade package after the signature verification is passed to obtain the upgrade content of the node controller to be upgraded, and to perform differentiated distribution based on the private key category corresponding to the signed upgrade package; wherein, the differentiated distribution includes: for slave nodes that reuse the master node's private key signature, extracting its upgrade content and calculating the cyclic redundancy check value for distribution; for slave nodes that use their own slave node private key signature, transparently transmitting the paired container format upgrade package and digital signature file; The execution module is used to perform verification and return the result after the upgraded node controller receives the issued upgrade content and CRC check value, or receives the transparently transmitted signed upgrade package.

9. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the upgrade package signing and verification method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which, when invoked and executed by the processor, cause the processor to implement the upgrade package signature verification method according to any one of claims 1 to 7.

Images