Software file integrity protection method and device, equipment and medium

Abstract

The invention discloses a software file integrity protection method and device, equipment and a medium, and relates to the technical field of software integrity protection. The method comprises the following steps: when software is subjected to incremental change every time, performing abstract processing on files associated with the change to obtain corresponding abstract values, and combining the abstract values into an abstract baseline of the change; signature is performed by using a private key, and the signature and the abstract baseline are published along with the change upgrade package; when the integrity of the file in the software needs to be checked, respectively carrying out signature verification on the abstract baselines based on signature data generated by previous incremental changes, and determining a current abstract value of the file; traversing the verified abstract baselines according to any sequence, and searching a target abstract baseline containing file abstract records; and comparing the recorded digest value with the current digest value, and judging whether the integrity verification is successful or not according to the comparison result. Through the technical scheme of the invention, the problems of insufficient signature security in a production environment, overlarge full-quantity signature engineering quantity and the like are solved.

Description

Technical Field

[0001] This invention relates to the field of software integrity protection technology, and in particular to a method, apparatus, device, and medium for protecting the integrity of software files. Background Technology

[0002] To ensure software is not tampered with after installation, a common integrity protection method is to aggregate the digests of multiple files to be protected into a digest baseline and sign it as a whole. This method improves operational efficiency and scalability. However, during incremental software upgrades, the digests of the corresponding files in the digest baseline need to be changed, and the signature value of the digest baseline must be updated synchronously; otherwise, integrity verification will fail. Existing solutions to this problem mainly include: re-signing based on the full file digests after the upgrade (local or remote signing), adding a digest baseline and signing it for the changed files during upgrade package creation, and regenerating and signing the digest baseline for all files during upgrade package creation to overwrite the original baseline. However, these solutions all have drawbacks: local signing is prone to leakage of private keys in the production environment; remote signing faces risks of information leakage and tampering during transmission, as well as network dependency issues; when adding a new digest baseline for changed files, the details and order of changes lack integrity protection, posing security and availability risks; full re-signing and replacement requires adaptation to different original software versions, increasing the workload and management difficulty.

[0003] Therefore, how to provide a solution to the above-mentioned technical problems is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for protecting the integrity of software files, which can achieve integrity protection for partially modified files without exposing the signing private key or introducing additional management complexity (such as change order or timestamps). The specific solution is as follows: Firstly, this application discloses a method for protecting the integrity of software files, including: Each time the software undergoes an incremental change, the files associated with this change are digested to obtain at least one corresponding digest value, and the digest values ​​are merged into a digest baseline for this change. The digest baseline is signed using a private key to obtain signature data, and the digest baseline and the corresponding signature data are released with the upgrade package of this change; When it is necessary to perform integrity verification on target files in the software, the signature baseline is verified based on the signature data generated by each incremental change, and the current digest value of the target file is determined. Traverse the verified digest baselines in any order to find the target digest baseline that contains the digest record of the target file; The record digest value of the target file is obtained from the target digest baseline, and the record digest value is compared with the current digest value so as to determine whether the integrity verification of the target file is successful based on the comparison result.

[0005] Optionally, the step of performing digest processing on the files associated with this change to obtain at least one corresponding digest value includes: For each file added and / or modified in this change, calculate the corresponding first digest value; For each file deleted in this change, the corresponding digest value will be set to a predefined second digest value.

[0006] Optionally, the step of traversing the verified digest baselines in any order to find the target digest baseline containing the digest record of the target file includes: Traverse the verified summary baselines in any order and determine whether the current summary baseline contains a summary record of the target file; If so, then terminate the traversal and determine the current summary baseline as the target summary baseline; If not, continue traversing the remaining summary baselines until a target summary baseline containing the summary record of the target file is found.

[0007] Optionally, the method for protecting the integrity of software files further includes: If no summary record of the target file is found after traversing all verified summary baselines, the integrity verification of the target file is deemed to have failed.

[0008] Optionally, comparing the record digest value with the current digest value to determine whether the integrity verification of the target file was successful based on the comparison result includes: Compare the record summary value with the current summary value; If the record digest value is equal to the current digest value, then the integrity verification of the target file is deemed successful. If the record digest value is not equal to the current digest value, the integrity verification of the target file is determined to have failed.

