Cross-CA certificate issuing risk prevention and control method and system based on damaged key information aggregation

Abstract

The invention relates to the technical field of internet security, discloses a cross-CA certificate issuing risk prevention and control method and system based on damaged key information aggregation, and is used for solving the technical problems that in the prior art, information barriers among multiple CAs cannot be crossed, and certificate issuing risks caused by damaged keys cannot be prevented and controlled. Comprising the steps of obtaining a plurality of CRL responders published by a CA in a preset risk control range, and screening out a revocation certificate serial number leaked by a private key; generating a global unique normalized code according to the revocation certificate serial number and the corresponding CRL issuer name; main body public key information corresponding to the revocation certificate is searched in a CT log information database according to the globally unique normalized code; after target public key data corresponding to multiple private key leakage is obtained, a damaged key database is constructed; when the CA receives a certificate application request, acquiring a user public key and judging whether the user public key is in a damaged key database or not; and if yes, it is considered that there is a signing and issuing risk, and the certificate signing and issuing process with the risk is prevented.

Description

Technical Field

[0001] This invention relates to the field of Internet security technology, and in particular to a method, system, electronic device, computer storage medium, and computer program product for risk prevention and control of cross-CA certificate issuance based on compromised key intelligence aggregation. Background Technology

[0002] In a Web PKI (Web Public Key Infrastructure) system, the core of digital certificate security lies in protecting the private key from being leaked. Once a private key is leaked, the CA (Certificate Authority) must promptly publish revocation information through the CRL (Certificate Revocation List) to prevent the compromised key from being further misused.

[0003] However, current certificate key security protection mechanisms still face several key technical bottlenecks, specifically in the following three aspects: (1) The problem of intelligence silos: Each CA only has access to the revocation data of its own issued certificates, lacking a unified intelligence sharing mechanism across institutions and domains. In this context, if an attacker obtains a private key from a CA and causes it to be leaked, they can still use the corresponding public key to apply for a new certificate from another CA. Since the new CA cannot know in real time that the public key has been marked as compromised in other existing CA domains, there is a risk of the certificate being maliciously "signed" by another CA.

[0004] (2) Data availability deficiencies: The current CRL format only includes the SN (Serial Number) of the revoked certificate and the reason for revocation, but does not include key identifying information such as the Subject Public Key Info (SPKI). This makes it difficult for the relying party and other CAs to effectively compare and screen the submitted public key during the CSR (Certificate Signing Request) stage based on the existing CRL data.

[0005] (3) Cross-source matching consistency problem: The way different CAs represent fields such as the CRL issuer name in the CRL often differs from the records in the CT (Certificate Transparency) log. For example, there may be differences in the order of attribute fields, redundant spaces, or encoding variations as specified in RFC 4514. Such non-semantic differences significantly reduce the accuracy of automated queries based on string matching, making it difficult for the system to efficiently and reliably identify and associate compromised public keys.

[0006] In conclusion, there is an urgent need to build a mechanism that can break down intelligence barriers and support cross-CA sharing and collaborative verification of compromised key information, thereby achieving risk control in the certificate issuance process throughout the Web PKI ecosystem. Summary of the Invention

[0007] The main objective of this invention is to solve the technical problem that existing technologies cannot overcome the intelligence barriers between multiple CAs and cannot prevent and control the certificate issuance risks caused by damaged keys.

[0008] The first aspect of this invention provides a method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation, comprising: Obtain multiple CRL response bodies issued by CAs within a preset risk control range, and filter out the revocation certificate serial numbers whose revocation reason is private key leakage from each CRL response body; A globally unique normalized code is generated based on the revocation certificate serial number and the corresponding CRL issuer name, wherein the encoding rules of the globally unique normalized code are the same as those in the preset CT log information database; Based on the globally unique normalized encoding, the public key information corresponding to the revoked certificate is searched in the CT log information database to obtain target public key data corresponding to multiple leaked private keys; The target public key data of each target are aggregated to construct a database of compromised keys. When any CA receives a certificate request, it obtains the user's public key contained in the certificate request. Determine whether the user's public key is in the compromised key database. If it is, then there is a risk of issuance, and the certificate issuance process with the risk of issuance is blocked.

[0009] Optionally, in a first implementation of the first aspect of the present invention, before obtaining the multiple CRL response bodies issued by the CA within the preset risk control range, the method further includes: Retrieve all trusted CAs recorded in the public CA database; Select target CAs that can issue HTTPS certificates from trusted CAs to obtain CAs within the preset risk control range.

[0010] Optionally, in a second implementation of the first aspect of the present invention, generating a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name includes: The string of the CRL issuer name is segmented, denoised, and numerically normalized to obtain the normalized CRL issuer name string; Rearrange the items in the normalized CRL issuer name string according to the alphabetical order of the attribute keys; The revocation certificate serial number and the normalized CRL issuer name string are concatenated using a fixed delimiter to generate a globally unique normalized code.

[0011] Optionally, in a third implementation of the first aspect of the present invention, the step of performing word segmentation, noise reduction, and numerical normalization on the string of the CRL issuer name includes: The string of the CRL issuer name is segmented using comma delimiters; Remove whitespace characters at both ends of the string and redundant spaces inside the string attribute values ​​to achieve noise reduction; The attribute keys contained in the string are converted to uppercase, and the attribute values ​​in the string are converted to lowercase to achieve numerical normalization.

