A certificate white list management method compatible with a multi-signature scheme and related devices

Abstract

This application discloses a certificate whitelist management method and related apparatus compatible with multi-signature schemes, which improves deployment efficiency and accuracy. The application includes: extracting all signing certificates from multiple application packages to be managed; parsing the issuer field and subject field of each signing certificate to identify the parent-child trust relationship between all signing certificates; constructing a trust chain based on the parent-child trust relationship, wherein the trust chain is a complete trust chain from the root certificate to the leaf certificates; generating whitelist data based on the trust chain and the signing certificates; and performing signature verification on the application to be installed based on the whitelist data.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a certificate whitelist management method and related apparatus compatible with multi-signature schemes. Background Technology

[0002] As Android versions continue to update, the signing scheme has evolved from the initial V1 (based on JAR signing) to V2 (APK signing scheme), V3 (supporting key rotation), and V3.1 (enhanced security) to meet the security needs at different stages. In enterprise application deployment scenarios, to ensure that only approved applications are allowed to be installed on terminal devices, a certificate whitelist mechanism is usually adopted. The device verifies the application by comparing the signing certificate when installing the application.

[0003] Traditional whitelist management requires administrators to manually extract certificates from APK files using tools like keytool and openssl. The extracted certificates are then entered into a whitelist configuration file and pre-installed on the device. When an application is installed, the device retrieves the application's signing certificate and compares it to certificates in the whitelist. If a match is found, installation is allowed; otherwise, it is prohibited.

[0004] However, the certificate extraction and whitelist generation process relies on manual operation. Administrators need to process APK files one by one and manually update configuration files. When enterprises need to manage hundreds or thousands of applications, this process is cumbersome and time-consuming, and it is easy to introduce incorrect certificate information due to operational errors, resulting in trusted applications being mistakenly blocked or untrusted applications being mistakenly allowed. This makes it difficult to meet the efficiency and accuracy requirements of large-scale enterprise application deployment. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a certificate whitelist management method and related apparatus that are compatible with multi-signature schemes, which can improve deployment efficiency and accuracy.

[0006] The technical solution provided in this application is described below:

[0007] The first aspect of this application provides a certificate whitelist management method compatible with multi-signature schemes, including: Extract all signing certificates from multiple application packages to be managed; Parse the issuer and subject fields of each signing certificate to identify the parent-child trust relationships among all signing certificates; A trust chain is constructed based on the parent-child trust relationship, and the trust chain is a complete trust chain from the root certificate to the leaf certificate. Generate whitelist data based on the trust chain and the signature certificate; The application to be installed is signed and verified based on the whitelist data.

[0008] Optionally, the step of performing signature verification on the application to be installed based on the whitelist data includes: The whitelist data is sent to the cloud server so that the cloud server can perform signature verification on the application to be installed based on the whitelist data.

[0009] Optionally, the step of performing signature verification on the application to be installed based on the whitelist data includes: The hash value of each signature certificate in the whitelist data is stored in the blockchain; The application to be installed is signed and verified using the hash value stored within the blockchain.

[0010] Optionally, the application to be installed may be signed based on the whitelist data, including: The whitelist data is imported into the hardware security module so that the hardware security module can perform signature verification on the application to be installed based on the whitelist data.

[0011] Optionally, the step of extracting all signing certificates from multiple application packages to be managed includes: Locate the central directory structure of the application package; Determine whether the application package contains a signature block based on the central directory structure; If not included, extract the certificate of the V1 signing scheme based on JAR signing from the application package; If included, then the signature identifiers corresponding to the other signature schemes besides the V1 signature scheme are determined from the signature block, and the certificates corresponding to each signature scheme are extracted based on the signature identifiers.

[0012] Optionally, generating whitelist data based on the trust chain and the signing certificate includes: All the signature certificates are deduplicated to obtain a set of certificates without redundancy; Whitelist data is generated based on the trust chain and the set of certificates without redundancy.

[0013] Optionally, the certificate whitelist management method further includes: Monitor the status of all the signing certificates and identify the target signing certificate whose status has changed, including certificate revocation, certificate addition, and certificate renewal. Determine the trust chain associated with the target signing certificate and the associated application package; Based on the associated trust chain and the associated application package, a whitelist entry associated with the state change is generated to obtain incremental whitelist data; Update the locally stored whitelist data based on the incremental whitelist data.

[0014] The second aspect of this application provides a certificate whitelist management device compatible with multi-signature schemes, including: The extraction unit is used to extract all signing certificates from multiple application packages to be managed. The parsing unit is used to parse the issuer and subject fields of each signing certificate to identify the parent-child trust relationship between all signing certificates; A building unit is used to build a trust chain based on the parent-child trust relationship, wherein the trust chain is a complete trust chain from the root certificate to the leaf certificate; A generation unit is used to generate whitelist data based on the trust chain and the signing certificate; The verification unit is used to perform signature verification on the application to be installed based on the whitelist data.

[0015] Optionally, the verification unit is specifically used to send the whitelist data to the cloud server, so that the cloud server performs signature verification on the application to be installed based on the whitelist data.