[0009] Optionally, the method for protecting the integrity of software files further includes: When the number of files associated with the software during this change exceeds a preset threshold, a full overwrite installation upgrade method is triggered.

[0010] Optionally, the upgrade method that triggers a full-scale installation includes: Generate and sign the corresponding full digest baseline for all software files, and delete all stored historical digest baselines and corresponding signature data during software upgrade and installation.

[0011] Secondly, this application discloses a software file integrity protection device, comprising: The change file summary processing module is used to perform summary processing on the files associated with each incremental change to obtain at least one corresponding summary value, and merge the summary values ​​into a summary baseline for this change. The signature release module is used to sign the digest baseline using a private key to obtain signature data, and release the digest baseline and the corresponding signature data along with the upgrade package of this change; The signature verification module is used to perform signature verification on the digest baseline based on the signature data generated by each incremental change when it is necessary to perform integrity verification on the target file in the software. The digest value calculation module is used to determine the current digest value of the target file; The traversal search module is used to traverse the verified digest baselines in any order to find the target digest baseline that contains the digest record of the target file; The digest value comparison module is used to obtain the record digest value of the target file from the target digest baseline, and compare the record digest value with the current digest value, so as to determine whether the integrity verification of the target file is successful based on the comparison result.

[0012] Thirdly, this application discloses an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the software file integrity protection method as described above.

[0013] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the software file integrity protection method described above.

[0014] This invention achieves the following beneficial effects by independently generating and signing a digest baseline containing the digest values ​​of all changed files with each incremental change, and by traversing all published digest baselines during verification to find the record of the target file: (1) All signatures are completed during the upgrade package creation stage, eliminating the need for local or remote signing using private keys in the production environment, thus avoiding the risks of private key leakage and network transmission. (2) Since the summary baseline generated by each upgrade is a complete and independent record unit, the verification does not depend on the upgrade order, but only on whether the corresponding record exists in the summary baseline. Therefore, there is no need to record and maintain the file change order, timestamp and other metadata in the upgrade package or runtime environment, which eliminates the security and availability risks caused by the tampering or improper management of additional metadata. (3) Whether adding, modifying or deleting files, they are all processed uniformly in the form of summary values, which reduces the engineering complexity of different change types and facilitates the implementation and supports the cumulative verification of multiple incremental upgrades. (4) When creating the upgrade package, there is no need to consider the original file status of the target system. Only the changed files are processed, which greatly reduces the complexity of upgrade package adaptation and management.

[0015] Furthermore, the software file integrity protection device, equipment, and storage medium provided in this application correspond to the above-mentioned software file integrity protection method and have the same effect. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a software file integrity protection method disclosed in this application; Figure 2 This is an example diagram of a summary baseline and signature disclosed in this application; Figure 3 An example diagram of the abstract baseline and signature retained after a software upgrade as disclosed in this application; Figure 4 This is a schematic diagram illustrating the signing process of a portion of a document before modification, as disclosed in this application. Figure 5 This application discloses a flowchart of a specific document integrity verification process. Figure 6 This is a schematic diagram of the structure of a software file integrity protection device disclosed in this application; Figure 7 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] 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. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] To ensure software is not tampered with after installation, it is usually necessary to further implement integrity protection for each file that makes up the software. In this scenario, to improve operational efficiency and scalability, the digest of each file to be protected is usually not signed. Instead, the digests of multiple files to be protected are stored together (collectively referred to as the digest baseline) and the entire baseline is signed for protection. When some files in the digest baseline need to be changed due to incremental software upgrades or other reasons, the digest baseline itself needs to be changed, and the signature value of the digest baseline needs to be modified simultaneously. Otherwise, the integrity protection mechanism based on the original digest baseline will fail verification. Existing solutions generally use the following methods to handle the problems caused by file changes in the above incremental upgrade scenario: 1. After the upgrade is complete, update the full file digest based on the file changes, and sign the entire digest baseline again. This is typically done locally in the production environment using a signing private key, but can also be done remotely by sending the digest to the signing server. 2. Sign the changed files during upgrade package creation and record file changes during upgrade. Specifically, generate a new summary baseline for the changed files in the development environment, sign it, and release it with the upgrade package. The file change information is retained during the upgrade; after the upgrade, both the original and new summary baselines will exist locally. When verifying a file, select the corresponding file summary from the required summary baseline based on the changed file information. 3. The entire digest baseline is signed during the upgrade package creation process. That is, in the development environment, the digest baseline of the upgraded, new, and fully protected files is signed according to the possible corresponding original versions, and then the original digest baseline in the environment is overwritten and replaced during the installation of the upgrade package.