[0012] Optionally, in a fourth implementation of the first aspect of the present invention, after constructing the damaged key database, the method further includes: Periodically obtain multiple new CRL response bodies issued by CA within a preset risk control range, calculate the current hash value of the new CRL response bodies, and determine whether there is new information in the new CRL response bodies based on the changes in the current hash value. If it exists, parse and obtain the newly added CRL response body, and filter out the newly added revocation certificate serial number whose revocation reason is private key leakage; Based on the newly added revocation certificate serial number, search the CT log information database for the target public key data corresponding to the newly added leaked private key; The compromised key database is updated based on the newly added target public key data.

[0013] Optionally, in a fifth implementation of the first aspect of the present invention, determining whether the user's public key is in the compromised key database includes: Calculate the public key fingerprint using the user's public key; A Bloom filter is used to initially screen the public key fingerprint to determine whether it is suspected of being leaked. If a leak is suspected, a more precise query method is then used to check whether the user's public key is in the compromised key database.

[0014] A second aspect of the present invention provides a cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation, comprising: The intelligence aggregation module is used to acquire multiple CRL response bodies issued by CAs within a preset risk control range, and filter out revocation certificate serial numbers whose revocation reason is private key leakage from each CRL response body; generate a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name, wherein the encoding rules of the globally unique normalized code are the same as those in the preset CT log information database; search for the subject public key information corresponding to the revocation certificate in the CT log information database based on the globally unique normalized code to obtain target public key data corresponding to multiple leaked private keys; aggregate the target public key data to construct a compromised key database; The risk control module is used to obtain the user's public key contained in the certificate application request when any CA receives a certificate application request; determine whether the user's public key is in the damaged key database; if it is in the damaged key database, it is considered that there is a certificate issuance risk, and the certificate issuance process with the certificate issuance risk is blocked.

[0015] Optionally, in a first implementation of the second aspect of the present invention, the intelligence aggregation module further includes a range acquisition unit for acquiring all trusted CAs recorded in the public CA database; Select target CAs that can issue HTTPS certificates from trusted CAs to obtain CAs within the preset risk control range.

[0016] Optionally, in a second implementation of the second aspect of the present invention, the intelligence aggregation module includes a normalization coding unit, which is specifically used for: The string of the CRL issuer name is segmented, denoised, and numerically normalized to obtain the normalized CRL issuer name string; Rearrange the items in the normalized CRL issuer name string according to the alphabetical order of the attribute keys; The revocation certificate serial number and the normalized CRL issuer name string are concatenated using a fixed delimiter to generate a globally unique normalized code.

[0017] Optionally, in a third implementation of the second aspect of the present invention, the normalization coding unit is further used for: The string of the CRL issuer name is segmented using comma delimiters; Remove whitespace characters at both ends of the string and redundant spaces inside the string attribute values ​​to achieve noise reduction; The attribute keys contained in the string are converted to uppercase, and the attribute values ​​in the string are converted to lowercase to achieve numerical normalization.

[0018] Optionally, in a fourth implementation of the second aspect of the present invention, the cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation further includes an intelligence update unit, used for: Periodically obtain multiple new CRL response bodies issued by CA within a preset risk control range, calculate the current hash value of the new CRL response bodies, and determine whether there is new information in the new CRL response bodies based on the changes in the current hash value. If it exists, parse and obtain the newly added CRL response body, and filter out the newly added revocation certificate serial number whose revocation reason is private key leakage; Based on the newly added revocation certificate serial number, search the CT log information database for the target public key data corresponding to the newly added leaked private key; The compromised key database is updated based on the newly added target public key data.

[0019] Optionally, in a fifth implementation of the second aspect of the present invention, the risk control module is further configured to: Calculate the public key fingerprint using the user's public key; A Bloom filter is used to initially screen the public key fingerprint to determine whether it is suspected of being leaked. If a leak is suspected, a more precise query method is then used to check whether the user's public key is in the compromised key database.

[0020] A third aspect of the present invention provides a cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation to perform the steps of the aforementioned cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation.

[0021] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation.

[0022] A fifth aspect of the present invention provides a computer program product comprising a computer program / instruction that, when executed by a processor, implements the steps of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation described above.

[0023] The technical solution provided by this invention involves acquiring multiple CRL response bodies issued by CAs within a preset risk control range and filtering out revocation certificate serial numbers whose revocation is due to private key leakage. A globally unique normalized code is generated based on the revocation certificate serial number and the corresponding CRL issuer name. The encoding rules of this globally unique normalized code are the same as those in a preset CT log information database. The public key information corresponding to the revoked certificate is searched in the CT log information database based on the globally unique normalized code, yielding target public key data corresponding to multiple leaked private keys. These target public key data are aggregated to construct a compromised key database. When any CA receives a certificate application request, it acquires the user's public key contained in the request and determines whether the public key is in the compromised key database. If it is, a certificate issuance risk is considered, and the certificate issuance process with this risk is blocked. This method can overcome intelligence barriers between multiple CAs, detect public keys corresponding to certificates revoked by different CAs due to private key leakage, locate certificate issuance risks based on public keys, and implement risk prevention and control.

