Method, device and system for secure release and verification of version file upgrade

Abstract

This application relates to a secure method, apparatus, and system for publishing and verifying versioned files. The method includes: obtaining multiple member files corresponding to the versioned file to be published; generating a total version hash value based on the file hash values ​​of each member file; digitally signing the total version hash value using the private key of the sending end to generate a target digital signature; encapsulating the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and publishing the target version package for verification and upgrade by the receiving end. The secure publishing and verification method, apparatus, and system for versioned files involved in this application can revolutionize the traditional fragmented and vulnerable mode of multi-file version publishing and verification into a self-contained, atomic, and secure binary package processing scheme with strong authentication and integrity verification, fundamentally eliminating the risks of file tampering and source forgery.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and more specifically, to a method, apparatus, and system for the secure release and verification upgrade of version files. Background Technology

[0002] In scenarios such as software release, embedded system upgrades, and firmware updates, the integrity and authenticity of version files (such as platform packages, driver packages, and image files) are the core foundation of system security. Any malicious tampering with version files (such as implanting backdoors or viruses) or forgery of their origin (such as attackers impersonating official release channels) can lead to serious security consequences such as device malfunction, data leakage, or even the collapse of the entire system.

[0003] Currently, the industry widely adopts Cyclic Redundancy Check (CRC) technology as the basic means of protecting the integrity of version files. Its typical implementation process is as follows: During the version file generation stage, the publisher calculates the CRC check value of the original version file and appends it to the end of the file or a specific header to form the final published file; during the reception and verification stage, the receiver recalculates the CRC value of the received file and compares it with the check value carried in the file. If the two match, it is determined that the file has not been tampered with during transmission.

[0004] like Figure 1 As shown, in the prior art, during the version file generation stage, the publisher calculates the CRC checksum of the original version file and appends it to the end of the file or a specific header to form the final published file; during the reception and verification stage, the receiver recalculates the CRC value of the received file and compares it with the checksum carried in the file. If the two match, it is determined that the file has not been tampered with during transmission.

[0005] With the evolution of attack techniques, schemes relying solely on CRC checksums have exposed the following serious security flaws and technical bottlenecks: 1. Weak resistance to malicious tampering: CRC is essentially an error detection code based on polynomial division, designed to detect non-malicious random transmission errors. Its algorithm is public and linear; an attacker can easily recalculate and update the corresponding CRC value after modifying the file content, making the tampering undetectable to the receiver. This cannot defend against any intentional attack.

[0006] 2. Complete lack of authentication mechanism: CRC checksums can only verify the "consistency" of data, but cannot answer the crucial question of "where the data came from." The recipient has no way of verifying whether the file originated from a trusted publisher (such as a software developer or device manufacturer). Attackers can easily forge a malicious version file containing the correct CRC value, impersonate an official update, and distribute it, thereby launching a supply chain attack.

[0007] 3. Single layer of integrity protection: The CRC checksum itself is part of the file and is "protected" along with other data blocks, which is logically paradoxical. Once the entire file is forged, its internal checksum naturally loses its reliable benchmark, causing the entire verification mechanism to fail.

[0008] Therefore, a new method, device, and system for secure release, verification, and upgrade of version files are needed.

[0009] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0010] In view of this, this application provides a secure method, apparatus and system for publishing and verifying version files, which can transform the traditional fragmented and vulnerable mode of publishing and verifying multiple file versions into a self-contained, atomic secure binary package processing scheme with strong identity authentication and integrity verification, fundamentally eliminating the risk of file tampering and source forgery.

[0011] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0012] According to one aspect of this application, a secure method for publishing and verifying version files is proposed. This method can be used on a sending end and includes: obtaining multiple member files corresponding to the version file to be published; generating a total version hash value based on the file hash values ​​of each member file; digitally signing the total version hash value using the sending end's private key to generate a target digital signature; encapsulating the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and publishing the target version package for verification and upgrading by a receiving end.

[0013] In one exemplary embodiment of this application, generating a version total hash value based on the file hash values ​​of each member file includes: performing hash calculations on each member file to obtain a corresponding file hash value; and generating a version total hash value based on the file hash values.

[0014] In one exemplary embodiment of this application, generating a version total hash value based on each of the file hash values ​​includes: arranging each of the file hash values ​​in a predetermined file order; concatenating the arranged file hash values ​​in binary form to obtain a concatenated data block; and performing a hash operation on the concatenated data block to obtain the version total hash value.