[0020] The above solution has the following drawbacks: 1. Performing local signing after the upgrade and changes are completed means using the private key in the production environment, which carries the risk of private key leakage; 2. Performing remote signing after the upgrade and changes are completed may pose a risk of information leakage or tampering during transmission, and may also face situations where network conditions prevent the connection to remote services. 3. Only add a summary baseline and sign the changed file. During verification, the corresponding file summary in the required summary baseline must be selected based on the specific change details (addition, deletion, modification) and the change order (such as the same file undergoing multiple changes in multiple upgrades). The change details, change order, timestamps and other information cannot be protected for integrity or are uncontrollable, which poses security or availability risks.

[0021] 4. When creating the installation package, the entire summary baseline is re-signed and then replaced after the upgrade is completed. This requires creating different new summary baselines for different versions of the original summary baseline that may exist in the software to be upgraded, which increases the workload and management difficulty.

[0022] To address this, this application provides a software file integrity protection scheme. For files affected by the current change (including additions, modifications, and deletions), a digest is pre-calculated to form a new, independent digest baseline, which is then signed and released with the upgrade package. During verification, for all historical digest baseline files, the current valid digest of the target file is found and compared by sequentially traversing all baselines. This avoids the risks associated with production environment signing, the large workload of full signing, and the complexity of managing additional change information.

[0023] This invention discloses a method for protecting the integrity of software files. See [link to relevant documentation]. Figure 1 As shown, the method includes: Step S11: During each incremental change of the software, perform summary processing on the files associated with this change to obtain at least one corresponding summary value, and merge the summary values ​​into a summary baseline for this change.

[0024] Each incremental software change generates corresponding files to be processed; these files are the change files generated during the incremental software upgrade. In this step, digest processing is performed on the files associated with this change, yielding at least one corresponding digest value, covering the unified processing of all file operation types involved in this incremental change. Specifically: First, for the files associated with this change, digest processing is performed according to the file operation type: For newly added and / or modified files: the system calculates its corresponding first digest value using a defined cryptographic algorithm. This digest value uniquely represents the file's content status in the current version. For deleted files: the system does not record its original digest or simply ignore it, but instead assigns it a predefined specific value as a second digest value. This specific value is a pre-agreed fixed value or special identifier (such as all Fs) used to uniformly identify the file's deletion status. The purpose is to maintain a clear record of the deleted file in the digest baseline, indicating that the file has been removed from the protected set.

[0025] Subsequently, the system collects and integrates the summary values ​​of all files involved in this incremental change (including newly added, modified, and deleted files), merging them into a complete summary baseline. As can be understood, the summary baseline is a set of file summary records, where each record contains at least one file identifier (such as a file path or unique ID) and its corresponding summary value. In this way, regardless of whether the file operation is addition, modification, or deletion, its final state is uniformly and indiscriminately encoded into a single summary value and included in the same summary baseline. In this way, each incremental change generates a self-contained, logically complete change record unit, laying the foundation for a subsequent verification process that does not rely on external change sequence information.

[0026] Step S12: Sign the digest baseline using the private key to obtain signature data, and release the digest baseline and the corresponding signature data along with the upgrade package for this change.

[0027] In this step, the digest baseline generated for this change is signed using a private key, generating corresponding signature data. Each time the software undergoes an incremental change, step S11 is repeated to generate a unique digest baseline and signature data for each change. All digest baselines and signature data are stored independently, without additional maintenance of file change order, timestamps, or other supplementary information.

[0028] like Figure 2 The diagram illustrates the file-digest-signature relationship. It involves N modified files, with the file paths (File1_Path, File2_Path…FileN_Path) specifying the exact location of the files to be protected; the file digests (File1_Hash, File2_Hash…FileN_Hash) are the unique identifiers calculated for each file; and the signature value (Sign_Value) represents the encrypted result of signing the entire digest baseline composed of all the aforementioned file-digests using the private key.

