Software package processing method and device, medium and program product

Abstract

The invention discloses a software package processing method and device, a medium and a program product, and relates to the technical field of data transmission. The software package is signed by adopting at least two signature algorithms, so that the potential safety hazard existing in a single algorithm and the limitation of only supporting a single fixed algorithm are avoided, the dynamic switching of a national secret algorithm and an international algorithm is supported, the compliance and compatibility requirements of different scenes are met, and the security and strategy flexibility of the algorithm level are improved; the client can select the signature algorithm for verification according to requirements, the verification mode is allowed to be dynamically adjusted, the problem of lack of a strategic verification mechanism is solved, and verification failure caused by failure of a single algorithm or expiration of a certificate is avoided. According to the method, large-scale distributed environment deployment is adapted through a multi-algorithm signature and flexible verification strategy of a software level, the technical problems of potential safety hazards and limited application scenes existing in a single signature algorithm are solved, and the technical effects of expanding the application scenes and improving the safety are achieved.

Description

Technical Field

[0001] The present application relates to the technical field of data transmission, and in particular to a method, device, medium and program product for processing a software package. Background Art

[0002] In the related art, there are two main technical solutions for software package security verification in operating system software repositories. The first is a layered encryption and multi-verification mechanism, which mainly uses asymmetric encryption for digital signatures and symmetric encryption to ensure transmission security, combined with a hash algorithm to verify integrity and source authenticity. This solution has algorithm security risks, insufficient key rotation automation, and a lack of recursive signature verification for third-party dependency packages, which can easily lead to problems such as expired certificates and unrenewed dependencies and dependency hijacking. The second is a security token integrity verification mechanism, which uses the built-in encryption algorithm of hardware security devices to generate / verify signature values to achieve storage and transmission protection. This solution is limited by supporting only a single fixed algorithm, the inability to dynamically switch strategies, and the lack of scalability due to hardware storage characteristics, making it difficult to adapt to large-scale application scenarios.

[0003] Therefore, providing a software package processing method with flexible and wide application scenarios and high security is a technical problem that needs to be solved urgently by those skilled in the art. Summary of the Invention

[0004] The present application provides a method, device, medium, and program product for processing a software package, which at least solves the technical problems of security risks and limited application scenarios of the single signature algorithm, and achieves the technical effects of expanding application scenarios and improving security.

[0005] The present application provides a method for processing a software package, comprising: compiling source code into a software package; signing the software package using at least two signature algorithms to obtain software package signature values corresponding to each of the signature algorithms, wherein the signature algorithms include a national secret algorithm and an international algorithm; writing the software package signature values into the header information of the software package, and pushing the signed software package to a storage module, so that when a client downloads the software package from the storage module, it can select a signature algorithm according to needs to verify the software package signature value.

[0006] The present application provides a method for processing a software package, comprising: obtaining a preset security policy and downloading a signed software package from a storage module; directly installing the software package according to the preset security policy, or determining at least one target software package signature value, verifying the target software package signature value, and installing the software package after the verification passes; the target software package signature value is a subset of all software package signature values.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned software package processing methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned software package processing methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned software package processing methods when executed by a processor.

[0010] Through this application, at least two signature algorithms are used to sign the software package, avoiding the security risks of a single algorithm and the limitation of only supporting a single fixed algorithm. It supports dynamic switching between national and international algorithms, meets the compliance and compatibility requirements of different scenarios, and improves the security and policy flexibility at the algorithm level. The client can select the signature algorithm for verification according to needs, allowing dynamic adjustment of the verification method, solving the problem of lack of a strategic verification mechanism, and avoiding verification failures caused by the failure of a single algorithm or certificate expiration. This application uses multi-algorithm signatures and flexible verification strategies at the software level to adapt to large-scale distributed environment deployment, solving the technical problems of security risks and limited application scenarios of a single signature algorithm, and achieving the technical effect of expanding application scenarios and improving security. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A flowchart of a method for processing a software package provided in an embodiment of the present application; Figure 2 An architectural diagram corresponding to a method for processing a software package provided in an embodiment of the present application; Figure 3 A flowchart of another method for processing a software package provided in an embodiment of the present application; Figure 4 A flowchart for verifying a software package signature value provided in an embodiment of the present application; Figure 5 A flowchart for verifying a warehouse signature value provided in an embodiment of the present application; Figure 6An architectural diagram corresponding to another software package processing method provided in an embodiment of the present application; Figure 7 A flowchart of the interaction between a user terminal and a storage module provided in an embodiment of the present application. DETAILED DESCRIPTION

[0013] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0014] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0015] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0016] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the processing method of the software package depends, the specific application environment architecture or the specific hardware architecture is described herein.

[0017] A TPM (Trusted Platform Module) is a security device used to protect hardware and data, supporting cryptographic operations and system integrity verification. Secure Boot is a secure boot mechanism designed to ensure only verified software runs, preventing malware from executing during system startup. By cryptographically verifying signatures at each stage of the boot process, it protects the computer from low-level malware. This feature is common in modern operating systems and hardware, providing enhanced security for users.

[0018] Intel Software Guard Extensions (Intel SGX) is a hardware-enhanced security technology that protects selected code and data from malware, operating system, or hardware-level attacks by creating isolated execution environments, or enclaves. SGX ensures that data processing security and privacy are maintained even in the presence of potential threats. This technology is ideal for applications requiring high security, such as financial transactions, healthcare, and cloud computing services.