[0016] Optionally, the verification unit is specifically used to store the hash value of each signature certificate in the whitelist data to the blockchain; The application to be installed is signed and verified using the hash value stored within the blockchain.

[0017] Optionally, the verification unit is specifically used to import the whitelist data into the hardware security module, so that the hardware security module performs signature verification on the application to be installed based on the whitelist data.

[0018] Optionally, the extraction unit is specifically used to locate the central directory structure of the application package; Determine whether the application package contains a signature block based on the central directory structure; If not included, extract the certificate of the V1 signing scheme based on JAR signing from the application package; If included, then the signature identifiers corresponding to the other signature schemes besides the V1 signature scheme are determined from the signature block, and the certificates corresponding to each signature scheme are extracted based on the signature identifiers.

[0019] Optionally, the generation unit is specifically used to deduplicatize all the signature certificates to obtain a set of certificates without redundancy; Whitelist data is generated based on the trust chain and the set of certificates without redundancy.

[0020] Optionally, the certificate whitelist management device further includes: The monitoring unit is used to monitor the status of all the signing certificates and determine the target signing certificate whose status has changed, including certificate revocation, certificate addition, and certificate renewal. A determining unit is used to determine the trust chain associated with the target signing certificate and the associated application package; An incremental unit is used to generate a whitelist entry associated with the state change based on the associated trust chain and the associated application package, thereby obtaining incremental whitelist data. The update unit is used to update the locally stored whitelist data based on the incremental whitelist data.

[0021] A third aspect of this application provides a certificate whitelist management device compatible with multi-signature schemes, comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the first aspect and any one of the optional methods in the first aspect.

[0022] A fourth aspect of this application provides a computer-readable storage medium on which a program is stored, which, when executed on a computer, performs the methods of the first aspect and any one of the first aspects.

[0023] As can be seen from the above technical solutions, this application has the following beneficial effects: In this application, all signing certificates are extracted from multiple application packages to be managed, and each signing certificate is parsed to identify the parent-child trust relationship between them, thereby constructing a trust chain from the root certificate to the leaf certificates. Based on this trust chain and the signing certificates, a whitelist is generated, and finally, the signature verification of the application to be installed is performed according to the whitelist data. This achieves the extraction of certificates and the generation of whitelists under different signing schemes, solving the problem of certificate omissions or incompatibility caused by existing technologies that only support a single signing scheme.

[0024] Furthermore, from certificate extraction, relationship identification, trust chain construction to whitelist generation, the entire process requires no manual intervention, reducing the tedious operation of traditional manual processing. Therefore, it can reduce the risk of introducing incorrect certificate information due to human error and improve the efficiency and accuracy of application deployment for large-scale enterprises. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of one embodiment of a certificate whitelist management method compatible with multi-signature schemes according to this application; Figure 2 This is a schematic diagram of an embodiment of the present application for extracting a signature certificate based on a signature block in a central directory structure; Figure 3 This is a schematic diagram of an embodiment of the present application that performs deduplication processing on the signature certificate before generating whitelist data; Figure 4 This is a schematic diagram of one embodiment of updating whitelist data in this application; Figure 5 This is a schematic diagram of one embodiment of a certificate whitelist management device compatible with multi-signature schemes according to this application; Figure 6 This is a schematic diagram of another embodiment of a certificate whitelist management device compatible with multi-signature schemes according to this application. Detailed Implementation

[0027] To address the problems of incompatibility between multiple Android signing schemes and the cumbersome manual operation and update process of whitelist maintenance in existing certificate management tools, which lead to low efficiency in enterprise application deployment, this application proposes a certificate whitelist management method compatible with multiple signing schemes. This method automatically extracts all signing certificates from the application package to be managed, parses the issuer and subject fields of each certificate to identify the parent-child trust relationship between certificates, constructs a trust chain from the root certificate to the leaf certificates, generates whitelist data based on this trust chain and signing certificates, and performs signature verification on the application to be installed based on this whitelist data. This achieves compatibility with multiple signing schemes and automates certificate extraction, whitelist generation, and distribution. It solves the shortcomings of traditional solutions, such as certificate omissions due to differences in signing schemes and cumbersome and error-prone manual operations, thereby improving the deployment efficiency and security of large-scale enterprise applications.

[0028] It should be noted that the certificate whitelist management method compatible with multi-signature schemes provided in this application can be applied to terminals, systems, and servers. For ease of explanation, the following detailed description will focus on a system as the implementation subject.

[0029] Please see Figure 1This application first provides an embodiment of a certificate whitelist management method compatible with multi-signature schemes, which includes: 101. Extract all signing certificates from multiple application packages to be managed.

[0030] An application package is an installation file for an Android application, with the extension APK (Android Package). It contains the application's code, resources, and signature information.

[0031] A signing certificate is an electronic file used to digitally sign an application. It contains the certificate owner's public key, identity information, and issuer information, and is used to verify the application's origin and integrity. Android applications support multiple signing schemes (such as Signing Scheme V1, Signing Scheme V2, Signing Scheme V3, and Signing Scheme V3.1).