[0029] The summary baseline is stored independently for each change event. That is, each file change (such as an incremental upgrade) simultaneously creates a new summary baseline and signature for the changed file. The summary baseline and the corresponding signature data are then released with the upgrade package for this change.

[0030] In a software upgrade scenario, assuming a software is installed with a total of 3 incremental upgrade packages, the retained summary baseline would be as follows: Figure 3 As shown. Summary baseline A is the summary baseline corresponding to the initial software installation. Summary baselines B, C, and D correspond to the summary baselines and signatures of the three upgrade packages. All summary baselines and signatures exist independently, and there is no additional information such as modification information or timestamps.

[0031] like Figure 4The diagram illustrates the core process of generating a signed digest baseline before changes to some software files. The process begins with "Signing files related to the software upgrade package," and proceeds sequentially through: "Identifying files to be added, deleted, or modified in the upgrade package," "Calculating digests for newly added or modified files," "Identifying files to be deleted with a special fixed value (e.g., all Fs)," "Forming a digest baseline from the added, deleted, and modified files, and signing it," and finally, "Releasing the software upgrade package together," thus concluding the process. This solution eliminates the need to sign the new file digest baseline with a signing private key after the upgrade, avoids adding extra data or information that could introduce additional security risks, and eliminates the need to consider the original digest baselines of the target files during upgrade package creation, thereby improving security and reducing implementation workload.

[0032] Step S13: When it is necessary to perform integrity verification on the target file in the software, the signature baseline is verified based on the signature data generated by each incremental change, and the current digest value of the target file is determined.

[0033] In this step, when it is necessary to verify the integrity of a target file in the software, multiple digest baselines generated by each incremental change and their corresponding signature data are obtained from storage. The validity of each signature data is verified by a verification certificate, and valid digest baselines are selected. This step aims to confirm that each acquired digest baseline has not been tampered with during transmission and storage, and that its source is trustworthy. Only digest baselines that have passed signature verification will be used for subsequent searches and comparisons, ensuring the security of integrity verification.

[0034] Furthermore, after securely obtaining a set of valid digest baselines, the current digest value of the target file to be verified is calculated, for example, using the SHA-256 hash algorithm, denoted as HASH.

[0035] Step S14: Traverse the verified digest baselines in any order to find the target digest baseline that contains the digest record of the target file.

[0036] Simultaneously, the system begins traversing all verified digest baselines in any order to check if they contain a digest record for the target file. "Any order" means that the order is irrelevant, eliminating the dependency on the upgrade history. Therefore, it is unnecessary to know the file's historical change order or rely on any additional metadata (such as timestamps). By simply traversing all published, signed digest baselines, the system can determine the currently valid digest value for the file and complete the verification.

[0037] The search process can have two outcomes. In one specific implementation, when a summary record of the target file is found in a certain summary baseline, the traversal terminates, and the current summary baseline is the found target summary baseline. The summary value is obtained and denoted as HASH_BASELINE. If the current summary baseline does not contain a summary record of the target file, the traversal continues to the next summary baseline, that is, the remaining summary baselines are traversed until a target summary baseline containing a summary record of the target file is found.

[0038] In another specific implementation, if no digest record of the target file is found after traversing all verified digest baselines, the integrity check of the file is directly deemed to have failed. This typically means that the file was never included in any version of the integrity protection scope.

[0039] Step S15: Obtain the record digest value of the target file from the target digest baseline, and compare the record digest value with the current digest value, so as to determine whether the integrity verification of the target file is successful based on the comparison result.

[0040] When a summary record of a target file is found within a summary baseline, the target summary baseline is identified. At this point, the system extracts a pre-stored record summary value from that baseline. This value may represent the file's legal status in a historical version. It's worth noting that if the file was deleted during an upgrade, its record summary value will be a specific, pre-defined value.