[0019] In the context of Intel SGX, a "quote" is a mechanism used to verify the integrity and identity of an SGX enclave. It allows an enclave to generate a report signed by the platform's sealing key, which can be sent to external entities for verification. Specifically, a quote contains information about the enclave, such as its identity (identified by the MRENCLAVE value), the ISV (Independent Software Vendor) public key hash, and some custom data. This quote is generated by the Intel-provided Quoting Enclave (QE) and signed with Intel's private key, ensuring its unforgeability. The recipient can verify the authenticity of the quote using Intel's publicly available root certificate, thereby confirming that the enclave communicating with it is indeed running on authentic SGX hardware and has not been tampered with or forged. Therefore, the quote mechanism is a core component of remote attestation, enabling trust relationships to be established between different SGX enclaves or between an enclave and external services.

[0020] The Platform Configuration Register (PCR) values in a TPM (Trusted Platform Module) are a set of registers used to measure and report the status of the platform's hardware and software. PCR values play a key role in ensuring the security of the system boot process and verifying system integrity.

[0021] The Attestation Identity Key (AIK) is a key component of a TPM (Trusted Platform Module) for remote attestation. It allows a platform to prove the state and configuration of its TPM to a remote entity while protecting the platform's privacy.

[0022] Nonce is a term widely used in cryptographic communications and security protocols, standing for "number used once." The primary purpose of a nonce is to ensure message freshness and prevent replay attacks, where an attacker repeatedly sends a previously intercepted message in an attempt to perform unauthorized operations. By introducing a unique value (the nonce) in each session or transaction, even if the same message is sent multiple times, the recipient can identify and reject duplicate messages by checking the nonce.

[0023] In the information security field, CA generally stands for Certificate Authority. It is a core component of the Public Key Infrastructure (PKI), responsible for issuing, managing, and verifying digital certificates. These digital certificates are used to confirm the identity of entities (such as individuals, organizations, or devices) and to protect the security of communications through encryption.

[0024] like Figure 1 , this application provides a method for processing a software package, comprising: S11: Compile the source code into a software package.

[0025] Specifically, human-readable source code is converted into a binary package executable by the target operating system through compilation tools, regardless of the specific compilation tools or package formats, such as RPM or DEB. Through syntax parsing, semantic analysis, code optimization, and target code generation of the source code, the scattered code files, configuration information, and dependent libraries are ultimately integrated into a structured package entity, providing a standardized physical carrier for subsequent signature verification, storage distribution, and client installation.

[0026] S12: Use at least two signature algorithms to sign the software package and obtain the software package signature value corresponding to each signature algorithm. The signature algorithms include national secret algorithms and international algorithms.

[0027] Specifically, two or more different signature algorithms (such as a combination of a national secret algorithm and an international algorithm) are used to cryptographically transform the software package data, generating a digital signature value that corresponds to each algorithm. This process encrypts the package's characteristic information (such as hash values and concatenated data) using the private keys of each algorithm to form a unique signature credential. Essentially, this system establishes a multi-dimensional digital fingerprint authentication system for the software package. This system aims to mitigate potential security risks associated with a single algorithm (such as algorithm vulnerabilities, backdoors, or compliance restrictions) by enabling concurrent signing with multiple algorithms. It also supports algorithm switching under dynamic policies (such as prioritizing the national secret algorithm and automatically switching to the international algorithm upon failure, or using a user-specified algorithm), providing clients with flexible and configurable verification options.

[0028] This multi-algorithm collaborative signature mechanism not only strengthens the authenticity of the software package source and the reliability of integrity verification, but also improves the system's compatibility and anti-attack capabilities in complex environments through the redundant design of algorithm combinations. It is the key security link connecting the software package generation end and the client verification logic.

[0029] S13: Writing the software package signature value into the header information of the software package, and pushing the signed software package to the storage module, so that the client can select a signature algorithm according to requirements to verify the software package signature value when downloading the software package from the storage module.

[0030] Specifically, to ensure the security and verifiability of software packages throughout their lifecycle, the package signature value is written into the package header, acting as a security label. The header is the easily accessible and identifiable portion of the package, making it easier for clients to extract and verify it. Pushing the signed software package to the storage module establishes a unified storage and distribution center for easier management and maintenance.

[0031] When downloading a software package from the storage module, the client can select an appropriate algorithm from multiple signature algorithms to verify the software package signature value based on its own needs, security policy, or system environment. By comparing the received signature value with the signature value calculated using the public key, it can confirm whether the software package has been tampered with during transmission and whether it comes from a legitimate source, thereby ensuring the authenticity, integrity, and security of the downloaded software package.

[0032] It is important to understand that based on your own needs, security policies, or system environment, you can select at least one algorithm from multiple signature algorithms to verify the software package signature value. You can also skip verification (select 0 algorithms) by configuring policies in specific trust scenarios (such as internal trusted networks) to balance security and deployment efficiency.

[0033] The design of this application is essentially to delegate verification control to the client. Through the mechanism of pre-implantation of multi-algorithm signatures and flexible policy selection, it decouples the security verification process from the actual application scenario. It not only ensures the security baseline of the entire link of the software package, but also provides configurable verification options for different user environments. It is the core interaction hub connecting server-side signature generation and client-side dynamic verification.

[0034] In an exemplary embodiment, after pushing the signed software package to the storage module, the process further includes: triggering the storage module to generate repository metadata based on the signed software package; signing the repository metadata using at least two signature algorithms to obtain repository signature values corresponding to each signature algorithm; so that when the client downloads the software package from the storage module, it selects a signature algorithm according to needs to verify the repository signature value.

[0035] During the software package processing process, when a signed software package is pushed to the storage module, it triggers the storage module to generate repository metadata and perform a multi-algorithm signature on it. The storage module generates repository metadata to comprehensively and systematically describe and organize the software package. This metadata contains key information about the software package, such as version, dependencies, hash values, and more, providing the necessary foundation for software package management and distribution. The repository metadata is signed using at least two signature algorithms, encrypted using the private keys of different signature algorithms, and a repository signature value corresponding to each algorithm is generated. This is equivalent to adding multiple different types of "digital seals" to the repository metadata, which can ensure the integrity of the metadata and the authenticity of its source from multiple dimensions.