[0015] In one exemplary embodiment of this application, generating a version total hash value based on the hash values ​​of each file includes: constructing a hash tree using the hash values ​​of each file as leaf nodes; when the number of leaf nodes is odd, copying the last leaf node to form an even number of nodes; concatenating the hash values ​​of adjacent nodes and performing hash operations to obtain the hash value of the parent node; recursively performing the parent node generation operation until the root node hash value is obtained; and determining the root node hash value as the version total hash value.

[0016] According to one aspect of this application, a secure method for publishing and verifying version files is proposed. This method can be used at a receiving end and includes: obtaining a target version package; parsing the target version package to obtain each member file and a target digital signature; re-hashing each member file to generate a total verification hash value; verifying the target digital signature using a pre-stored public key to obtain the target total hash value; and performing a corresponding version upgrade operation when the total verification hash value matches the target total hash value.

[0017] In one exemplary embodiment of this application, performing the corresponding version upgrade operation includes: releasing each of the parsed member files to a target storage location; and performing an installation operation or a version update operation based on the released member files.

[0018] In one exemplary embodiment of this application, the method further includes: terminating the upgrade process and outputting verification failure information when the total verification hash value is inconsistent with the target total hash value.

[0019] According to one aspect of this application, a secure publishing and verification upgrade device for version files is proposed. This device can be used at a sending end and includes: a file module for acquiring multiple member files corresponding to the version file to be published; a hash module for generating a total version hash value based on the file hash values ​​of each member file; a signature module for digitally signing the total version hash value using the sending end's private key to generate a target digital signature; an encapsulation module for encapsulating the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and a publishing module for publishing the target version package for verification and upgrade by a receiving end.

[0020] According to one aspect of this application, a secure publishing and verification upgrade device for version files is proposed. This device can be used at a receiving end and includes: an acquisition module for acquiring a target version package; a parsing module for parsing the target version package to obtain each member file and a target digital signature; a calculation module for re-hashing each member file to generate a total verification hash value; a verification module for verifying the target digital signature using a pre-stored public key to obtain the target total hash value; and an upgrade module for performing a corresponding version upgrade operation when the total verification hash value matches the target total hash value.

[0021] According to one aspect of this application, a secure publishing and verification upgrade system for version files is proposed. The system includes: a sending end, configured to acquire multiple member files corresponding to the version file to be published; generate a total version hash value based on the file hash values ​​of each member file; digitally sign the total version hash value using the sending end's private key to generate a target digital signature; encapsulate the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; publish the target version package for verification and upgrade by a receiving end; and a receiving end, configured to acquire the target version package; parse the target version package to obtain each member file and the target digital signature; re-hash each member file to generate a verification hash value; verify the target digital signature using a pre-stored public key to obtain the target hash value; and perform a corresponding version upgrade operation when the verification hash value matches the target hash value.

[0022] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0023] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0024] According to the secure release, verification, and upgrade method, apparatus, and system for version files of this application, the following steps are taken: First, multiple member files corresponding to the version file to be released are obtained. Then, a total version hash value is generated based on the file hash values ​​of each member file. Next, the total version hash value is digitally signed using the private key of the sending end to generate a target digital signature. Finally, the multiple member files and the target digital signature are encapsulated into a target version package according to a preset package structure, which includes a package header, a file index table, a file data area, and a signature area. The target version package is then released for verification and upgrade by the receiving end. This method revolutionizes the multi-file version release and verification process from a fragmented and vulnerable traditional model into a self-contained, atomic, and secure binary package processing scheme with strong authentication and integrity verification, fundamentally eliminating the risks of file tampering and source forgery.

[0025] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0026] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0027] Figure 1 This is a schematic diagram of the secure release and verification upgrade methods for version files in existing technologies.

[0028] Figure 2 This is a flowchart illustrating a secure release and verification upgrade method for a version file according to an exemplary embodiment.

[0029] Figure 3 This is a schematic diagram illustrating a secure release and verification upgrade method for a version file according to another exemplary embodiment.

[0030] Figure 4 This is a schematic diagram illustrating a secure release and verification upgrade method for a version file according to another exemplary embodiment.

[0031] Figure 5 This is a flowchart illustrating a secure release and verification upgrade method for a version file according to another exemplary embodiment.

[0032] Figure 6 This is a block diagram illustrating a secure release and verification upgrade device for a version file according to an exemplary embodiment.

[0033] Figure 7This is a block diagram illustrating a secure release and verification upgrade apparatus for a version file according to another exemplary embodiment.