[0041] In this step, after successfully finding the record digest value, the crucial comparison stage begins. This record digest value is compared with the currently calculated digest value of the target file to determine if the hash is equal to the hash_baseline. If they are completely identical, it proves that the target file has not been tampered with since it was recorded, and the integrity verification is successful; if they are inconsistent, the verification fails. Possible reasons for inconsistency include: the file content has been illegally modified.

[0042] Through the above process, accurate, secure, and efficient integrity verification of any file state is achieved after multiple incremental upgrades.

[0043] like Figure 5 The diagram illustrates the target file integrity verification process, combining steps S14 and S15. The system node begins verifying the integrity of file X, clearly defining the target object for verification. Then, it obtains various digest baselines through the verification certificate, subsequently traversing these baselines and comparing them one by one with the file's real-time digest. If a match is found on a baseline and the digest is identical, the process immediately terminates and verification is deemed successful; if all baselines do not match, verification is deemed unsuccessful.

[0044] Furthermore, as an optimization and cleanup mechanism, when the number of file changes in a version upgrade exceeds a preset threshold, a full-scale installation can be selected to complete the file changes. Specifically, a full digest baseline is generated and signed for all software files, and released with the full upgrade package. During the software upgrade installation, all stored historical digest baselines and corresponding signature data are deleted, achieving the cleanup purpose.

[0045] This invention achieves the following beneficial effects by independently generating and signing a digest baseline containing the digest values ​​of all changed files with each incremental change, and by traversing all published digest baselines during verification to find the record of the target file: (1) All signatures are completed during the upgrade package creation stage, eliminating the need for local or remote signing using private keys in the production environment, thus avoiding the risks of private key leakage and network transmission. (2) Since the summary baseline generated by each upgrade is a complete and independent record unit, the verification does not depend on the upgrade order, but only on whether the corresponding record exists in the summary baseline. Therefore, there is no need to record and maintain the file change order, timestamp and other metadata in the upgrade package or runtime environment, which eliminates the security and availability risks caused by the tampering or improper management of additional metadata. (3) Whether adding, modifying or deleting files, they are all processed uniformly in the form of summary values, which reduces the engineering complexity of different change types and facilitates the implementation and supports the cumulative verification of multiple incremental upgrades. (4) When creating the upgrade package, there is no need to consider the original file status of the target system. Only the changed files are processed, which greatly reduces the complexity of upgrade package adaptation and management.

[0046] Accordingly, this application also discloses a software file integrity protection device, see [link to relevant documentation]. Figure 6 As shown, the device includes: The change file summary processing module 11 is used to perform summary processing on the files associated with the current change each time the software is incrementally changed, so as to obtain at least one corresponding summary value, and merge the summary values ​​into a summary baseline for the current change; The signature release module 12 is used to sign the digest baseline using a private key to obtain signature data, and release the digest baseline and the corresponding signature data along with the upgrade package of this change; The signature verification module 13 is used to perform signature verification on the digest baseline based on the signature data generated by each incremental change when it is necessary to perform integrity verification on the target file in the software. The digest value calculation module 14 is used to determine the current digest value of the target file; The traversal search module 15 is used to traverse the verified digest baselines in any order to find the target digest baseline containing the digest record of the target file; The summary value comparison module 16 is used to obtain the record summary value of the target file from the target summary baseline, and compare the record summary value with the current summary value, so as to determine whether the integrity verification of the target file is successful based on the comparison result.

[0047] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0048] Therefore, the above-described scheme in this embodiment achieves the following beneficial effects by independently generating and signing a digest baseline containing the digest values ​​of all changed files for each incremental change, and by traversing all published digest baselines to find the record of the target file during verification: (1) All signatures are completed during the upgrade package creation stage, eliminating the need for local or remote signing using private keys in the production environment, thus avoiding the risks of private key leakage and network transmission. (2) Since the summary baseline generated by each upgrade is a complete and independent record unit, the verification does not depend on the upgrade order, but only on whether the corresponding record exists in the summary baseline. Therefore, there is no need to record and maintain the file change order, timestamp and other metadata in the upgrade package or runtime environment, which eliminates the security and availability risks caused by the tampering or improper management of additional metadata. (3) Whether adding, modifying or deleting files, they are all processed uniformly in the form of summary values, which reduces the engineering complexity of different change types and facilitates the implementation and supports the cumulative verification of multiple incremental upgrades. (4) When creating the upgrade package, there is no need to consider the original file status of the target system. Only the changed files are processed, which greatly reduces the complexity of upgrade package adaptation and management.