[0036] When downloading software packages from the storage module, clients can flexibly select an appropriate signature algorithm to verify the repository signature value based on their needs, security policies, or system environment. By comparing the received signature value with the signature value calculated using the public key, it can determine whether the repository metadata has been tampered with during transmission or storage, and whether it comes from a legitimate and reliable source, thereby ensuring that the software package information obtained by the client is accurate and secure.

[0037] It is important to understand that based on your own needs, security policies, or system environment, you can select at least one algorithm from multiple signature algorithms to verify the warehouse signature value. You can also skip verification (select 0 algorithms) directly by configuring policies in specific trust scenarios (such as internal trusted networks) to balance security and deployment efficiency.

[0038] In an exemplary embodiment, after compiling the source code into a software package, the method further includes: concatenating the software package with a random number to obtain data to be signed; signing the software package using at least two signature algorithms to obtain software package signature values corresponding to each signature algorithm, including: signing the data to be signed using at least two signature algorithms to obtain software package signature values corresponding to each signature algorithm; and writing the software package signature value into the header information of the software package, including: synchronously writing the software package signature value and the random number into the header information of the software package.

[0039] During software package processing, after the source code is compiled into a software package, the package is concatenated with a random number. First, the package and random number are concatenated to produce the data to be signed. This introduces an additional random factor, increasing the security and unpredictability of the signature. The inclusion of the random number ensures that even if the same package is signed at different times or under different circumstances, the resulting data to be signed will be different, effectively defending against attacks targeting fixed data, such as rainbow table attacks.

[0040] At least two signature algorithms are used to sign the data to be signed, generating the corresponding software package signature values for each signature algorithm. By employing multiple signature algorithms and leveraging their unique characteristics and encryption mechanisms, software package signatures can be authenticated from multiple perspectives. The signature results from different algorithms complement and verify each other, further enhancing the reliability and security of software package signatures and reducing the risk of vulnerabilities or cracking that may exist with a single algorithm.

[0041] The software package signature value and random number are synchronously written to the package header. The header is the easily accessible and identifiable portion of the software package. Placing the signature value and random number here allows clients to quickly retrieve and use this information for verification after downloading the package. Clients can select an appropriate signature algorithm to verify the package signature value based on their needs, security policies, or system environment. The random number is used to verify the validity of the signature and the integrity of the package, ensuring that the package has not been tampered with during transmission and storage, thereby ensuring the security and reliability of the package.

[0042] In an exemplary embodiment, the method further includes integrating secure random number generation logic into a device on the server side or the user side to facilitate random generation of random numbers.

[0043] The principle behind integrating secure random numbers into server-side or user-side devices is to generate highly random and unpredictable values through hardware-level security mechanisms, providing fundamental support for critical security operations during software package processing. Specifically, secure random numbers are typically generated using physical entropy sources (such as circuit thermal noise, quantum effects, and other natural random phenomena) within hardware security devices (e.g., TPMs). Their core advantage lies in ensuring true randomness through physical processes at the hardware level, thereby avoiding security risks associated with predictable states in software algorithms.

[0044] During server-side integration, secure random numbers can be used to generate a random salt value (such as the random number a) during the package signing process. This salt value is then concatenated with the package data for multi-algorithm signing. By dynamically injecting random factors, the same package generates different data to be signed at different signing times, effectively defending against pre-calculation attacks targeting fixed data, such as rainbow table attacks. For example, in the packaging module, the introduction of secure random numbers allows signature values for algorithms such as SM2 and RSA to dynamically change with the salt value, enhancing the unpredictability and uniqueness of the signature.

[0045] During user-side integration, secure random numbers can be used to generate random challenges (such as nonce values) during the verification process to prevent replay attacks. When the client verifies the signature of a software package or repository metadata, a temporary verification factor is generated using secure random numbers to ensure the freshness of each verification process and prevent attackers from exploiting historical communication data to falsely appear to have passed verification. Furthermore, secure random numbers can be used in scenarios such as key generation and session key negotiation, ensuring the fundamental security of interactions between the client and the server.

[0046] By integrating secure random numbers into both server-side and user-side devices, randomized protection can be implemented throughout the entire process, from signature generation to verification. This compensates for the security deficiencies of software pseudo-random numbers and provides underlying randomization support for core mechanisms such as multi-algorithm signatures and dynamic policy switching, ultimately enhancing the software package processing system's ability to resist various cryptographic attacks.

[0047] like Figure 2 Specifically, the above method is applied to the server side (where security devices such as TPM are deployed). For example, the server-side services are divided into a packaging module and a storage module. The packaging module is used to compile the source code of the software package into a binary package, such as the RPM package in the Red Hat series operating system.

[0048] In the implementation of the present application, the binary software package generation tool is modified. After packaging the completed binary software package, the random number a and the value of the binary software package b are concatenated. The concatenated value is then signed using two signature algorithms, SM2 and RSA (not limited to the two or the signature algorithms listed above; other algorithms, such as quantum-resistant signature algorithms, may also be used).

[0049] S SM2 =R SM2 (P SM2 (a+b)), where S SM2 is the software package signature value of the SM2 algorithm, R SM2 is the signature function of the SM2 algorithm; P SM2 The signature private key of the SM2 signature algorithm; a+b represents the concatenation of the random number a and the binary software package b.

[0050] S RSA =R RSA (P RSA (a+b)), similarly S RSA 、R RSA are the software package signature value and signature function of the RSA algorithm, P RSA The private key for the RSA signature algorithm.

[0051] Then, S SM2 、S RSA、The random number a is written into the SIGSM2, SIGRSA, and Salt fields of the binary package header. The random number a is a variable-length random salt value, with a default length of 16 bytes. Dynamic injection of the random salt value (a) protects against rainbow table attacks. Furthermore, a timestamp is embedded in the binary package header to verify the package's timeliness. Combining the hash and timestamp generates a time-sensitive signature to prevent malicious rollbacks of older versions.