[0034] Figure 8 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0035] Figure 9 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0036] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0037] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0038] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0040] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0041] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0042] The technical abbreviations used in this application are explained as follows: CRC check: A mathematical method used to detect whether errors occur in data during transmission or storage. Its core is to generate a small check code (i.e., CRC code) for the original data through specific calculations. The receiver determines the integrity of the data by recalculating and comparing the check code.

[0043] Digital signature: A cryptographic primitive based on asymmetric cryptography (public-key cryptography) used to verify the authenticity, integrity, and non-repudiation of digital messages, software, or documents.

[0044] Hash value: A fixed-length and unique digital fingerprint generated by a hash function, used to uniquely identify and verify the integrity of data blocks of any size.

[0045] Hash tree: A tree-like data structure in which each leaf node stores the hash value of a data block, while non-leaf nodes store the hash value of the combination of the hash values ​​of their child nodes, ultimately forming a "unique fingerprint" representing the integrity of the entire dataset at the root node.

[0046] RSA (Asymmetric Encryption Algorithm): A public-key cryptosystem based on the large number factorization problem. It is a cornerstone algorithm for implementing digital signatures and key exchange.

[0047] In view of the technical deficiencies in the prior art, this application proposes a secure method and system for the release and verification of multiple file versions of software or firmware. The secure release and verification upgrade system for version files may include: The sending end is used to obtain multiple member files corresponding to the version file to be released; generate a total version hash value based on the file hash value of each member file; digitally sign the total version hash value using the sending end's private key to generate a target digital signature; encapsulate the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and publish the target version package so that the receiving end can verify and upgrade. Multiple receiving ends are used to obtain the target version package; parse the target version package to obtain each member file and the target digital signature; re-hash each member file to generate a verification total hash value; verify the target digital signature using a pre-stored public key to obtain the target total hash value; and perform the corresponding version upgrade operation when the verification total hash value matches the target total hash value.

[0048] The core of this application lies in the following: The publisher encapsulates all member files constituting a version (such as the main program module, configuration files, resource libraries, etc.) along with a digital signature generated based on an asymmetric cryptographic algorithm that covers all member files into a self-contained, structured single binary package file (.bin). The receiver only needs to obtain this single file to simultaneously complete the integrity verification of all member files and the publisher's identity authentication.

[0049] The content of this application will be described in detail below with reference to specific embodiments.

[0050] Figure 2 This is a flowchart illustrating a secure release and verification upgrade method for a version file according to an exemplary embodiment. The secure release and verification upgrade method 20 for version files can be applied to a sending end and includes at least steps S202 to S210.

[0051] like Figure 2 As shown, in S202, multiple member files corresponding to the version file to be released are obtained. For example, multiple member files a, b, c, ... such as the main program module file, configuration file, resource file, driver file, dynamic link library file, or image file corresponding to the version can be obtained. These multiple member files together constitute a complete release version. In some embodiments, each member file may originate from the compilation generation directory, version build directory, or a preset version repository. The sending end can determine the set of member files to be released based on the version configuration file, file list, or build script. To ensure the consistency of subsequent total hash calculations, after obtaining the member files, the file name, file length, and file path information of each member file can be standardized, and a corresponding file index relationship can be established.

[0052] In S204, a total version hash value is generated based on the file hash values ​​of each member file. For example, each member file can be hashed separately to obtain its corresponding file hash value; the total version hash value is then generated based on these file hash values.

[0053] In this application, the file hash value can be used to characterize the integrity status of the corresponding member file. The hash algorithm can be SHA-256, SHA-1, SM3, or other fixed-length digest algorithms. Preferably, the SHA-256 algorithm can be used to generate a 256-bit digest value for each member file to reduce the probability of different files generating the same digest value. When calculating the file hash value, the sending end can directly read and calculate the original binary data of the member files to ensure the consistency of hash results across different platforms.

[0054] In one embodiment, generating a version total hash value based on the hash values ​​of each file includes: arranging the hash values ​​of each file in a preset file order; concatenating the arranged hash values ​​in binary form to obtain a concatenated data block; and performing a hash operation on the concatenated data block to obtain the version total hash value.

[0055] For example, the hash values ​​of files can be generated according to a fixed file order, which can be sorted lexicographically by filename, sorted by file path, or sorted according to a preset file list order. When generating the total hash, the hash values ​​corresponding to each member file are concatenated in binary form, forming a continuous binary data block, strictly following the fixed order. Then, a hash operation is performed on the concatenated data block to obtain the total hash value H_original.