[0049] Furthermore, embodiments of this application also disclose an electronic device, Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0050] Figure 7This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the software file integrity protection method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0051] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0052] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0053] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the software file integrity protection method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0054] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned software file integrity protection method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0055] Furthermore, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements any of the above-described methods for protecting the integrity of software files.

[0056] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0057] The steps of the software file integrity protection method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0058] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0059] The foregoing has provided a detailed description of a method, apparatus, device, and medium for protecting the integrity of software files provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for protecting the integrity of software files, characterized in that, include: Each time the software undergoes an incremental change, the files associated with this change are digested to obtain at least one corresponding digest value, and the digest values ​​are merged into a digest baseline for this change. The digest baseline is signed using a private key to obtain signature data, and the digest baseline and the corresponding signature data are released with the upgrade package of this change; When it is necessary to perform integrity verification on target files in the software, the signature baseline is verified based on the signature data generated by each incremental change, and the current digest value of the target file is determined. Traverse the verified digest baselines in any order to find the target digest baseline that contains the digest record of the target file; The record digest value of the target file is obtained from the target digest baseline, and the record digest value is compared with the current digest value so as to determine whether the integrity verification of the target file is successful based on the comparison result.

2. The software file integrity protection method according to claim 1, characterized in that, The process of digesting the files associated with this change to obtain at least one corresponding digest value includes: For each file added and / or modified in this change, calculate the corresponding first digest value; For each file deleted in this change, the corresponding digest value will be set to a predefined second digest value.

3. The method for protecting the integrity of software files according to claim 1, characterized in that, The step of traversing the verified digest baselines in any order to find the target digest baseline containing the digest record of the target file includes: Traverse the verified summary baselines in any order and determine whether the current summary baseline contains a summary record of the target file; If so, then terminate the traversal and determine the current summary baseline as the target summary baseline; If not, continue traversing the remaining summary baselines until a target summary baseline containing the summary record of the target file is found.

4. The software file integrity protection method according to claim 3, characterized in that, Also includes: If no summary record of the target file is found after traversing all verified summary baselines, the integrity verification of the target file is deemed to have failed.

5. The software file integrity protection method according to claim 1, characterized in that, The step of comparing the record digest value with the current digest value to determine whether the integrity verification of the target file was successful based on the comparison result includes: Compare the record summary value with the current summary value; If the record digest value is equal to the current digest value, then the integrity verification of the target file is deemed successful. If the record digest value is not equal to the current digest value, the integrity verification of the target file is determined to have failed.

6. The method for protecting the integrity of software files according to any one of claims 1 to 5, characterized in that, Also includes: When the number of files associated with the software during this change exceeds a preset threshold, a full overwrite installation upgrade method is triggered.

7. The method for protecting the integrity of software files according to claim 6, characterized in that, The upgrade methods that trigger a full-scale installation include: Generate and sign the corresponding full digest baseline for all software files, and delete all stored historical digest baselines and corresponding signature data during software upgrade and installation.

8. A software file integrity protection device, characterized in that, include: The change file summary processing module is used to perform summary processing on the files associated with each incremental change to obtain at least one corresponding summary value, and merge the summary values ​​into a summary baseline for this change. The signature release module is used to sign the digest baseline using a private key to obtain signature data, and release the digest baseline and the corresponding signature data along with the upgrade package of this change; The signature verification module is used to perform signature verification on the digest baseline based on the signature data generated by each incremental change when it is necessary to perform integrity verification on the target file in the software. The digest value calculation module is used to determine the current digest value of the target file; The traversal search module is used to traverse the verified digest baselines in any order to find the target digest baseline that contains the digest record of the target file; The digest value comparison module is used to obtain the record digest value of the target file from the target digest baseline, and compare the record digest value with the current digest value, so as to determine whether the integrity verification of the target file is successful based on the comparison result.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the software file integrity protection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used for storing computer programs; wherein the computer programs, when executed by a processor, implement the software file integrity protection method as described in any one of claims 1 to 7.

Images