[0032] In this embodiment, after obtaining the set of application packages to be managed, the system determines the certificate storage area for each APK file based on the characteristics of its signing scheme. Specifically, for APKs containing only V1 signatures, the certificate is extracted from the .SF and .RSA files under the META-INF directory; for APKs containing V2 and above signatures (V3, V3.1), the signing block is found by parsing the central directory structure of the APK, and the certificates embedded in the V3.1, V3, and V2 signing blocks are extracted according to the magic number and identifier of each signing scheme.

[0033] If an APK contains certificates from multiple signing schemes, all of them are extracted and retained. This ultimately yields the raw data of all signing certificates for all applications to be managed.

[0034] 102. Parse the issuer and subject fields of each signing certificate to identify the parent-child trust relationship between all signing certificates.

[0035] The issuer field refers to the name of the Certificate Authority (CA) that issued the certificate. For example, if certificate B is issued by certificate A, then the value of the issuer field of certificate B is the same as the value of the subject field of certificate A.

[0036] The subject field refers to the name that identifies the certificate holder in the certificate, i.e., the identity of the current certificate.

[0037] A parent-child trust relationship refers to the issuing relationship between certificates. For example, if certificate A issues certificate B, then A is the parent certificate of B, and B is the child certificate of A. This embodiment can determine the hierarchical relationship between all certificates by comparing the issuer field of a certificate with the subject field of another certificate.

[0038] During the parsing process, a certificate parsing library, such as the X.509 parsing library, is used to read the issuer and subject fields of each certificate. Specifically, for the current certificate, the value of its issuer field is retrieved, and then it is checked whether a certificate exists with the exact same subject field value. If it exists, it means that the current certificate was issued by the found certificate, and this parent-child relationship is recorded.

[0039] If it does not exist, it means that the current certificate is a self-signed certificate (the issuer is equal to its own subject), and it is considered a root certificate. Alternatively, if the issuer of the current certificate is not in the current certificate set, it means that the current certificate is an orphan certificate (e.g., issued by an external CA but not under management), and it can be marked separately or handled according to a preset policy (e.g., regarded as untrusted).

[0040] For example, there are three certificates: Certificate A: Subject = "CN=RootCA,O=Company", Issuer = "CN=RootCA,O=Company" (Self-signed, meaning the issuer is the same as the subject) Certificate B: Subject = "CN=IntermediateCA, O=Company", Issuer = "CN=RootCA, O=Company" Certificate C: Subject = "CN=AppSigner, O=Company", Issuer = "CN=IntermediateCA, O=Company".

[0041] After analyzing these three certificates, the following results were obtained: Certificate A: Since the issuer is equal to the subject, A is determined to be the root certificate.

[0042] Certificate B: Search for the certificate with the subject "CN=RootCA, O=Company", find certificate A, and therefore record the parent-child relationship: A→B.

[0043] Certificate C: Find the certificate with the subject "CN=IntermediateCA, O=Company", find certificate B, and record the parent-child relationship: B→C.

[0044] Therefore, it can be concluded that certificate C is issued by certificate B, certificate B is issued by certificate A, and certificate A is the anchor of trust.

[0045] 103. Construct a trust chain based on the parent-child trust relationship. The trust chain is a complete trust chain from the root certificate to the leaf certificate.

[0046] The trust chain is an ordered sequence that starts with the root certificate, passes through intermediate certificates, and finally reaches the leaf certificates. When verifying application signatures, the device needs to be able to trace back from the application certificate to the trusted root certificate to ensure the certificate's legitimacy before installation can proceed.

[0047] Root certificates are certificates located at the top of the trust chain and are typically self-signed. Leaf certificates are certificates located at the bottom of the trust chain and are used directly to sign applications. The public key of a leaf certificate is used to verify the validity of the application signature.

[0048] In this embodiment, based on the parent-child relationship identified in step 102, starting from each certificate without a parent certificate (i.e., the root certificate or self-signed certificate), the process traverses downwards along the issuance relationship, sequentially connecting to its issued child certificates, until a leaf certificate without child certificates is reached. For each leaf certificate, the complete certificate sequence from the root certificate to that leaf certificate is recorded, forming a trust chain.

[0049] If multiple roots or branches exist, multiple trust chains are generated. It should also be noted that orphaned certificates whose root certificates cannot be traced can be individually marked or handled according to a preset strategy (e.g., treated as self-signed roots).

[0050] For example, in the three certificate examples in step 102, first identify all root certificates. Certificate A has no parent certificate (self-signed), so we start with certificate A.

[0051] Starting with certificate A, find the sub-certificates it directly issues: find certificate B.

[0052] Continue searching for the subcertificates issued by certificate B: find certificate C.

[0053] Upon reaching certificate C, which has no subcertificates, the process stops. A complete trust chain is formed from A to B to C.

[0054] If there are other branches (for example, another intermediate certificate D issues a leaf certificate E), then another chain is built starting from the root.

[0055] The final result is a set of trust chains, with each chain recorded as an ordered list, such as the list in the example above: [A, B, C].