[0056] By standardizing the file arrangement order and hash concatenation rules, it can be ensured that the sending and receiving ends generate consistent total hash values ​​when processing the same set of member files, avoiding verification failures due to different file orders. Furthermore, compared to signing multiple member files separately, this application reduces the number of signing objects and improves version release efficiency and receiver verification efficiency by signing a unified total hash value.

[0057] In another embodiment, generating a version total hash value based on the hash values ​​of each file includes: constructing a hash tree using the hash values ​​of each file as leaf nodes; when the number of leaf nodes is odd, copying the last leaf node to form an even number of nodes; concatenating the hash values ​​of adjacent nodes and performing hash operations to obtain the hash value of the parent node; recursively performing the parent node generation operation until the root node hash value is obtained; and determining the root node hash value as the version total hash value.

[0058] More specifically, a tree-based hashing method can be used, where the file hash values ​​corresponding to all member files are used as leaf nodes of the hash tree. If the number of leaf nodes is odd, the last leaf node is copied to form paired nodes. Then, the hash values ​​of adjacent nodes are concatenated and the hash operation is performed again to generate the corresponding parent node hash value. This parent node generation process is recursively executed until a unique root node hash value is generated. This root node hash value is the total version hash value H_original, and its hash tree structure is as follows: Figure 3 As shown.

[0059] By adopting a tree-structured hash table, the organizational complexity of large-scale file collections can be effectively reduced, and hierarchical verification can be supported. For scenarios with a large number of files, abnormal files can be quickly located through local node verification, improving version verification efficiency.

[0060] In S206, the total hash value of the version is digitally signed using the private key of the sending end to generate the target digital signature. For example, the generated total hash value H_original can be used as the signature object, and a digital signature operation can be performed using the private key pre-stored at the sending end to generate the digital signature d. The digital signature algorithm can be an asymmetric cryptographic algorithm such as RSA, ECC, or SM2. Preferably, the RSA algorithm can be used to generate a fixed-length digital signature.

[0061] By digitally signing the total hash value of the version, the digital digest corresponding to the version file can be bound to the publisher's identity. Since the target digital signature can only be verified using the corresponding public key, the receiving end can verify whether the target version package was generated by a trusted publisher, thereby preventing attackers from forging malicious upgrade packages or tampering with the version content.

[0062] Furthermore, since the signature object is a uniformly generated version hash value, the receiving end only needs to perform an asymmetric signature verification operation once to complete the overall integrity verification and identity authentication of multiple member files, reducing the computational overhead caused by signing multiple files separately.

[0063] In step S208, multiple member files and the target digital signature are encapsulated into a target version package according to a preset package structure. The preset package structure includes a package header, a file index table, a file data area, and a signature area. For example, member files a, b, c... and digital signature d are serialized and encapsulated according to a preset binary package structure format to generate a final single version file, version.bin, thus forming a self-describing, self-contained release entity, facilitating unified distribution, storage, and upgrade management.

[0064] In this application, the preset packet structure can be a structured binary packet format, the core structure of which is as follows: Figure 4 As shown. Specifically, the package structure may include: The packet header records basic descriptive information about the target version packet. This basic descriptive information may include the magic number, version number, header length, number of files, packet format version number, signature algorithm identifier, and hash algorithm identifier. By setting the magic number, the receiving end can quickly identify the target version packet type; by setting the version number and packet format version number, compatibility processing between different version structures can be supported.

[0065] A file index table records the index description information corresponding to each member file. This index description information may include file name length, file name, file offset, file data length, and file type identifier. The receiving end can quickly locate the storage location of the corresponding member file in the file data area based on the file index table and accurately parse the original data of each member file.

[0066] The file data area is used to sequentially store the raw binary data of each member file. Multiple member files can be stored in sequence according to the offset information in the file index table to support fast reading and random access.

[0067] A signature area is used to store the target digital signature. This signature area may be located at the end of the target version packet and is used to store digital signature data generated using an asymmetric signature algorithm. For example, it may store a 256-byte RSA digital signature.

[0068] In some embodiments, the signature content corresponding to the target digital signature may cover the packet header, file index table, and file data area to ensure that any change in the structural content of the target version packet will result in signature verification failure, thereby preventing security issues such as file replacement, index tampering, or data forgery.

[0069] The design of self-contained structured binary packages features self-description, self-containment, and unified distribution. It can support the integrated distribution of multiple member files, avoiding problems such as file loss, version mismatch, or incorrect file correspondence during transmission and storage.