[0024] The system, electronic device, computer-readable storage medium, and computer program product provided by this invention also solve the corresponding technical problems. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the first embodiment of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation in this invention. Figure 2 This is a flowchart illustrating the second embodiment of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation in this invention. Figure 3 This is a schematic diagram of a module of an embodiment of the cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation in this invention. Figure 4 This is a schematic diagram of another embodiment of the cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation in this invention. Figure 5 This is a schematic diagram of an embodiment of a cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation in this invention. Figure 6 This is a schematic diagram illustrating the principle of a computer-readable medium according to an embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments of the invention will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limiting the invention to the embodiments set forth herein. Rather, these exemplary embodiments are provided to make the invention more comprehensive and complete, and to facilitate a full communication of the inventive concept to those skilled in the art. The same reference numerals in the drawings denote the same or similar elements, components, or parts, and therefore repeated descriptions of them will be omitted.

[0027] Subject to the technical concept of this invention, the features, structures, characteristics or other details described in a particular embodiment may be combined in one or more other embodiments in a suitable manner.

[0028] In the description of specific embodiments, the features, structures, characteristics, or other details described in this invention are intended to enable those skilled in the art to fully understand the embodiments. However, it is not excluded that those skilled in the art can practice the technical solutions of this invention without one or more of the specific features, structures, characteristics, or other details.

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

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

[0031] The terms “and / or” or “and / or” include all combinations of any one or more of the listed items.

[0032] See Figure 1 The first embodiment of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation in this invention includes: S101. Obtain multiple CRL response bodies issued by CA within the preset risk control range, and filter out the revocation certificate serial number whose revocation reason is private key leakage from each CRL response body; It is understood that the implementing entity of this invention can be a cross-CA certificate issuance risk prevention and control system that aggregates compromised key intelligence, or it can be a terminal or a server; the specific implementation is not limited here. Here, CA stands for Certificate Authority.

[0033] The embodiments of the present invention are illustrated using a server as the execution subject.

[0034] In this step, a preset risk control scope needs to be obtained first, and then the CRL (Certificate Revocation List) response bodies issued by the CAs included in the risk control scope need to be retrieved. After obtaining each CRL response body, the system parses its internal structure, checks each recorded revoked certificate entry, and filters out revoked certificate information whose revocation reason is private key leakage. In this embodiment, the filtered revoked certificate information is the revoked certificate serial number.

[0035] When obtaining the preset risk control scope, methods include, but are not limited to, setting filtering strategies for other items such as CRL issuer names and CRL distribution point URLs (Uniform Resource Locator) to define the scope, or manually configuring the CA list to exclude specific CAs. For example, the preset risk control scope can be obtained from the public CA database included in the existing public trust plan, which contains CAs marked as trusted.

[0036] The steps for obtaining the CRL response body are as follows: after obtaining the preset risk control range, obtain the distribution point URLs (such as HTTPS links) of the certificate revocation lists publicly released by these CAs, and automatically download the corresponding CRL files according to the distribution point URLs to obtain multiple CRL response bodies.

[0037] S102. Generate a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name; In this embodiment, while filtering out revocation certificate serial numbers whose revocation reason is private key leakage in step S102, the CRL issuer name corresponding to the revocation certificate entry is also recorded. In this step, a globally unique normalized code is generated based on the revocation certificate serial number and the corresponding CRL issuer name. The specific method includes: performing word segmentation, noise reduction, and numerical normalization on the string of the CRL issuer name to obtain the normalized string of the CRL issuer name; rearranging the contents of the normalized CRL issuer name string according to the alphabetical order of the attribute keys; and concatenating the revocation certificate serial number and the normalized CRL issuer name string using a fixed delimiter to generate a globally unique normalized code.

[0038] The encoding rules of this globally unique normalized code are the same as those in the preset CT log information database, so that the corresponding principal public key information in the revocation certificate can be found in the CT log information database according to this globally unique normalized code.

[0039] S103. Based on the globally unique normalized encoding, search the CT log information database for the principal public key information corresponding to the revoked certificate to obtain the target public key data corresponding to multiple leaked private keys; The system first uses the globally unique normalized code generated from information extracted from the CRL to perform a precise query in a pre-built CT log information database. Since the CT log information database records the complete content of each issued certificate, including the Subject Public Key Info (SPKI), it can locate the subject public key information of the revoked certificate in the CT log information database based on the globally unique normalized code, thus obtaining real and verifiable public key data. Furthermore, because the revocation reason considered during the screening in S101 is private key leakage, the subject public key information located in this embodiment is the target public key data corresponding to the leaked private key.

[0040] S104. Aggregate the public key data of each target to construct a database of damaged keys; Subsequently, the public keys that have been revoked due to private key leakage and their metadata (such as algorithm type, validity period, source CA, etc.) are aggregated to build a structured database of damaged keys. This database not only contains public key fingerprints (such as the SHA256 hash value of the main public key information), but in some implementations, it also links the original certificate to the verification link on the public CT platform to support auditing and traceability.