[0056] 104. Generate whitelist data based on the trust chain and signature certificate.

[0057] Whitelist data refers to a collection of allowed application signing certificates and their trust chain information, which are usually stored in a structured format (such as JSON or XML) and compared during application installation.

[0058] In this embodiment, all trust chains are organized and duplicate certificates are removed (the same certificate may appear in multiple chains) to form a set of certificates without redundancy. The specific deduplication process will be described in detail in subsequent embodiments.

[0059] Then, the hierarchical relationship of each trust chain is preserved, that is, the complete chain path corresponding to each leaf certificate is recorded. This information is organized according to a preset data structure, such as storing the certificate fingerprint (SHA256) of each leaf certificate, the fingerprints of certificates at each level in the trust chain, and necessary metadata (such as package name association). Finally, a unified whitelist file or data stream is generated.

[0060] 105. Verify the signature of the application to be installed based on the whitelist data.

[0061] In this embodiment, when an application is to be installed, the system extracts the signing certificate of the application to be installed and verifies it based on the trust chain information in the whitelist data. During verification, the fingerprint of the certificate of the application to be installed is first calculated, and the system searches for a matching leaf certificate in the whitelist data. If a matching leaf certificate is found, the system further verifies whether the trust chain of the leaf certificate is complete and has not been tampered with. If the verification is successful, the installation is allowed; otherwise, it is rejected.

[0062] Optionally, in one feasible approach, the application to be installed is signed and verified by a cloud server. Specifically, whitelist data is sent to the cloud server. When all terminal devices of the enterprise are installing the application, they send a verification request to the cloud server. The cloud server then performs whitelist comparison and signature verification in a unified manner and returns the result to the terminal device (the result indicates whether installation is allowed or prohibited).

[0063] Alternatively, in another feasible approach, the application to be installed is signed and verified via a blockchain. First, the hash value of each signing certificate in the whitelist data is stored in the blockchain, and then the application to be installed is signed and verified based on the hash value stored in the blockchain.

[0064] Specifically, a blockchain node is a computer node participating in a blockchain network. When a terminal device needs to verify an application to be installed, it first extracts the hash value of the application's signing certificate. Then, the terminal, acting as a light node in the blockchain, initiates a query to the blockchain network to retrieve the trust chain hash record associated with that hash value. If the record does not exist on the blockchain, it indicates that the application is unauthorized.

[0065] If a record exists, the terminal device retrieves the list of trust chain hashes stored on the blockchain and verifies whether the hash of the complete certificate chain (from leaf to root) provided by the application to be installed matches the record on the chain. If they match, the application is trusted (installation is allowed); otherwise, installation is rejected.

[0066] Optionally, in another feasible approach, the hardware security module (HSM) performs signature verification on the DadaDa application to be installed. Specifically, the hardware security module (HSM) is a hardware device used to securely generate, store, and manage keys and certificates, and to provide cryptographic operation services. In this embodiment, whitelist data is imported into the HSM through a secure channel. The HSM can store the hash value or public key of the certificate and protect this data using its hardware-level security mechanisms. When the terminal device needs to install the application, the terminal device extracts the signature certificate chain of the application to be installed and sends the entire signature certificate chain to a verification service that interacts with the HSM (this service can run on a secure server and call the HSM through a proprietary API).

[0067] The verification service sends the signing certificate chain of the application to be installed to the HSM, requesting the HSM to verify the signature validity of the chain. The HSM uses the root certificate public key stored internally to verify the signature of the first certificate in the chain, then verifies the signatures of subsequent certificates in sequence, up to the leaf certificates. Simultaneously, the HSM checks whether each certificate in the chain is on a whitelist (i.e., whether it matches the imported public key). Finally, the HSM returns the verification result (pass / fail) to the verification service, which then returns the result to the terminal, which decides whether to install the application.

[0068] In this embodiment, all signing certificates are extracted from multiple application packages to be managed, and each signing certificate is parsed to identify the parent-child trust relationship between them, thereby constructing a trust chain from the root certificate to the leaf certificates. Based on this trust chain and the signing certificates, a whitelist is generated. Finally, the signature verification of the application to be installed is performed according to the whitelist data. This achieves the extraction of certificates and the generation of whitelists under different signing schemes, solving the problem of certificate omissions or incompatibility caused by existing technologies that only support a single signing scheme.

[0069] Furthermore, from certificate extraction, relationship identification, trust chain construction to whitelist generation, the entire process requires no manual intervention, reducing the tedious operation of traditional manual processing. Therefore, it can reduce the risk of introducing incorrect certificate information due to human error and improve the efficiency and accuracy of application deployment for large-scale enterprises.

[0070] Furthermore, traditional single-certificate verification only checks if the leaf certificate is on a whitelist, failing to determine whether the certificate was issued by a trusted entity. This application employs a complete trust chain verification, tracing back from the leaf certificate to the root certificate, verifying the validity of the signature at each level. This effectively identifies security threats such as certificate forgery and man-in-the-middle attacks, ensuring the authenticity and legitimacy of application signature sources. By establishing a complete trust chain from the root certificate to the leaf certificates, each application's signature certificate can be traced back to the enterprise's pre-defined trust anchors, forming a hierarchical and auditable trust relationship. This facilitates full lifecycle certificate management and security auditing for enterprises.