[0070] In addition, this package structure has the following advantages: Self-descriptive: Through the packet header and file index table, the receiving end can losslessly parse all member files in the target version packet and restore the original file structure.

[0071] Security: Digital signatures cover the packet header, file index table, and file data area, ensuring that any modification to any area of ​​the target version packet can be detected, thereby improving the overall anti-tampering capability.

[0072] Extensibility: The package structure supports accommodating any number of member files and allows for the addition of new field types or extended functional fields, exhibiting good compatibility and extensibility.

[0073] In step S210, the target version package is published so that the receiving end can verify and upgrade it. For example, the sending end can publish the target version package via network transmission, file server, upgrade platform, mirror site, removable storage medium, or OTA upgrade channel. After obtaining the target version package, the receiving end can perform subsequent version verification and upgrade operations based on the digital signature and member file data in the target version package.

[0074] Since this application uses a single structured version package for unified distribution, the receiving end only needs to obtain a single target version package to complete the integrity verification and upgrade processing of multiple member files, thereby reducing the management complexity caused by the independent transmission of multiple files.

[0075] According to the secure release and verification upgrade method for version files in this application, the following steps are taken: First, multiple member files corresponding to the version file to be released are obtained. Then, a total version hash value is generated based on the file hash values ​​of each member file. Next, the total version hash value is digitally signed using the private key of the sending end to generate a target digital signature. Finally, the multiple member files and the target digital signature are encapsulated into a target version package according to a preset package structure, which includes a package header, a file index table, a file data area, and a signature area. The target version package is then released for verification and upgrade by the receiving end. This method revolutionizes the traditional, fragmented, and vulnerable multi-file version release and verification process into a self-contained, atomic, and secure binary package processing solution with strong authentication and integrity verification, fundamentally eliminating the risks of file tampering and source forgery.

[0076] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0077] Figure 5 This is a flowchart illustrating a secure release and verification upgrade method for a version file according to another exemplary embodiment. Figure 5 The process 50 shown is applicable to the sending end and includes at least steps S502 to S510.

[0078] like Figure 5 As shown, in S502, the target version package is obtained. For example, the receiving end can obtain the target version package (version.bin) through network download, upgrade server, mirror site, removable storage medium, or OTA upgrade channel. After obtaining the target version package, the receiving end can first perform a basic format check on the target version package to confirm that the target version package meets the preset package structure requirements.

[0079] In some embodiments, the magic number, version number, header length, number of files, and package format identifier can be verified by reading the package header information in the target version package to confirm that the target version package belongs to a supported version package type. If a magic number error, abnormal header length, or corrupted package structure is detected, the subsequent upgrade process can be terminated directly.

[0080] Subsequently, the receiving end parses the target version package according to the preset package structure format, and separates the original data corresponding to each member file and the target digital signature d from the target version package.

[0081] In S504, the target version package is parsed to obtain each member file and the target digital signature.

[0082] For example, the receiving end can traverse and parse the file index table based on the number of files recorded in the packet header and the index table offset information to obtain information such as the file name, file offset, file data length, and file type identifier corresponding to each member file.

[0083] Subsequently, the receiving end can read the original binary data of the corresponding member file from the file data area according to the file offset and file length, and extract the target digital signature d from the signature area.

[0084] In some embodiments, the receiving end may also perform boundary validity checks on the offset and data length in the file index table to avoid data out-of-bounds reading problems caused by abnormal packet structure.

[0085] In addition, the receiving end can also verify whether the number of files matches the number of index entries to ensure the integrity of the target version package structure.

[0086] In S506, the hash of each member file is recalculated to generate a total verification hash value.

[0087] In this application, the receiving end uses the same hash algorithm, file arrangement order, and total hash generation rule as the sending end to regenerate the verification total hash value H_total for each member file obtained from parsing, so as to ensure that the generation results of both parties are consistent.

[0088] In one embodiment, for example, the same method and order as the publishing end can be used to calculate the individual file hash value for each member file, and then the file hash values ​​corresponding to each member file can be concatenated end-to-end in binary form to form a continuous binary data block. Subsequently, the hash operation is performed again on the concatenated data block to obtain the total verification hash value H_total.

[0089] In some embodiments, the order of member files can be determined according to lexicographical order of filenames, file path order, or a preset file list order. Using a unified file sorting rule between the receiving and sending ends can avoid the problem of generating different verification hash values ​​due to inconsistent file order.