[0052] The packaging module compiles the software package source code into a binary software package, adds SM2 and RSA dual signatures, and pushes the binary software package to the storage module through a secure channel.

[0053] The storage module receives the binary software package pushed by the packaging module and generates warehouse metadata using the warehouse construction tool. The warehouse construction tool supports multiple hash algorithms such as SM3 and SHA256, and the generated warehouse metadata also includes hash values of multiple hash algorithms.

[0054] Use both SM2 and RSA signature algorithms to sign the repository metadata (not limited to two, nor limited to the signature algorithms listed above).

[0055] That is: RS SM2 =R SM2 (MP SM2 (Metadata)), where R SM2 is the signature function of the SM2 algorithm, RS SM2 The warehouse signature value of the SM2 signature algorithm for the warehouse metadata; MP SM2 The private key of the SM2 signature algorithm for the warehouse construction tool, and Metadata is the warehouse metadata.

[0056] RS RSA =R RSA (MP RSA (Metadata)), similarly, R RSA is the signature function of the RSA algorithm, RS RSA The warehouse signature value of the RSA signature algorithm for the warehouse metadata; MP RSA The RSA signature algorithm private key for the repository construction tool is now complete. The storage module data is now ready to receive client requests for downloading software packages.

[0057] In addition, the signature public key of the signature algorithm can be preset to the local trust store, such as the RPM trust store of the redhat series operating system. The preset keys include, Q SM2 , Q RSA 、MQ SM2 、MQ RSA , where Q SM2The signature public key of the SM2 algorithm for the binary software package; Q RSA The RSA signature public key for the binary software package, MQ SM2 The signature public key of the warehouse metadata SM2 algorithm; MQ RSA The signature public key of the repository metadata using the RSA algorithm.

[0058] like Figure 3 , this application provides a method for processing a software package, comprising:

[0059] S21: Obtain the preset security policy and download the signed software package from the storage module;

[0060] Specifically, a pre-set security policy is a set of rules and configurations based on system or user security needs, compliance requirements, and actual application scenarios. It determines the security standards and operating procedures to be followed when downloading software packages.

[0061] Downloading signed software packages from the storage module is based on the storage module's role as a centralized software package storage and distribution center. The storage module stores software packages processed and signed by the packaging module. These packages carry signature information for subsequent verification and validation. Clients interact with the storage module to obtain the required software packages according to pre-set security policies.

[0062] Retrieving the preset security policy and downloading the signed software package from the storage module work together to ensure the security and controllability of the software package download process. The preset security policy provides security for the download process, while downloading the signed software package from the storage module is the specific operation that implements the software package acquisition. Together, they constitute a critical step in the software package processing process.

[0063] S22: directly installing the software package according to the preset security policy, or determining at least one target software package signature value, verifying the target software package signature value, and installing the software package after the verification passes; the target software package signature value is a subset of all software package signature values.

[0064] Specifically, the flexibility of pre-set security policies is used to balance the efficiency and security of software package installation. Pre-set security policies take into account multiple factors, including user needs, system environment, usage scenarios, and security level requirements, to provide guidance for the software package installation process.

[0065] If the pre-set security policy determines that the current environment has a low security risk and the source of the package is highly trusted, the package will be installed directly to improve deployment efficiency. However, when higher security is required, some or all of the signature values of the entire package (i.e., the target package signature value) will be verified from the signature values of the entire package.

[0066] This verification process, based on the cryptographic principles of digital signatures, compares the signature value calculated with the public key to confirm that the software package has not been tampered with during transmission and that the source is legitimate. Only if the verification passes will the software package be installed, ensuring that the software package installed on the system is authentic, complete, and secure.

[0067] In an exemplary embodiment, verifying a signature value of a target software package and installing the software package after the verification passes includes: obtaining a first public key of a first target signature algorithm corresponding to the signature value of the target software package; parsing the first public key to obtain the signature value of the software package to be compared; determining whether the signature value of the software package to be compared is identical to the signature value of the target software package; if they are identical, determining that the verification passes and installing the software package.

[0068] Specifically, within this software package processing flow, a pre-set security policy determines the operational path for software package installation. If a security verification is required, a target software package signature value is selected from all available software package signature values. Based on public key cryptography, each target software package signature value corresponds to a specific first target signature algorithm and its first public key. After obtaining the first public key and parsing it, the signature value of the software package to be compared, calculated based on this algorithm and public key, is obtained. Comparing this signature value with the target software package signature value essentially verifies whether the software package has been tampered with during transmission and storage. Because digital signatures are unique and unforgeable, if the two are identical, it indicates that the software package has been tampered with and has not been illegally modified. Verification is determined to have passed and the software package is installed, ensuring that the system is installing a secure and complete software package.

[0069] In an exemplary embodiment, directly installing a software package or determining at least one target software package signature value according to a preset security policy includes: obtaining a first configuration item in a storage module; the preset security policy includes the first configuration item; when the first configuration item is a first preset value, determining to directly install the software package; when the first configuration item is not the first preset value, determining a target software package signature value corresponding to at least one target signature algorithm based on the value of the first configuration item and a first mapping relationship; the first mapping relationship includes a correspondence between the value of the first configuration item and the signature algorithm.

[0070] Specifically, if Figure 4 The first configuration item in the preset security policy allows for flexible software package installation, balancing security and efficiency. The first configuration item in the storage module is a specific embodiment of the preset security policy, reflecting pre-defined settings made by the system or user based on different security requirements, usage scenarios, and other factors. For example, add the first configuration item to the repository configuration file.

[0071] When the first configuration item is the first preset value, it means that the security risk of the current environment is low, or the source of the software package is highly trusted, so the software package can be installed directly, which can improve the efficiency of software deployment.