[0071] In step 101 above, it is necessary to extract the signing certificates for the multiple applications that the enterprise plans to deploy, in order to subsequently determine the parent-child relationships between the signing certificates. For instructions on extracting the signing certificates, please refer to [link / reference needed]. Figure 2 This application provides an embodiment for extracting a signature certificate based on signature blocks in a central directory structure, the embodiment including: The above describes how to extract all signing certificates from multiple application packages to be managed, including: 201. Locate the central directory structure of the application package.

[0072] The central directory structure is located at the end of the ZIP file and records the metadata of all files within the archive, including the name, compression method, and starting offset of each file. The APK Signing Block, introduced in signature schemes V2 and above, is located before the ZIP central directory structure. However, for ZIP format compatibility, the position of the signing block must be located using specific fields in the central directory structure.

[0073] In this embodiment, regardless of whether the APK contains a signature block, the location of the central directory needs to be determined first. For each ZIP file, the End of Central Directory Record (EOCD) is searched backwards from the end of the file. This record contains the starting offset and size of the central directory.

[0074] 202. Determine whether the application package contains a signature block based on the central directory structure.

[0075] The APK Signing Block is a data block introduced in signing schemes V2 and above, used to store signing information, certificates, and additional metadata. The signing block is located before the central directory structure of the ZIP file. The starting position of the signing block can be calculated backwards from the starting offset of the central directory, and the signing block itself contains a magic number to identify its existence.

[0076] Based on the starting offset of the central directory obtained in step 201, offsetting forward by a specified size (usually 8 bytes) will locate the end position of the signature block. Then, the length field of the signature block is parsed backward from that position. If the parsed length value is consistent with the length calculated from the starting offset of the central directory, and the signature block contains a fixed magic number (such as "APK SigBlock 42"), it can be determined that the APK contains a signature block, that is, the APK uses a V2 or higher signature scheme.

[0077] Conversely, if the signature block magic number is not found at the expected location, or the calculated length does not match the starting position of the central directory, it is determined that the APK does not contain a signature block, that is, it only uses the V1 signature scheme.

[0078] For example, App1.apk: uses only V1 signing (e.g., an older application signed with jarsigner). App2.apk: uses V2 signing (e.g., an application signed with apksigner, containing only the V2 scheme). App3.apk: uses V3 signing and enables key rotation (contains multiple certificates, and may be backward compatible with V2 signing).

[0079] When locating the central directory structure in step 201, the starting offset of the central directory for App1.apk is 0x123400, and its size is 0x2000 bytes. The starting offset of the central directory for App2.apk is 0x234500. The starting offset of the central directory for App3.apk is 0x345600.

[0080] During the judgment process, for App1.apk: offset forward 8 bytes from the starting offset 0x123400 in the central directory, read the length field, and compare it with the length calculated from the starting position in the central directory. No magic number of the signature block was found, so it was determined that no signature block was contained. At this time, step 203 is executed.

[0081] For App2.apk: Starting from the central directory offset of 0x234500, the signature block length field value is read as 0x1000, and the magic number "APK Sig Block 42" is found at the end of this area, thus determining that it contains a signature block. At this point, step 204 is executed.

[0082] For App3.apk: Starting from the central directory offset 0x345600, a signature block is detected, indicating that the file contains a signature block. Step 204 is then executed.

[0083] 203. If not included, extract the certificate of the V1 signing scheme based on JAR signing from the application package.

[0084] When it is determined that the APK does not contain a signature block, the certificate extraction method using the V1 signing scheme is as follows: Unzip the APK file, locate the META-INF directory, and search for all files with the extensions .RSA, .DSA, or .EC (the specific extension depends on the signing algorithm used). For each found file, use the PKCS#7 parsing library to extract the embedded certificate chain.

[0085] Assume the APK file contains a leaf certificate (subject "CN=Old App Signer, O=Company") and an intermediate certificate (subject "CN=Intermediate CA, O=Company"), but no root certificate (because the root certificate is usually not embedded). Save the two extracted certificates (leaf certificate and intermediate certificate) for subsequent processing.

[0086] 204. If included, determine the signature identifiers corresponding to the other signature schemes besides the V1 signature scheme from the signature block, and extract the certificates corresponding to each signature scheme based on the signature identifiers.

[0087] Other signature schemes besides the V1 signature scheme include the V2 signature scheme (APK signature scheme), the V3 signature scheme (supporting key rotation), and the V3.1 signature scheme (enhanced security).

[0088] The signature identifier is located within the signature block of signature schemes V2 and above. Each signature scheme corresponds to a specific ID; for example, the ID for a V2 signature is 0x7109871a, the ID for a V3 signature is 0xf05368c0, and the ID for a V3.1 signature is 0x1b93ad61. By looking up these IDs, the specific data block for the corresponding signature scheme can be located.