[0090] In one embodiment, the hash tree structure may be reconstructed independently, for example, using the exact same tree-hash algorithm and calculation rules as the publisher.

[0091] Specifically, the receiving end first recalculates the file hash value for each member file (a, b, c, d...), for example, obtaining H(a), H(b), H(c), H(d)... The file arrangement order is consistent with that of the sending end.

[0092] Then, the hash value of the parent node is recursively calculated. Adjacent nodes are paired according to preset rules, and hash operations are performed accordingly. Calculate H_ab = Hash(H(a) + H(b)); Calculate H_cd = Hash(H(c) + H(d)).

[0093] If the number of nodes in the current layer is odd, then the last node is copied to participate in the calculation of the next layer.

[0094] Then, the concatenation and hash operations are recursively performed on the generated parent nodes until a unique root node hash value is finally generated: H_total = Hash(H_ab + H_cd).

[0095] H_total is the root hash value recalculated by the receiving end.

[0096] By adopting a tree-like hash structure, the receiving end can perform integrity verification on the version package in a hierarchical manner, and can quickly locate the range of abnormal files when partial verification fails, thereby improving the verification efficiency of large-scale file sets.

[0097] In S508, the target digital signature is verified using a pre-stored public key to obtain the target total hash value. For example, the receiving end can invoke a pre-securely stored trusted publisher's public key to perform a signature verification operation on the target digital signature d to obtain the target total hash value H_original corresponding to the target digital signature.

[0098] In some embodiments, the public key may be pre-stored in the device firmware, security chip, trusted execution environment, or system secure storage area to prevent the public key from being illegally replaced.

[0099] The digital signature verification process can employ asymmetric cryptographic algorithms such as RSA, ECC, or SM2. Preferably, the RSA algorithm can be used for digital signature verification.

[0100] By using public key verification, the receiving end can confirm whether the target version package was generated by a trusted publisher and verify whether the target version package has been illegally tampered with during transmission, storage, and distribution.

[0101] Since the signature content corresponding to the target digital signature covers the packet header, file index table, and file data area, any modification to any content in the target version packet will cause the signature verification to fail, thereby improving overall security.

[0102] In step S510, when the verified total hash value matches the target total hash value, a corresponding version upgrade operation is performed. For example, the receiving end compares the verified total hash value H_total with the target total hash value H_original. If they match, it indicates that the member files in the target version package have not been tampered with, and the source of the target version package is trustworthy.

[0103] After the signature verification is successful, the receiving end can release the parsed member files a, b, c... to the corresponding target storage location and perform installation or version update operations.

[0104] In some embodiments, the receiving end can write different member files to the corresponding upgrade area according to the file type. For example, the main program module can be written to the system program area, the configuration file can be written to the configuration storage area, and the resource files can be written to the resource directory.

[0105] In addition, before performing the upgrade operation, the receiving end can also check the target storage space capacity, version compatibility, and device operating status to ensure that the upgrade process is executed normally.

[0106] After the upgrade is completed, the receiving end can also record upgrade logs, version number information, and upgrade time information for subsequent version management and fault tracking.

[0107] In one embodiment, the method further includes: terminating the upgrade process and outputting verification failure information when the total verification hash value is inconsistent with the target total hash value.

[0108] For example, when H_total and H_original are inconsistent, the receiving end determines that the target version package has been tampered with, the file is corrupted, or the source is untrustworthy. In this case, member file release and version update operations are prohibited.

[0109] In some embodiments, the receiving end may output corresponding error codes, log information, or alarm information to indicate the reason for the upgrade failure.

[0110] In addition, you can delete downloaded abnormal version packages, restore historical versions, or roll back to the state before the upgrade to prevent the device from entering an abnormal operating state.

[0111] By performing the upgrade operation only when the overall signature verification passes, multiple member files can be atomically verified as a unified whole, thereby avoiding system anomalies caused by partial file replacement, partial file upgrade success, or inconsistent file versions.

[0112] Compared with the prior art, this application has at least the following beneficial effects: 1. Solved the problem of integrated management and trust of multiple file versions.

[0113] This application transforms the complex model of "multi-file hash distribution + independent signing" into a unified model of "single-file distribution and single-time verification". The receiving end only needs to obtain a single structured version package to complete the unified verification and upgrade of multiple member files, thereby simplifying the version release, distribution and upgrade process.

[0114] 2. An atomic security verification mechanism was constructed.

[0115] This application uses the entire target version package as a unified signature object and a unified total hash value as the basis for integrity verification. The upgrade operation is only performed when all member files have been verified, thereby ensuring the consistency of version upgrades and avoiding the system being in an inconsistent state due to abnormalities in some files.