[0072] If the first configuration item is not the first preset value, it indicates that a certain degree of security verification is required. In this case, the value of the first configuration item and the first mapping relationship can be used to determine at least one target signature algorithm and its corresponding target software package signature value. Verifying these signature values ensures the authenticity and integrity of the software package, thereby ensuring secure system operation.

[0073] Specifically, taking two signature algorithms as an example, if the first configuration option is GMCheck, the optional values for the first configuration option are 0 and 1. When the GMCheck configuration option is 1, the local repository verifies the binary package's signature value using the national encryption algorithm SM2; when the GMCheck configuration option is 0, the local repository verifies the binary package's signature value using the international encryption algorithm RSA. If more than two signature algorithms are used, GMCheck can be configured to use binary data of 2 or more bits.

[0074] This design allows the software package installation process to be dynamically adjusted according to actual conditions, meeting both security requirements and efficiency.

[0075] In an exemplary embodiment, the number of target signature algorithms determined according to the value of the first configuration item is greater than 1; verifying the target software package signature value, and installing the software package after the verification passes, includes: obtaining the priority of the target signature algorithm; verifying the target software package signature values corresponding to the target signature algorithms in order of priority; and installing the software package when the number of target software package signature values that pass the verification is greater than a preset number; the preset number is not greater than the number of target signature algorithms.

[0076] Specifically, a priority-driven, multi-algorithm collaborative verification mechanism ensures both software package security and verification efficiency. When the first configuration item in a pre-set security policy corresponds to multiple target signature algorithms, each algorithm is assigned a priority based on security requirements or scenario configuration (for example, national encryption algorithms are prioritized in domestic scenarios, while international algorithms are prioritized in international scenarios), forming a verification order. During the verification process, corresponding signature values are verified sequentially from highest to lowest priority, avoiding indiscriminate verification of all algorithms and improving efficiency.

[0077] The preset number is used as the judgment threshold for verification pass (such as at least one main algorithm passes or a majority of algorithms are required to pass), which allows key algorithms (such as high-priority national encryption algorithms) to complete verification independently, and also supports redundant verification of multiple algorithms to enhance security.

[0078] This design adapts to scenarios with different security levels through dynamic priority sorting and threshold control. Under high security requirements, multiple algorithms can be required to pass verification. In ordinary scenarios, the main algorithm is prioritized to quickly complete verification. It balances verification strength and performance in complex environments to ensure that the software package is efficiently installed on the premise that the source is legitimate and has not been tampered with.

[0079] In an exemplary embodiment, before downloading the signed software package from the storage module, the method further includes: determining, based on a preset security policy, to directly download the signed software package from the storage module, or determining at least one target repository signature value, verifying the target repository signature value, and downloading the signed software package from the storage module after the verification passes.

[0080] Specifically, before downloading a signed software package from the storage module, the pre-set security policy is consulted for verification. If the current environment's security risk is low, or the source of the software package is highly trusted, the pre-set security policy may dictate downloading the signed software package directly from the storage module. This approach improves software package download and deployment efficiency, avoids unnecessary verification steps, and is particularly suitable for time-sensitive or highly trusted environments.

[0081] However, when faced with higher security requirements, the pre-set security policy may require verification of the repository's signature. The repository metadata in the storage module is signed using multiple signature algorithms, including repository signature values generated by algorithms such as SM2 and RSA. From these signature values, at least one target repository signature value is determined. The target repository signature value can be one, two, or more, or even zero (for direct downloads), depending on the pre-set security policy.

[0082] Verifying the target repository's signature value is based on the principle of digital signatures. The signature value is decrypted and verified using the corresponding public key to confirm that the repository metadata has not been tampered with during transmission and storage and originates from a legitimate source. Only after the target repository's signature value passes verification will the signed software package be downloaded from the storage module. This verification process effectively prevents the download of malicious software packages and ensures that the downloaded software package is authentic, complete, and secure.

[0083] Through this flexible decision-making mechanism based on preset security policies, it is possible to find the optimal balance between security and efficiency according to different security requirements and scenarios, ensuring the secure download of software packages while improving download efficiency under appropriate circumstances.

[0084] In an exemplary embodiment, determining whether to directly download a signed software package from a storage module or determining at least one target repository signature value based on a preset security policy includes: obtaining a second configuration item in the storage module; when the second configuration item is a second preset value, directly downloading the signed software package from the storage module; when the second configuration item is not the second preset value, determining a target repository signature value corresponding to at least one target signature algorithm based on the value of the second configuration item and a second mapping relationship; the second mapping relationship includes a correspondence between the value of the second configuration item and the signature algorithm.

[0085] Specifically, if Figure 5 The pre-set security policy is a set of rules developed based on a comprehensive consideration of various factors, including system security requirements, application scenarios, and compliance. It provides an overall guiding framework for the software package download process. The second configuration item in the storage module is the actual implementation of this policy.

[0086] After obtaining the second configuration item from the storage module, it is evaluated. If the value of the second configuration item is exactly the second preset value, this means that the current software package download scenario has been determined to have a low security risk or that the software package source is highly trustworthy. In this case, to improve software package download and deployment efficiency, the signed software package is downloaded directly from the storage module, skipping the verification of the repository signature value. This avoids unnecessary time and resource consumption and is particularly suitable for environments with high download speed requirements or high internal trust.

[0087] On the contrary, when the value of the second configuration item is not the second preset value, it means that the current scenario requires higher security protection. At this time, with the help of the second mapping relationship, the relationship clarifies the correspondence between the value of the second configuration item and the signature algorithm. Through this mapping, at least one target signature algorithm can be determined according to the specific value of the second configuration item, and then the target warehouse signature value corresponding to these target signature algorithms can be obtained. Verifying these target warehouse signature values is an important step to ensure the reliability and integrity of the source of the software package. Based on the principle of digital signature, the signature value is decrypted and verified using the corresponding public key. Only when the verification is passed and it is confirmed that the warehouse metadata has not been tampered with during transmission and storage and comes from a legitimate source, the signed software package will be downloaded from the storage module.