[0041] S105. When any CA receives a certificate request, it obtains the user's public key contained in the certificate request. In this step, when a user sends a certificate application request to any Certificate Authority (CA), the CA, upon receiving the new certificate issuance request, does not immediately perform the actual certificate issuance. Instead, it first extracts the user's public key, which is the principal public key information included in the new certificate application request. Next, specific risk control steps can be performed to verify, based on the user's public key, whether the user's certificate has been revoked due to private key leakage.

[0042] S106. Determine whether the user's public key is in the compromised key database. If it is in the compromised key database, it is considered that there is a risk of issuance and the certificate issuance process with the risk of issuance is blocked.

[0043] After obtaining the user's public key contained in the certificate application request, information matching is performed on the compromised key database based on the user's public key to determine whether it exists in the compromised key database: if the match is successful, it is determined that there is a risk of misuse of the leaked private key, the certificate is automatically rejected and the security event is recorded, and a security warning message is given; if the match is not successful, the certificate issuance process is allowed to continue.

[0044] The method provided in this embodiment of the invention can overcome the intelligence barriers between multiple CAs, detect the public keys of certificates revoked by different CAs due to private key leakage, locate certificate issuance risks based on the public keys, and carry out risk prevention and control.

[0045] See Figure 2 The second embodiment of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation in this invention includes: S201. Obtain all trusted CAs recorded in the public CA database, filter out target CAs that can issue HTTPS certificates from the trusted CAs, and obtain CAs within the preset risk control range; It is understood that the executing entity of this invention can be a cross-CA certificate issuance risk prevention and control system that aggregates compromised key intelligence, or it can be a terminal or a server; the specific implementation is not limited here. This embodiment of the invention uses a server as an example for illustration. Here, CA stands for Certificate Authority.

[0046] The public CA database stores information in a structured format, including the issuer's name (Issuer Distinguished Name, Issuer DN), CRL (Certificate Revocation List) distribution point URL (Uniform Resource Locator), CT (Certificate Transparency) log submission policy, and CA status for each trusted CA globally.

[0047] This embodiment uses Mozilla's CCADB (Common CA Database) as an example of a public CA database implementation. CCADB records root certificate authorities (CAs) trusted by mainstream browsers (such as Firefox and Google), along with their related policies, technical requirements, and compliance status. The server initiates a data retrieval request to CCADB via a timer or by receiving trigger information, obtaining entries for all trusted CAs recorded in CCADB. It then filters out CAs capable of issuing HTTPS certificates from among the trusted CAs, selecting them as target CAs.

[0048] In one specific implementation, all CAs in CCADB with the TLS Capable flag can be used as the preset risk control range. Here, TLS Capable is a policy flag used in the Public Trust Root Certificate Scheme (which is also used in CCADB). Trusted CAs in the Public Trust Root Certificate Scheme can be filtered based on TLS Capable. In another implementation, filtering policies can be set for other items such as issuer name and CRL distribution point URL to define the range, or the preset risk control range can be set by manually configuring the CA list and excluding specific CAs.

[0049] In one specific implementation, when filtering out trusted CAs that can issue HTTPS (Hypertext Transfer Protocol Secure) certificates, the first step is to obtain and parse the entire dynamic list of Certificate Records (CCADB) and filter out CA entries with the TLS Capable flag. The TLS Capable flag indicates that the CA is allowed to issue terminal entity certificates for TLS (such as HTTPS). Such CAs may be used by attackers for phishing or man-in-the-middle certificate fraud, so they are included in the risk control scope in this embodiment.

[0050] S202. Obtain multiple CRL response bodies issued by CA within the preset risk control range, and filter out the revocation certificate serial number whose revocation reason is private key leakage from each CRL response body; After obtaining the preset risk control range, a data crawling engine is used to retrieve multiple CRL response bodies issued by CAs within that range. Each CRL response body contains the issuer name, certificate serial number, and revocation reason code extension. After parsing the CRL main structure, the revocation reason code extension is searched to filter out revocation certificate information where the revocation reason is private key leakage. In this embodiment, the filtered revocation certificate information with private key leakage as the revocation reason includes the revocation certificate serial number.

[0051] When a CA within the preset risk control scope is obtained via CCADB, the Full CRL and Partitioned CRLs fields are extracted from the certificate record entries. Subsequently, a global crawling queue is constructed using methods such as an asynchronous crawling engine. This queue is then used to filter valid entries and collect their CRL distribution points. If a distribution point is not empty, it is added to the crawling task queue to obtain the revocation certificate sequence number indicating that the revocation was due to private key leakage. Specifically, each crawling task must carry the name of its corresponding CRL issuer (from CCADB).

[0052] In one specific implementation, the steps for filtering revoked certificate sequence numbers whose revocation reason is private key leakage include: parsing the revoked certificate sequence in the X.509 CRL structure and filtering items in the extended field whose revocation reason code is "key Compromise (1)", wherein "key Compromise (1)" is the standard revocation reason code used in X.509 Public Key Infrastructure (PKI) to indicate "private key leakage".