[0116] 3. Enhanced overall security and reliability.

[0117] Because the target digital signature covers the packet header, file index table, and file data area, an attacker cannot replace any member file in the target version of the packet without breaking the signature.

[0118] Meanwhile, using a single structured version package to uniformly encapsulate multiple member files can avoid problems such as file loss, file mismatch, and version inconsistency during transmission or storage of multiple independent files.

[0119] Furthermore, the asymmetric digital signature mechanism can also be used to authenticate the identity of the publisher, solving the problem that traditional verification mechanisms such as CRC cannot verify the source of the publication.

[0120] 4. Improved the verification efficiency of the receiving end.

[0121] For the receiving end, especially embedded devices, only one asymmetric cryptographic signature verification operation is needed to complete the unified legality verification of multiple member files. Compared with verifying multiple signatures or managing multiple CRC values ​​separately, this reduces computational complexity and system resource consumption, and improves version upgrade efficiency.

[0122] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0123] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0124] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0125] Figure 6 This is a block diagram illustrating a secure release and verification upgrade apparatus for a version file according to another exemplary embodiment. Figure 6 As shown, the secure release and verification upgrade device 60 for version files can be used on the sending end, including: file module 602, hash module 604, signature module 606, encapsulation module 608, and release module 610.

[0126] File module 602 is used to obtain multiple member files corresponding to the version file to be released; Hash module 604 is used to generate a total version hash value based on the file hash values ​​of each member file; The signature module 606 is used to digitally sign the total hash value of the version using the private key of the sender, and generate the target digital signature; The encapsulation module 608 is used to encapsulate multiple member files and the target digital signature into a target version package according to a preset package structure. The preset package structure includes: a package header, a file index table, a file data area, and a signature area. The publishing module 610 is used to publish the target version package so that the receiving end can verify and upgrade it.

[0127] Figure 7 This is a block diagram illustrating a secure release and verification upgrade apparatus for a version file according to an exemplary embodiment. Figure 7 As shown, the secure release and verification upgrade device 70 for version files can be used at the receiving end, including: an acquisition module 702, a parsing module 704, a calculation module 706, a verification module 708, and an upgrade module 710.

[0128] Module 702 is used to obtain the target version package; The parsing module 704 is used to parse the target version package to obtain each member file and the target digital signature; The calculation module 706 is used to re-hash each of the member files to generate a total verification hash value; Verification module 708 is used to verify the target digital signature using a pre-stored public key to obtain the target total hash value; The upgrade module 710 is used to perform a corresponding version upgrade operation when the verified total hash value is consistent with the target total hash value.

[0129] The secure release and verification upgrade device for version files according to this application obtains multiple member files corresponding to the version file to be released; generates a total version hash value based on the file hash values ​​of each member file; digitally signs the total version hash value using the private key of the sending end to generate a target digital signature; encapsulates the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and releases the target version package for verification and upgrade by the receiving end. This method can revolutionize the multi-file version release and verification from the traditional fragmented and vulnerable mode into a self-contained, atomic secure binary package processing scheme with strong identity authentication and integrity verification, fundamentally eliminating the risks of file tampering and source forgery.

[0130] Figure 8 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0131] The following reference Figure 8 To describe an electronic device 800 according to this embodiment of the present application. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0132] like Figure 8 As shown, the electronic device 800 is presented in the form of a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one processing unit 810, at least one storage unit 820, a bus 830 connecting different system components (including storage unit 820 and processing unit 810), a display unit 840, etc.

[0133] The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 810 can perform actions such as... Figure 2 , Figure 5 The steps are shown in the figure.

[0134] The storage unit 820 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 8201 and / or a cache storage unit 8202, and may further include a read-only memory unit (ROM) 8203.

[0135] The storage unit 820 may also include a program / utility 8204 having a set (at least one) program module 8205, such program module 8205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0136] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0137] Electronic device 800 can also communicate with one or more external devices 800' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 800, and / or any device (e.g., router, modem, etc.) that allows electronic device 800 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 850. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 860. Network adapter 860 can communicate with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0138] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 9 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0139] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0140] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0141] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0142] The aforementioned computer-readable medium carries one or more programs. When these programs are executed by a device, the computer-readable medium performs the following functions: acquiring multiple member files corresponding to the version file to be published; generating a total version hash value based on the file hash values ​​of each member file; digitally signing the total version hash value using the private key of the sending end to generate a target digital signature; encapsulating the multiple member files and the target digital signature into a target version package according to a preset package structure, the preset package structure including: a package header, a file index table, a file data area, and a signature area; and publishing the target version package for verification and upgrade by the receiving end.