[0088] Specifically, taking two signature algorithms as an example, if the second configuration item is RemoteRepositoryCheck, the optional values for the second configuration item are 0 and 1. When the RemoteRepositoryCheck configuration item is 0, the local repository does not verify the repository signature value; when the RemoteRepositoryCheck configuration item is 1, the local repository must first verify the repository signature value before downloading the binary package. Only after the repository signature value verification passes can the binary package be downloaded. If more than two signature algorithms are used, RemoteRepositoryCheck can be configured to binary data of 2 or more bits.

[0089] In summary, this decision-making mechanism based on the second configuration item and the second mapping relationship enables the software package download process to be flexibly adjusted according to actual conditions. While ensuring security, it can also improve efficiency in appropriate scenarios, achieving a dynamic balance between security and efficiency.

[0090] In an exemplary embodiment, the target warehouse signature value is verified, and after the verification passes, the signed software package is downloaded from the storage module, including: obtaining a second public key of a second target signature algorithm corresponding to the target warehouse signature value; parsing the second public key to obtain the signature value of the warehouse to be compared; determining whether the signature value of the warehouse to be compared is the same as the signature value of the target warehouse; if they are the same, determining that the verification passes, and downloading the signed software package from the storage module.

[0091] Specifically, in an asymmetric encryption system, there exists a pair of keys: a public key and a private key. The private key is held in secret by the signer and is used to sign data; the public key is publicly available and can be used to verify the signature. Repository metadata in the storage module is signed using multiple signature algorithms to form target repository signature values. These signature values act as a "digital fingerprint" of the repository metadata, representing its integrity and the legitimacy of its source.

[0092] When verifying the target repository's signature, the second public key of the second target signature algorithm corresponding to the target repository's signature is first retrieved. This is because different signature algorithms use different key pairs, and only by obtaining the correct public key can the corresponding signature be verified.

[0093] Parse the second public key. The parsing process involves using the public key to recalculate the repository metadata using the corresponding signature algorithm, thereby obtaining the repository signature value to be compared. This repository signature value is a theoretical signature value calculated using the public key, assuming the repository metadata has not been tampered with and is from a legitimate source.

[0094] The signature value of the repository to be compared is then compared with the signature value of the target repository. If they match, this indicates that the repository metadata has not been modified since signing and that it was signed by a legitimate party holding the corresponding private key, thus passing verification. Because in asymmetric encryption, only when the correct private key is used for signing can the corresponding public key verify the same signature value. Once verification passes, it proves that the repository metadata in the storage module is reliable and the signed software package corresponding to this repository metadata is also safe and complete. At this point, the signed software package can be downloaded from the storage module, ensuring that the downloaded software package is from a reliable source and has not been tampered with, thus ensuring the security of the entire software package download process.

[0095] It's important to understand that the first target signature algorithm verifies the software package signature value, ensuring the authenticity and integrity of the software package itself; the second target signature algorithm verifies the repository metadata signature value, ensuring the reliability of the repository metadata. While the two target verification targets are different, the algorithm can be used to simplify the verification process or to enhance security based on different security requirements and policies. This application does not limit this.

[0096] In an exemplary embodiment, obtaining the second public key of the second target signature algorithm corresponding to the target warehouse signature value includes: determining whether the conditions for updating the second public key are met; if so, obtaining the updated second public key corresponding to the second target signature algorithm from a preset platform; if not, calling the second public key corresponding to the second target signature algorithm stored in itself.

[0097] Specifically, this embodiment is used to ensure that during the software package download process, the second public key used to verify the target warehouse signature value is always safe, valid and up-to-date, thereby ensuring the accuracy and reliability of the warehouse metadata signature verification, and ultimately ensuring the security and integrity of the downloaded software package.

[0098] In asymmetric encryption systems, public keys are a crucial element for verifying digital signatures. Over time, due to changing security requirements or potential security vulnerabilities, public keys may need to be updated. Therefore, when obtaining the second public key for the second target signature algorithm corresponding to the target repository's signature value, the system first determines whether it meets the conditions for updating the second public key. This step acts as a "safety check" for the use of public keys, evaluating the current state to determine whether a new public key is necessary.

[0099] If the judgment result indicates that the update conditions are met, this means that the currently stored second public key may no longer be secure, valid, or compliant with the latest security policies. At this point, the updated second public key corresponding to the second target signature algorithm is obtained from the preset platform. The preset platform is usually a data source that has undergone strict security authentication and management, and it can provide the latest and secure public key information. Obtaining the updated public key from the preset platform is like replacing the verification process with a "new key", which can more accurately verify the signature of the warehouse metadata and prevent verification failure or security risks caused by the use of old, insecure public keys.

[0100] If the update conditions are not met, the second public key corresponding to the second target signature algorithm currently stored by the application is still secure and valid and can continue to be used. In this case, the stored second public key is used for signature verification. This avoids unnecessary public key updates, reduces system resource consumption and time costs, and ensures a smooth verification process.

[0101] In summary, this mechanism of first determining the update conditions and then determining the method for obtaining the public key based on the determination is a flexible and efficient public key management strategy. While ensuring the security of software package downloads, it also balances the rational use of system resources and the efficiency of the verification process, making the entire software package processing process more stable and reliable.

[0102] In an exemplary embodiment, determining whether a condition for updating the second public key is met includes: determining whether the software package is downloaded from the storage module for the first time, or determining whether a software package signature value of the software package is detected to have been changed; if the software package is downloaded from the storage module for the first time or the software package signature value is detected to have been changed, determining that the condition for updating the second public key is met; otherwise, determining that the condition for updating the second public key is not met.