[0089] A signature block consists of multiple consecutive key-value pairs, each containing a 4-byte ID and a variable-length value. The value portion contains the signature data for the signature scheme, the certificate chain, and any additional attributes that may be required.

[0090] When it is determined that the APK contains a signature block, the signature block is parsed, and the specific parsing is as follows: First, locate the starting position of the signature block by moving forward from the starting offset of the central directory. Then, starting from the beginning of the signature block, read each key-value pair sequentially according to the format of the signature block, and check whether the ID of each key-value pair matches the signature identifier of V3.1, V3, or V2.

[0091] Since higher-version signature schemes (such as V3.1) will overwrite lower versions, and V3 and above support key rotation which may involve multiple certificates, this embodiment will extract the certificates in the priority order of V3.1→V3→V2. Specifically, it will first search for the key-value pair with ID 0x1b93ad61. If it exists, the certificate chain of the V3.1 signature scheme will be parsed from it; if it does not exist, it will continue searching for the V3 signature with ID 0xf05368c0; if it still does not exist, it will search for the V2 signature with ID 0x7109871a.

[0092] For each found signature scheme, parse its value portion and extract all embedded certificates (including leaf certificates and intermediate certificates). Additionally, it should be noted that an APK may contain multiple signature schemes simultaneously (e.g., both V2 and V3 for backward compatibility); in this case, extract the certificates from all existing signature schemes.

[0093] During the certificate extraction process, for example, for a key-value pair with ID 0x7109871a, its value is parsed to extract the certificate list. Assume the extracted list contains two certificates: a leaf certificate (subject "CN=App2 Signer, O=Company") and an intermediate certificate (subject "CN=Intermediate CA, O=Company"). These two certificates are then saved.

[0094] In this embodiment, by locating the central directory structure and determining the existence of signature blocks, and employing differentiated certificate extraction methods for APKs with and without signature blocks, especially for APKs containing signature blocks, the V3.1, V3, and V2 signature identifiers are identified by priority and the corresponding certificates are extracted. This achieves automatic compatibility and complete certificate extraction for signature schemes from V1 to V3.1. Thus, it ensures that the signature certificate of the application to be installed can be obtained regardless of the signature method used, avoiding interruptions in enterprise application deployment or failure of security verification due to signature scheme fragmentation.

[0095] Step 104 above has provided a detailed explanation of the generation of whitelist data. However, since the same signing certificate may appear in multiple application packages (e.g., multiple applications using the same signing certificate), or the same signing certificate may appear repeatedly in multiple signing schemes of an APK, please refer to the following section to avoid redundancy. Figure 3 This application provides an embodiment for deduplicating signature certificates before generating whitelist data, the embodiment including: 301. Perform deduplication on all signature certificates to obtain a set of certificates without redundancy.

[0096] During deduplication, all signed certificates extracted from all APKs to be managed are first collected to form an initial certificate list. Then, a unique identifier is calculated for each certificate, followed by the creation of a mapping table (such as a hash table). The certificate fingerprint is used as the key, and the certificate object as the value. For the current certificate, it is checked whether its fingerprint already exists in the mapping table. If it does not exist, the fingerprint and corresponding certificate are added to the mapping table; if they do exist, it is considered a duplicate certificate and does not need to be stored again. After checking all signed certificates in the initial certificate list, all values ​​in the mapping table constitute the deduplicated, non-redundant certificate set.

[0097] For example, extract certificate A and certificate B from APP1, and extract certificate A, certificate B and certificate C from APP2. At this time, certificate A and certificate B appear repeatedly. After deduplication, the set of certificates without redundancy is {certificate A, certificate B, certificate C}.

[0098] 302. Generate whitelist data based on the trust chain and a set of certificates without redundancy.

[0099] In this embodiment, a whitelist of data without redundancy is generated based on the trust chain and each signature certificate in the set of certificates without redundancy. The specific generation process has been described in detail in step 104 above, and will not be repeated here.

[0100] Following step 105 above, when an enterprise issues a newly released signing certificate or needs to revoke certain signing certificates, it needs to update the whitelist data promptly to prevent applications with revoked certificates from still being installed or to block the installation of applications corresponding to the newly signed certificates. Based on this, please refer to... Figure 4 This application provides an embodiment for updating whitelist data, which includes: 401. Monitor the status of all signing certificates and identify the target signing certificate whose status has changed, including certificate revocation, certificate addition, and certificate renewal.

[0101] Certificate status change refers to the changes that occur to a certificate during its lifecycle. Types of changes include certificate revocation, certificate addition, and certificate renewal.

[0102] When monitoring all signed certificates, you can periodically download the CRL or query the OCSP responder to obtain the certificate revocation status for certificates issued by public or enterprise CAs.

[0103] Alternatively, periodically scan the "validity period" field of all certificates, mark certificates that are about to expire (e.g., 30 days remaining) as "pending renewal", and mark expired certificates as "expired", triggering the renewal process.

[0104] Alternatively, it can interface with the company's internal certificate issuance system to receive certificate change notifications in real time.