[0143] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0144] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0145] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for securely publishing and verifying versioned files, the method being applicable to the sending end, characterized in that, include: Retrieve multiple member files corresponding to the version file to be released; Based on the file hash values ​​of each member file, generate the total version hash value; The target digital signature is generated by digitally signing the total hash value of the version using the private key of the sender. According to a preset package structure, multiple member files and the target digital signature are encapsulated into a target version package. The preset package structure includes: a package header, a file index table, a file data area, and a signature area. The target version package is released so that the receiving end can verify and upgrade it.

2. The method as described in claim 1, characterized in that, Based on the file hash values ​​of each member file, a total version hash value is generated, including: Perform hash calculations on each of the member files to obtain the corresponding file hash values; A total version hash value is generated based on the hash values ​​of each of the aforementioned files.

3. The method as described in claim 2, characterized in that, A total version hash value is generated based on the hash values ​​of each of the aforementioned files, including: The hash values ​​of each file are arranged sequentially according to a preset file order; The hash values ​​of the arranged files are concatenated end to end in binary form to obtain a concatenated data block. Perform a hash operation on the concatenated data block to obtain the total hash value of the version.

4. The method as described in claim 2, characterized in that, A total version hash value is generated based on the hash values ​​of each of the aforementioned files, including: Construct a hash tree using the hash values ​​of each file as leaf nodes; When the number of leaf nodes is odd, copy the last leaf node to form an even number of nodes; The hash values ​​of adjacent nodes are concatenated and a hash operation is performed to obtain the hash value of the parent node; Recursively execute the parent node generation operation until the root node hash value is obtained; The root node hash value is determined as the total hash value of the version.

5. A method for securely publishing and verifying version files, which can be used at the receiving end, characterized in that... include: Obtain the target version package; The target version package is parsed to obtain each member file and the target digital signature; Recalculate the hash of each member file to generate a total verification hash value; The target digital signature is verified using a pre-stored public key to obtain the target total hash value; When the verified total hash value matches the target total hash value, the corresponding version upgrade operation is performed.

6. The method as described in claim 5, characterized in that, Perform the corresponding version upgrade operation, including: Release each of the parsed member files to the target storage location; Perform installation or version update operations based on the extracted member files.

7. The method as described in claim 5, characterized in that, Also includes: If the total hash value being verified is inconsistent with the target total hash value, the upgrade process is terminated and a verification failure message is output.

8. A secure release and verification upgrade device for version files, which can be used at the sending end, characterized in that, include: The file module is used to retrieve multiple member files corresponding to the version file to be released. The hash module is used to generate a total version hash value based on the file hash values ​​of each member file. The signature module is used to digitally sign the total hash value of the version using the private key of the sender, and generate the target digital signature; The encapsulation module is used to encapsulate multiple member files and the target digital signature into a target version package according to a preset package structure, wherein the preset package structure includes: a package header, a file index table, a file data area, and a signature area; The publishing module is used to publish the target version package so that the receiving end can verify and upgrade it.

9. A secure release and verification upgrade device for version files, the device being used at a receiving end, characterized in that, include: The acquisition module is used to obtain the target version package; The parsing module is used to parse the target version package to obtain each member file and the target digital signature; The calculation module is used to re-hash each of the member files to generate a total verification hash value; The verification module is used to verify the target digital signature using a pre-stored public key to obtain the target total hash value; The upgrade module is used to perform a corresponding version upgrade operation when the verified total hash value is consistent with the target total hash value.

10. A secure release and verification upgrade system for version files, comprising: The sending end is used to obtain multiple member files corresponding to the version file to be released; Based on the file hash values ​​of each member file, generate the total version hash value; The target digital signature is generated by digitally signing the total hash value of the version using the private key of the sender. According to a preset package structure, multiple member files and the target digital signature are encapsulated into a target version package, the preset package structure including: a package header, a file index table, a file data area, and a signature area; the target version package is then published so that the receiving end can verify and upgrade it. The receiving end is used to obtain the target version package; parse the target version package to obtain each member file and the target digital signature; re-hash each member file to generate a verification total hash value; verify the target digital signature using a pre-stored public key to obtain the target total hash value; and perform the corresponding version upgrade operation when the verification total hash value matches the target total hash value.

Images