[0103] Specifically, by determining whether the conditions for updating the second public key are met, the public key used during the software package download process is ensured to be always accurate and valid, thereby ensuring the reliability of the repository metadata signature verification and maintaining the security and integrity of the software package download.

[0104] Specifically, whether the conditions for updating the second public key are met is judged from two aspects.

[0105] First, determine whether this is the first time the software package has been downloaded from the storage module. When the client performs a download operation for the first time, since the corresponding public key has not been used for verification before, it cannot determine whether the second public key currently stored by itself matches the signature algorithm of the repository metadata in the storage module. The storage module may use a new signature algorithm or public key version. If the old or mismatched public key is used for verification, verification may fail or the legitimate signature may not be recognized. Therefore, updating the second public key during the first download can ensure that the public key used is consistent with the signature algorithm and policy of the current storage module, improving the accuracy of verification.

[0106] Secondly, determine whether a change in the package signature value has been detected. A change in the package signature value indicates that the package's signature algorithm, signing key, or signature data may have changed. This may be due to security policy adjustments, algorithm upgrades, or changes in the package source. If the signature value has changed and the client still uses the old public key for verification, it is likely to fail verification, even if the package itself is legitimate. Therefore, updating the second public key when a package signature value change is detected ensures that the public key matches the new signature value, ensuring the effectiveness of the verification process.

[0107] If either of the above two conditions is met, the conditions for updating the second public key are met, and the updated second public key is obtained from the preset platform to adapt to the new signature verification requirements. If neither condition is met, it means that the currently used public key may still be valid, and the existing public key will continue to be used for verification, avoiding unnecessary public key updates and reducing system resource consumption and time costs.

[0108] In summary, this judgment mechanism based on first download and signature value replacement is a public key management strategy that balances security and efficiency. It can flexibly adjust the use of public keys according to actual conditions to ensure the security and reliability of the software package download process.

[0109] like Figure 6 The figure shows the interaction between the packaging module, storage module, and client module. The packaging module pushes the binary package to the storage module. The client module obtains the public key corresponding to the binary package from the packaging module and the public key and binary package corresponding to the repository metadata from the storage module, forming a three-way data flow interaction structure.

[0110] First, a security device, such as a TPM, must be deployed in the packaging module's hardware. The packaging module must enable Secure Boot and dynamic trusted authentication to dynamically verify the integrity of each security component within the packaging module. Furthermore, the packaging module must deploy the packaging program and signature private key within a trusted execution environment (TEE). Within this trusted execution environment, the source code is packaged. For example, if Intel SGX is used to create an enclave, an enclave quote is generated, consisting of the enclave's hash value and a signature using a private key certified by a third-party CA. The third-party CA must be a nationally recognized CA center. For example, in China, this can be a sub-CA of the National Electronic Certification Root CA. Next, the TPM's PCR value (reflecting platform startup and software status) is obtained and signed with the TPM's Attestation Identity Key (AIK). The AIK must be a private key certified by a third-party CA and embedded in the TPM security chip. The requirements for third-party CAs are the same as above. Finally, bind SGXQuote and TPM signature data (PCR value + signature) to generate a unified attestation report.

[0111] Secondly, when the client module wants to download a binary package, it checks the local repository configuration item "RemoteRepositoryCheck". If the value of this item is 1, the client module determines whether this is the first time the binary package is downloaded from the remote repository, or whether it has detected that the packaging module's signature key has been rotated or replaced. In this case, the client module needs to update the signature public key to download the binary package. If the client module detects either of these scenarios, it will contact the packaging module to verify the security of the runtime environment. Only packages generated in a secure runtime environment are trustworthy. The client module also deploys security devices such as a TPM, which contains the public key of a trusted third-party root CA, such as the national electronic certification root CA. The client first obtains remote attestation from the packaging module. In the obtained remote attestation information, the signature of the PCR value is first verified using the TPM's public key (AIK). The public key authentication chain must extend to the root CA, such as the national electronic certification root CA's public key. The PCR value is compared with the expected secure boot configuration (e.g., a known correct hash value). The SGXQuote is then verified to ensure the legitimacy and integrity of the trusted environment enclave. Comprehensive verification ensures nonce matching (preventing replay attacks) and confirms that the SGX enclave is running on a verified TPM platform. At this point, the client module has verified the security and trustworthiness of the packaging environment and obtained the signature public key used during the binary package packaging process through a secure channel within the packaging environment. Using a secure channel in a secure and trusted environment ensures the authenticity of the locally obtained signature public key. The signature public key is then stored in a local repository for subsequent binary package signature verification. Simultaneously, the signature public key's hash value is recorded in the TPM security chip. This process is only required when obtaining the signature public key for the first time or when updating the signature key to ensure the security and trustworthiness of the signature public key. Subsequent downloads of the binary package for signature verification require only a comparison of the signature public key hash value in the local repository with the hash value in the TPM security chip. This ensures the security of the signature public key while also balancing efficiency.

[0112] The process of obtaining the remote warehouse security and trustworthiness and the signature public key of the warehouse metadata between the client module and the storage module is similar to the above process and will not be repeated here.

[0113] like Figure 7 , which illustrates the interaction between a client and a storage module. The process is as follows: 1. The client initiates a request; 2. The server generates an attestation report (platform configuration register value + metadata signature); 3. The client verifies the server's attestation; 4. The client generates its own attestation report (platform configuration register value + signature); 5. The server verifies the client's attestation; 6. After two-way verification is successful, 7. The client requests the signature public key over a secure channel; 8. The server sends the signature public key over a secure channel.

[0114] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0115] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned software package processing method embodiments.

[0116] For descriptions of features in the embodiments corresponding to the electronic device, reference can be made to the relevant descriptions of the embodiments corresponding to the processing method of the software package, which will not be repeated here.

[0117] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned software package processing method embodiments when run.