[0105] During monitoring, one or more of the above methods can be used to track the status of all certificates.

[0106] When a change in the status of a certificate is detected, the certificate is marked as the "target signing certificate" and the change type (revocation, addition, renewal) and related timestamps are recorded.

[0107] 402. Determine the trust chain associated with the target signing certificate and the associated application package.

[0108] An associated trust chain refers to all trust chains that contain the target signing certificate. The target certificate may be a root certificate, an intermediate certificate, or a leaf certificate.

[0109] The associated application package refers to the application package that is signed using the leaf certificates in these trust chains (the trust chains associated with the target signing certificate).

[0110] In this embodiment, after building the trust chain in step 103, an inverted index is created to record which trust chains each certificate (fingerprint) appears in (i.e., which leaf certificate trust chains contain the certificate).

[0111] When extracting certificates in step 101, record which APKs use each leaf certificate (a leaf certificate may be used by multiple APKs).

[0112] Once the target signing certificate is identified, the mapping from certificate to trust chain is used to find all trust chains containing that certificate, resulting in a list of all affected leaf certificates. Then, the mapping from leaf certificates to application packages is used to find a list of application packages corresponding to each affected leaf certificate. Finally, all trust chains and application packages that need to be updated are obtained.

[0113] 403. Based on the associated trust chain and associated application package, generate whitelist entries associated with state changes to obtain incremental whitelist data.

[0114] Incremental whitelist data refers to data packets that contain only whitelist entries that have changed, including the operation type (such as add, delete, replace) and the specific content of the change, so as to efficiently update local storage.

[0115] In this embodiment, a corresponding incremental update instruction is generated based on the type of state change. Specifically, for certificate revocation: if a leaf certificate is revoked, the trust chain entry corresponding to that leaf certificate is deleted (removed from the whitelist). If an intermediate or root certificate is revoked, all trust chain entries containing that certificate are deleted. Then, a "delete" operation is generated, specifying the list of leaf certificate fingerprints to be deleted.

[0116] For adding certificates: Add a new leaf certificate and its trust chain (if some certificates already exist in the trust chain, only the new certificate and chain relationship need to be added). At this time, an "Add" operation is generated, providing new trust chain data (including details of the new certificate and chain relationship).

[0117] For certificate renewal: Renewal typically means that the old certificate is replaced by a new certificate, and the new certificate may share the same trust chain as the old certificate (the root and intermediate layers remain unchanged). In this case, a "replace" operation is generated, specifying that the old leaf certificate fingerprint is replaced by the new leaf certificate fingerprint, while providing details of the new certificate.

[0118] Understandably, if multiple certificates are changed at the same time, multiple operations can be combined.

[0119] 404. Update the locally stored whitelist data based on the incremental whitelist data.

[0120] After receiving the incremental whitelist data, the system modifies the locally stored whitelist data according to the operation type to ensure that the whitelist is always up-to-date.

[0121] Specifically, the system parses the operation type and change details. For a "delete" operation, it removes the specified leaf certificate entry and its trust chain from the whitelist. For an "add" operation, it adds the new certificate and trust chain to the whitelist. For a "replace" operation, it replaces the entry corresponding to the old certificate with the new certificate and updates the trust chain. Then, it updates the version number and timestamp to record this change.

[0122] In this embodiment, dynamic and automated updates of the whitelist are achieved by monitoring certificate status, locating the affected scope, generating incremental whitelist data, and updating existing whitelist data. This solves the cumbersome process of redeploying or manually pushing configuration files for certificate updates in traditional solutions, reduces operation and maintenance costs, shortens response time, and ensures that enterprise terminals can promptly block the installation of applications using revoked certificates and quickly accept applications with newly issued certificates.

[0123] In the foregoing embodiments, the specific implementation process of the method provided in this application has been described in detail. It should be understood that, to implement the above method, this application also provides corresponding devices and computer-readable storage media, the technical concepts of which are consistent with the foregoing method embodiments, and both are used to implement all or part of the steps in the foregoing method. The technical solutions of the devices and computer-readable storage media involved in this application will be further described below in conjunction with specific embodiments.

[0124] Please see Figure 5 This application also provides an embodiment of a certificate whitelist management device compatible with multi-signature schemes, the embodiment including: Extraction unit 501 is used to extract all signature certificates from multiple application packages to be managed; Parsing unit 502 is used to parse the issuer field and subject field of each signing certificate to identify the parent-child trust relationship between all signing certificates; Building unit 503 is used to build a trust chain based on the parent-child trust relationship. The trust chain is a complete trust chain from the root certificate to the leaf certificate. Generation unit 504 is used to generate whitelist data based on the trust chain and signature certificate; Verification unit 505 is used to perform signature verification on the application to be installed based on whitelist data.

[0125] Optionally, the verification unit 505 is specifically used to send whitelist data to the cloud server so that the cloud server can perform signature verification on the application to be installed based on the whitelist data.

[0126] Optionally, verification unit 505 is specifically used to store the hash value of each signing certificate in the whitelist data to the blockchain; The application to be installed is signed and verified using the hash value stored within the blockchain.