[0053] S203. Generate a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name; Because the CRL issuer names defined by different CAs in the CRL may differ from the names recorded in the CT logs due to inconsistencies in field order and redundant spaces, conventional string matching algorithms have a high failure rate. Therefore, this embodiment sets a globally unique normalized encoding rule, and the globally unique normalized encoding is the same as the encoding rule in the preset CT log information database, so as to facilitate matching and querying; or, the encoding rule based on the revoked certificate serial number and CRL issuer name in this step can be adjusted so that the globally unique normalized encoding generated based on this encoding rule can match the names recorded in the CT log information database.

[0054] The process of generating a globally unique normalized code includes segmenting, denoising, and numerical normalization of the CRL issuer name string to obtain the normalized CRL issuer name string; rearranging the contents of the processed CRL issuer name string according to the alphabetical order of the attribute keys; and concatenating the sequence number and the normalized CRL issuer name string using a fixed delimiter to obtain the globally unique normalized code.

[0055] In one specific implementation, after filtering out revocation certificate information where the revocation reason is a leaked private key, its feature triples are extracted, including the revocation certificate serial number (SN), the corresponding CRL issuer distinguished name (Issuer DN), and the revocation date. Subsequently, the CRL issuer name string undergoes tokenization, denoising, and numerical normalization, including: tokenizing the issuer name string using commas as delimiters, where escape characters such as "\", "," and "`" are supported during segmentation; removing leading and trailing whitespace characters and redundant spaces within attribute values ​​of the CRL issuer name string for denoising; and converting attribute keys (such as CN`, OU`, etc.) in the CRL issuer name string to uppercase and attribute values ​​to lowercase for numerical normalization, resulting in the normalized CRL issuer name string (Normalized_Issuer). After normalization, the processed items are rearranged according to the alphabetical order of the attribute keys and concatenated with a fixed delimiter to obtain a globally unique normalized code. The format of this globally unique normalized code includes, but is not limited to, "<SN, Normalized_Issuer> ".

[0056] This step proposes a semantic standard alignment algorithm for CRL issuer names in X.509. This algorithm does not rely on the original character sequence, but instead decomposes inconsistently formatted name strings and other information items into atomic attribute sets, performing denoising, normalization, and lexicographical rearrangement. This achieves high-precision semantic matching across CRL and CT data sources, significantly improving accuracy.

[0057] S204. Based on the globally unique normalized encoding, search the CT log information database for the principal public key information corresponding to the revoked certificate to obtain the target public key data corresponding to multiple leaked private keys; Next, based on the globally unique normalized encoding mapping and to find the target public key data corresponding to the leaked private key, batch query tasks are constructed. The globally unique normalized encoding (as described above) is mapped to the target public key data.<SN, Normalized_Issuer> The data is sent to a distributed CT data index cluster for matching, thereby obtaining the subject public key information (SPKI) of the certificate that matches the information in the CT log information database, and obtaining the target public key data corresponding to the leaked private key.

[0058] The CT data index cluster is a pre-built CT log data indexing system that supports structured queries. When ingesting each certificate from the CT logs, this indexing system synchronously executes the same issuer name normalization process as in S203 of this embodiment, and establishes a joint index with metadata such as the revoked certificate sequence number, principal public key information, and validity period. When this system uses globally unique normalized encoding (as described above)...<SN, Normalized_Issuer> When submitted as a query key to the CT data index cluster, it can ensure precise alignment with the normalized fields in the index. Furthermore, since the certificate serial numbers issued under the same CA will not be duplicated, the globally unique normalized encoding can uniquely locate the complete record of the revoked certificate among a massive number of certificates and extract its main public key information field as the target public key data.

[0059] S205. Aggregate the public key data of each target to construct a database of damaged keys; The public key data of each target is aggregated, and a verification link pointing to the CT data index cluster or CT log search engine (such as crt.sh) is automatically generated for each record. A deep fingerprint database containing the valid expiration date and key algorithm is generated, resulting in a compromised key database.

[0060] Based on the content of S204 and S205 in this embodiment, this embodiment uses a self-developed distributed query scheduling algorithm to map a massive number of sequence numbers whose revocation was due to private key leakage to the complete CT log set. Even without a native public key library, the transparency of the CT log can be utilized to retrieve matching certificate records in the CT log index using globally unique normalized encoding as the query condition. This allows for the acquisition of the complete public key content and its metadata (algorithm, length, validity period, etc.) corresponding to the certificates revoked due to private key leakage, thus constructing a usable structured database of compromised keys.

[0061] In a preferred embodiment, after constructing the initial damaged key database, this embodiment further includes periodically updating the damaged key database. Specifically, this includes: periodically acquiring multiple newly issued CRL response bodies from CAs within a preset risk control range; calculating the current hash value of the newly issued CRL response bodies; determining whether new information exists in the newly issued CRL response bodies based on changes in the current hash value; if so, parsing and acquiring the newly issued CRL response bodies; filtering out newly issued revocation certificate serial numbers whose revocation reason is private key leakage; searching for the target public key data corresponding to the newly leaked private key in the CT log information database based on the newly issued revocation certificate serial number and the corresponding CRL issuer name; and updating the damaged key database based on the newly issued target public key data. The query method used when searching for the target public key data corresponding to the newly leaked private key in the CT log information database based on the newly issued revocation certificate serial number and the corresponding CRL issuer name is basically the same as the method in S203 and S204 of this embodiment, and therefore will not be described again here.

[0062] In this process, each time the system checks for new information in a newly acquired CRL response based on changes in the current hash value, it calculates the current hash value of the latest acquired CRL response and the historical hash value of a previously acquired CRL response from the same CA. The current and historical hash values ​​are compared to determine if there is any new revocation certificate information (such as a revocation certificate sequence number). If the hash values ​​match, there is no new revocation certificate information, and the damaged key database does not need to be updated; therefore, the parsing step for the new CRL response is skipped. If the hash values ​​do not match, it is assumed that there is new revocation certificate information, triggering the ASN.1 parsing logic and updating the damaged key database. This scheme reduces the wasteful data consumption caused by periodically downloading CRL response bodies when there is no new data, and while maintaining minute-level detection sensitivity, it reduces network bandwidth consumption and IO (in-out) load by 90%.

[0063] S206. When any CA receives a certificate request, it obtains the user's public key contained in the certificate request. S207. Calculate the public key fingerprint using the user's public key; In this embodiment, when implementing specific risk prevention and control, a two-layer interception algorithm consisting of a Bloom filter and a local vector library is also included. Before the CA issues a certificate, when a user (or terminal device, etc.) applies for a certificate from the CA, they submit a Certificate Signing Request (CSR) to the CA. This CSR contains the user's principal public key information, identity information, and signature information. After receiving the CSR from the user, the server first intercepts the request and obtains the principal public key information contained in the CSR to obtain the current user's public key; after obtaining the user's public key, it calculates the SHA256 fingerprint as the user's public key fingerprint.

[0064] S208. Use a Bloom filter to perform a preliminary screening of the public key fingerprint to determine whether it is suspected of being leaked. The initial screening accuracy requirement is obtained in advance, and a Bloom filter is constructed and configured based on this requirement. The parameters of the Bloom filter are mathematically optimized based on the estimated maximum blacklist capacity and the target false alarm rate. In a specific example, the initial screening accuracy requirement is determined by the target false alarm rate. Configure settings, such as setting a target false alarm rate. .

[0065] Using the public key fingerprint as the query keyword, a Bloom filter is called to perform a hash operation on the public key fingerprint to obtain several position indices. The Bloom filter's internal array is then checked to see if all these positions are 1. If any position corresponding to each position index is 0, then this user's public key is definitely not in the compromised key database, and no further checks are performed. If all positions corresponding to each position index are 1, then it is determined that the public key may be in the compromised key database, meaning that the private key corresponding to the public key is suspected of being leaked.

[0066] The initial screening step described in this section can shorten the time required for accurate queries of keys that are not damaged, and the comparison process of the entire initial screening step has an impact of less than 50 microseconds on the issuance delay, thus reducing time consumption and data resources overall.

[0067] S209. If a leak is suspected, then use the precise query method to check whether the user's public key is in the compromised key database.

[0068] In one specific implementation, since the Bloom filter in S208 may produce false positives, this embodiment also performs a precise screening step based on a local vector library. A subset of the compromised key database is created in advance, containing the public key fingerprints required for interception, and configured as a local vector library.

[0069] When the Bloom filter determines that a leak is suspected, the second layer of the two-layer interception algorithm, the local vector library query mechanism, is activated. By using exact matching, the public key fingerprint is treated as a high-dimensional binary vector, and an exact search is performed in the compromised key database or the local vector library (such as using key-value lookup, hash table lookup, or binary search, etc.) to determine whether the user's public key is in the compromised key database, thereby determining whether the user's certificate application behavior involves risks.

[0070] This invention addresses inconsistencies in field order, whitespace, and encoding formats across different data sources by introducing a semantic normalization alignment algorithm for X.509 issuer names. This establishes a de facto standard for public key intelligence exchange, resolves cross-domain matching failures, and significantly improves the accuracy and reliability of public key intelligence association. Furthermore, it constructs a compromised private key intelligence aggregation mechanism covering trusted CAs across the entire industry. This mechanism no longer relies on a single CA's internal blacklist and achieves instant identification and interception of compromised private keys across the industry through automation. It enables real-time risk assessment of public keys in application requests before certificate issuance. Compared to traditional mechanisms, this embodiment moves the risk control node forward to the CA issuance process entry point, eliminating potential attack windows caused by private key leaks and enhancing overall security.

[0071] The above describes the cross-CA certificate issuance risk prevention and control method based on damaged key intelligence aggregation in the embodiments of the present invention. The following describes the cross-CA certificate issuance risk prevention and control system based on damaged key intelligence aggregation in the embodiments of the present invention. (See reference...) Figure 3 and Figure 4 An embodiment of the cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation in this invention is as follows: The cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation includes an intelligence aggregation module 301 and a risk prevention and control module 302, wherein: In another embodiment of this application, the intelligence aggregation module 301 includes: The revocation information acquisition unit 3011 is used to acquire multiple CRL response bodies issued by CAs within a preset risk control range, and to filter out the revocation certificate serial number whose revocation reason is private key leakage from each of the CRL response bodies. The normalization coding unit 3012 is used to generate a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name, wherein the coding rule of the globally unique normalized code is the same as the coding rule in the preset CT log information database. Database construction unit 3013 is used to search for the principal public key information corresponding to the revoked certificate in the CT log information database according to the globally unique normalized encoding, and obtain target public key data corresponding to multiple leaked private keys; aggregate the target public key data to construct a damaged key database. Risk control module 302 includes: The request receiving unit 3021 is used to obtain the user public key contained in the certificate application request when any CA receives a certificate application request; The risk assessment unit 3022 is used to determine whether the user's public key is in the damaged key database. If it is in the damaged key database, it is considered that there is a risk of issuance and the certificate issuance process with the risk of issuance is blocked.

[0072] The system provided in this embodiment of the invention can overcome the intelligence barriers between multiple CAs, detect the public keys of certificates revoked by different CAs due to private key leakage, locate certificate issuance risks based on the public keys, and carry out risk prevention and control.

[0073] Continue reading Figure 4 In another embodiment of this application, the intelligence aggregation module 301 includes: In another embodiment of this application, the intelligence aggregation module 301 further includes a range acquisition unit 3014; The range acquisition unit 3014 is also used to acquire all trusted CAs recorded in the public CA database; Select target CAs that can issue HTTPS certificates from trusted CAs to obtain CAs within the preset risk control range.

[0074] In another embodiment of this application, the normalization coding unit 3012 is further configured to: The string of the CRL issuer name is segmented, denoised, and numerically normalized to obtain the normalized CRL issuer name string; Rearrange the items in the normalized CRL issuer name string according to the alphabetical order of the attribute keys; The revocation certificate serial number and the normalized CRL issuer name string are concatenated using a fixed delimiter to generate a globally unique normalized code.

[0075] In another embodiment of this application, the normalization coding unit 3012 is further configured to: The string of the CRL issuer name is segmented using comma delimiters; Remove whitespace characters at both ends of the string and redundant spaces inside the string attribute values ​​to achieve noise reduction; The attribute keys contained in the string are converted to uppercase, and the attribute values ​​in the string are converted to lowercase to achieve numerical normalization.

[0076] In another embodiment of this application, the intelligence aggregation module 301 further includes an intelligence update unit 3015, used for: Periodically obtain multiple new CRL response bodies issued by CA within a preset risk control range, calculate the current hash value of the new CRL response bodies, and determine whether there is new information in the new CRL response bodies based on the changes in the current hash value. If it exists, parse and obtain the newly added CRL response body, and filter out the newly added revocation certificate serial number whose revocation reason is private key leakage; Based on the newly added revocation certificate serial number, search the CT log information database for the target public key data corresponding to the newly added leaked private key; The compromised key database is updated based on the newly added target public key data.

[0077] In another embodiment of this application, the risk assessment unit 3022 is further configured to: Calculate the public key fingerprint using the user's public key; A Bloom filter is used to initially screen the public key fingerprint to determine whether it is suspected of being leaked. If a leak is suspected, a more precise query method is then used to check whether the user's public key is in the compromised key database.

[0078] This invention, by introducing a semantic normalization alignment algorithm, resolves inconsistencies in field order, whitespace characters, and encoding formats across different data sources. It establishes a de facto standard for public key intelligence exchange, solves cross-domain matching failures, and significantly improves the accuracy and reliability of public key intelligence association. A compromised private key intelligence aggregation mechanism covering trusted CAs across the entire industry is constructed, no longer relying on a single CA's internal blacklist. Through automation, it achieves instant identification and interception of compromised private keys across the entire industry, enabling real-time risk assessment of public keys in application requests before certificate issuance. Compared to traditional mechanisms, this embodiment moves the risk control node forward to the CA issuance process entry point, eliminating potential attack windows caused by private key leaks and improving overall security.

[0079] Based on the same inventive concept, this specification also provides an electronic device for cross-CA certificate issuance risk prevention and control based on compromised key intelligence aggregation. The electronic device for cross-CA certificate issuance risk prevention and control based on compromised key intelligence aggregation in this embodiment of the invention will be described in detail below from the perspective of hardware processing.

[0080] Figure 5 This is a schematic diagram of an electronic device provided as an embodiment of this specification. Refer to the following... Figure 5 To describe the electronic device 500 according to this embodiment of the invention. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0081] like Figure 5 As shown, the electronic device 500 is presented in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including storage unit 520 and processing unit 510), a display unit 540, etc.

[0082] The storage unit stores program code that can be executed by the processing unit 510, causing the processing unit 510 to perform the steps described in the processing method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 510 can perform, for example... Figure 1 The steps are shown.

[0083] The storage unit 520 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 5201 and / or a cache storage unit 5202, and may further include a read-only memory unit (ROM) 5203.

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

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

[0086] Electronic device 500 can also communicate with one or more external devices 100 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 550. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 560. Network adapter 560 can communicate with other modules of electronic device 500 via bus 530. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0087] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described in this invention can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this invention can be embodied in the form of a software product, which can be stored in a computer-readable storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the method described above according to this invention. When the computer program is executed by a data processing device, it enables the computer-readable medium to implement the method described above, i.e.: as... Figure 1 or Figure 2 The method shown.

[0088] Figure 6 This is a schematic diagram of a computer-readable medium provided for embodiments of this specification.

[0089] accomplish Figure 1 or Figure 2The computer program of the method shown can be stored on one or more computer-readable media. A computer-readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

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

[0091] In addition, the present invention also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation as described in any of the above embodiments.

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

[0093] In summary, the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that in practice, general-purpose data processing devices such as microprocessors or digital signal processors (DSPs) can be used to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0094] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the present invention is not inherently related to any specific computer, virtual device, or electronic device, and various general-purpose devices can also implement the present invention. The above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0095] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0096] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0097] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for preventing and controlling risks in cross-CA certificate issuance based on compromised key intelligence aggregation, characterized in that, include: Obtain multiple CRL response bodies issued by CAs within a preset risk control range, and filter out the revocation certificate serial numbers whose revocation reason is private key leakage from each CRL response body; A globally unique normalized code is generated based on the revocation certificate serial number and the corresponding CRL issuer name, wherein the encoding rules of the globally unique normalized code are the same as those in the preset CT log information database; Based on the globally unique normalized encoding, the CT log information database is searched to find the principal public key information corresponding to the revoked certificate, and the target public key data corresponding to multiple leaked private keys is obtained. The target public key data of each target are aggregated to construct a database of compromised keys. When any CA receives a certificate request, it obtains the user's public key contained in the certificate request. Determine whether the user's public key is in the compromised key database. If it is, then there is a risk of issuance, and the certificate issuance process with the risk of issuance is blocked.

2. The method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation according to claim 1, characterized in that, Before obtaining the multiple CRL response bodies issued by the CA within the preset risk control range, the method further includes: Retrieve all trusted CAs recorded in the public CA database; Select target CAs that can issue HTTPS certificates from trusted CAs to obtain CAs within the preset risk control range.

3. The method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation according to claim 1, characterized in that, The step of generating a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name includes: The string of the CRL issuer name is segmented, denoised, and numerically normalized to obtain the normalized CRL issuer name string; Rearrange the items in the normalized CRL issuer name string according to the alphabetical order of the attribute keys; The revocation certificate serial number and the normalized CRL issuer name string are concatenated using a fixed delimiter to generate a globally unique normalized code.

4. The method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation according to claim 3, characterized in that, The process of segmenting, denoising, and normalizing the string of the CRL issuer name includes: The string of the CRL issuer name is segmented using comma delimiters; Remove whitespace characters at both ends of the string and redundant spaces inside the string attribute values ​​to achieve noise reduction; The attribute keys contained in the string are converted to uppercase, and the attribute values ​​in the string are converted to lowercase to achieve numerical normalization.

5. The method for cross-CA certificate issuance risk prevention and control based on compromised key intelligence aggregation according to claim 1, characterized in that, Following the construction of the compromised key database, the following is also included: Periodically obtain multiple new CRL response bodies issued by CA within a preset risk control range, calculate the current hash value of the new CRL response bodies, and determine whether there is new information in the new CRL response bodies based on the changes in the current hash value. If it exists, parse and obtain the newly added CRL response body, and filter out the newly added revocation certificate serial number whose revocation reason is private key leakage; Based on the newly added revocation certificate serial number, search the CT log information database for the target public key data corresponding to the newly added leaked private key; The compromised key database is updated based on the newly added target public key data.

6. The method for preventing and controlling cross-CA certificate issuance risks based on compromised key intelligence aggregation according to claim 1, characterized in that, The step of determining whether the user's public key is in the compromised key database includes: Calculate the public key fingerprint using the user's public key; A Bloom filter is used to initially screen the public key fingerprint to determine whether it is suspected of being leaked. If a leak is suspected, a more precise query method is then used to check whether the user's public key is in the compromised key database.

7. A cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation, characterized in that, The cross-CA certificate issuance risk prevention and control system based on compromised key intelligence aggregation includes: The intelligence aggregation module is used to acquire multiple CRL response bodies issued by CAs within a preset risk control range, and filter out revocation certificate serial numbers whose revocation reason is private key leakage from each CRL response body; generate a globally unique normalized code based on the revocation certificate serial number and the corresponding CRL issuer name, wherein the encoding rules of the globally unique normalized code are the same as those in the preset CT log information database; search for the subject public key information corresponding to the revocation certificate in the CT log information database based on the globally unique normalized code to obtain target public key data corresponding to multiple leaked private keys; aggregate the target public key data to construct a compromised key database; The risk control module is used to obtain the user's public key contained in the certificate application request when any CA receives a certificate application request; determine whether the user's public key is in the damaged key database; if it is in the damaged key database, it is considered that there is a certificate issuance risk, and the certificate issuance process with the certificate issuance risk is blocked.

8. A cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation, characterized in that, The cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the cross-CA certificate issuance risk prevention and control device based on compromised key intelligence aggregation to perform the steps of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program / instructions thereon, characterized in that, When the program / instruction is executed by the processor, it implements the steps of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation as described in any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the cross-CA certificate issuance risk prevention and control method based on compromised key intelligence aggregation as described in any one of claims 1-6.

Images