[0118] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0119] For descriptions of features in the embodiments corresponding to the computer-readable storage medium, reference may be made to the relevant descriptions of the embodiments corresponding to the processing method of the software package, which will not be detailed here.

[0120] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned software package processing method embodiments are implemented.

[0121] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned software package processing method embodiments are implemented.

[0122] For descriptions of features in the embodiments corresponding to the computer program product, reference can be made to the relevant descriptions of the embodiments corresponding to the processing method of the software package, which will not be repeated here.

[0123] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0124] The above describes in detail the processing method, device, medium, and program product of a software package provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core concept of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, various improvements and modifications may be made to the present application, and such improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for processing a software package, characterized in that: include: Compile the source code into a package; Sign the software package using at least two signature algorithms to obtain software package signature values corresponding to the signature algorithms, wherein the signature algorithms include national secret algorithms and international algorithms; The software package signature value is written into the header information of the software package, and the signed software package is pushed to the storage module, so that the client can select a signature algorithm according to needs to verify the software package signature value when downloading the software package from the storage module.

2. The method for processing a software package according to claim 1, wherein: After pushing the signed package to the repository, also include: triggering the storage module to generate warehouse metadata according to the signed software package; The warehouse metadata is signed using at least two signature algorithms to obtain warehouse signature values corresponding to the signature algorithms; so that when the client downloads the software package from the storage module, the signature algorithm is selected according to the needs to verify the warehouse signature value.

3. The method for processing a software package according to claim 1 or 2, characterized in that: After compiling the source code into a package, it also includes: Concatenate the software package and the random number to obtain data to be signed; Signing the software package using at least two signature algorithms to obtain software package signature values corresponding to the signature algorithms includes: Sign the data to be signed using at least two signature algorithms to obtain software package signature values corresponding to the signature algorithms; Write the software package signature value into the software package header information, including: The software package signature value and the random number are synchronously written into the header information of the software package.

4. A method for processing a software package, characterized in that: include: Obtaining a preset security policy and downloading a signed software package from the storage module; directly installing the software package according to the preset security policy, or determining at least one target software package signature value, verifying the target software package signature value, and installing the software package after the verification passes; The target software package signature value is a subset of all software package signature values.

5. The method for processing a software package according to claim 4, wherein: Verifying the signature value of the target software package and installing the software package after the verification passes, including: Obtaining a first public key of a first target signature algorithm corresponding to the signature value of the target software package; Parsing the first public key to obtain a signature value of the software package to be compared; Determine whether the signature value of the software package to be compared is the same as the signature value of the target software package; If they are the same, the verification is determined to be successful and the software package is installed.

6. The method for processing a software package according to claim 4, wherein: Directly installing a software package according to the preset security policy, or determining at least one target software package signature value, including: Acquire a first configuration item in the storage module; the preset security policy includes the first configuration item; When the first configuration item is a first preset value, determining to directly install the software package; When the first configuration item is not the first preset value, a target software package signature value corresponding to at least one target signature algorithm is determined based on the value of the first configuration item and a first mapping relationship; the first mapping relationship includes a correspondence between the value of the first configuration item and the signature algorithm.

7. The method for processing a software package according to claim 6, wherein: The number of target signature algorithms determined according to the value of the first configuration item is greater than 1; Verifying the signature value of the target software package and installing the software package after the verification passes, including: Obtaining the priority of the target signature algorithm; Verifying the target software package signature values corresponding to the target signature algorithm in order of priority; When the number of target software package signature values that pass the verification is greater than a preset number, the software package is installed; the preset number is not greater than the number of target signature algorithms.

8. The method for processing a software package according to any one of claims 4 to 7, characterized in that: Before downloading the signed software package from the storage module, the method further includes: Determine according to the preset security policy whether to directly download the signed software package from the storage module, or determine at least one target warehouse signature value, verify the target warehouse signature value, and download the signed software package from the storage module after the verification passes.

9. The method for processing a software package according to claim 8, wherein: Determining to download a signed software package directly from the storage module according to the preset security policy, or determining at least one target warehouse signature value, includes: Obtaining a second configuration item in the storage module; When the second configuration item is a second preset value, directly downloading the signed software package from the storage module; When the second configuration item is not the second preset value, the target warehouse signature value corresponding to at least one target signature algorithm is determined according to the value of the second configuration item and the second mapping relationship; the second mapping relationship includes the correspondence between the value of the second configuration item and the signature algorithm.

10. The method for processing a software package according to claim 8, wherein: Verifying the signature value of the target warehouse and, after passing the verification, downloading the signed software package from the storage module, including: Obtaining a second public key of a second target signature algorithm corresponding to the target warehouse signature value; Parse the second public key to obtain the warehouse signature value to be compared; Determine whether the signature value of the warehouse to be compared is the same as the signature value of the target warehouse; If they are the same, it is determined that the verification is successful, and the signed software package is downloaded from the storage module.

11. The method for processing a software package according to claim 10, wherein: Obtaining a second public key of a second target signature algorithm corresponding to the target warehouse signature value, including: Determine whether the condition for updating the second public key is met; If satisfied, obtain the updated second public key corresponding to the second target signature algorithm from the preset platform; If not satisfied, call the second public key corresponding to the second target signature algorithm stored in itself.

12. The method for processing a software package according to claim 11, wherein: Determining whether the condition for updating the second public key is met includes: determining whether the software package is downloaded from the storage module for the first time, or determining whether a software package signature value of the software package has been detected to have been changed; If the software package is downloaded from the storage module for the first time or it is detected that the software package signature value of the software package has been changed, it is determined that the condition for updating the second public key is met; otherwise, it is determined that the condition for updating the second public key is not met.

13. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the method for processing a software package according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the method for processing a software package according to any one of claims 1 to 12 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for processing a software package according to any one of claims 1 to 12 are implemented.

Images