[0127] Optionally, the verification unit 505 is specifically used to import whitelist data into the hardware security module so that the hardware security module can perform signature verification on the application to be installed based on the whitelist data.

[0128] Optionally, the extraction unit 501 is specifically used to locate the central directory structure of the application package; Determine whether the application package contains a signature block based on the central directory structure; If not included, extract the V1 signing scheme certificate based on JAR signing from the application package; If included, the signature identifiers corresponding to the other signature schemes besides the V1 signature scheme are determined from the signature block, and the certificates corresponding to each signature scheme are extracted based on the signature identifiers.

[0129] Optionally, the generation unit 504 is specifically used to deduplicatize all signature certificates to obtain a set of certificates without redundancy; Whitelist data is generated based on the trust chain and a set of certificates without redundancy.

[0130] Optionally, the certificate whitelist management device also includes: The monitoring unit 506 is used to monitor the status of all signing certificates and identify the target signing certificate whose status has changed, including certificate revocation, certificate addition, and certificate renewal. The determining unit 507 is used to determine the trust chain associated with the target signing certificate and the associated application package; Incremental unit 508 is used to generate whitelist entries associated with state changes based on the associated trust chain and associated application package, and obtain incremental whitelist data. Update unit 509 is used to update the locally stored whitelist data based on the incremental whitelist data.

[0131] Please see Figure 6 This application also provides another embodiment of a certificate whitelist management device compatible with multi-signature schemes, which includes: Processor 601, memory 602, input / output unit 603, bus 604; The processor 601 is connected to the memory 602, the input / output unit 603, and the bus 604; The memory 602 stores a program, and the processor 601 calls the program to execute any of the methods described above.

[0132] This application also relates to a computer-readable storage medium on which a program is stored, which, when run on a computer, causes the computer to perform any of the methods described above.

[0133] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

Claims

1. A certificate whitelist management method compatible with multi-signature schemes, characterized in that, include: Extract all signing certificates from multiple application packages to be managed; Parse the issuer and subject fields of each signing certificate to identify the parent-child trust relationships among all signing certificates; A trust chain is constructed based on the parent-child trust relationship, and the trust chain is a complete trust chain from the root certificate to the leaf certificate. Generate whitelist data based on the trust chain and the signature certificate; The application to be installed is signed and verified based on the whitelist data.

2. The certificate whitelist management method according to claim 1, characterized in that, The signature verification of the application to be installed based on the whitelist data includes: The whitelist data is sent to the cloud server so that the cloud server can perform signature verification on the application to be installed based on the whitelist data.

3. The certificate whitelist management method according to claim 1, characterized in that, The signature verification of the application to be installed based on the whitelist data includes: The hash value of each signature certificate in the whitelist data is stored in the blockchain; The application to be installed is signed and verified using the hash value stored within the blockchain.

4. The certificate whitelist management method according to claim 1, characterized in that, The signature verification of the application to be installed based on the whitelist data includes: The whitelist data is imported into the hardware security module so that the hardware security module can perform signature verification on the application to be installed based on the whitelist data.

5. The certificate whitelist management method according to any one of claims 1 to 4, characterized in that, The process of extracting all signing certificates from multiple application packages to be managed includes: Locate the central directory structure of the application package; Determine whether the application package contains a signature block based on the central directory structure; If not included, extract the certificate of the V1 signing scheme based on JAR signing from the application package; If included, then the signature identifiers corresponding to the other signature schemes besides the V1 signature scheme are determined from the signature block, and the certificates corresponding to each signature scheme are extracted based on the signature identifiers.

6. The certificate whitelist management method according to any one of claims 1 to 4, characterized in that, The step of generating whitelist data based on the trust chain and the signing certificate includes: All the signature certificates are deduplicated to obtain a set of certificates without redundancy; Whitelist data is generated based on the trust chain and the set of certificates without redundancy.

7. The certificate whitelist management method according to any one of claims 1 to 4, characterized in that, The certificate whitelist management method also includes: Monitor the status of all the signing certificates and identify the target signing certificate whose status has changed, including certificate revocation, certificate addition, and certificate renewal. Determine the trust chain associated with the target signing certificate and the associated application package; Based on the associated trust chain and the associated application package, a whitelist entry associated with the state change is generated to obtain incremental whitelist data; Update the locally stored whitelist data based on the incremental whitelist data.

8. A certificate whitelist management device compatible with multi-signature schemes, characterized in that, include: The extraction unit is used to extract all signing certificates from multiple application packages to be managed. The parsing unit is used to parse the issuer and subject fields of each signing certificate to identify the parent-child trust relationship between all signing certificates; A building unit is used to build a trust chain based on the parent-child trust relationship, wherein the trust chain is a complete trust chain from the root certificate to the leaf certificate; A generation unit is used to generate whitelist data based on the trust chain and the signing certificate; The verification unit is used to perform signature verification on the application to be installed based on the whitelist data.

9. A certificate whitelist management device compatible with multi-signature schemes, characterized in that, include: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, performs the method as described in any one of claims 1 to 7.

Images