Method for protecting identity privacy in PKI certificate transparent service

Abstract

This invention discloses a method for protecting identity privacy in a PKI certificate transparency service, relating to the field of information security. The method includes: a service provider generating a trapdoor based on the domain name information of the domain name owner and sending it to the domain name owner; the domain name owner verifying the correctness of the trapdoor generated by the service provider based on the domain name information; if correct, the domain name owner sending an edit certificate generation request to a certificate authority; the certificate authority generating an edit certificate based on the domain name information and submitting it to a log server; the log server generating a signature certificate timestamp for the edit certificate and sending it to the certificate authority; the certificate authority sending the signature certificate timestamp and the edit certificate to the domain name owner; and a monitor retrieving the edit certificate related to the domain name owner from the log server, assisting the domain name owner who has access to the trapdoor in auditing the retrieved edit certificate. This invention enhances domain name privacy while ensuring the effectiveness of the certificate transparency service.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method for protecting identity privacy in a PKI certificate transparency service. Background Technology

[0002] Public Key Infrastructure (PKI) is a security infrastructure service based on public-key cryptography algorithms. Certificate-based PKI systems provide authentication, encrypted transmission, and data integrity verification services for secure communication between any entities on the internet. In a PKI system, a Certificate Authority (CA) acts as a trust anchor, responsible for issuing digital certificates (or simply certificates) to network entities, binding the entity's identity and public key information. When a client establishes a connection with a website server, it verifies the other party's certificate through a pre-set CA certificate trust list to complete identity verification, thereby completing steps such as key negotiation and encrypted transmission. Therefore, in a PKI system, it is typically assumed that the CA is completely trustworthy, and on this basis, trust is established and transmitted between different entities on the network based on certificates issued by the CA.

[0003] However, recent security incidents have shown that Certificate Authorities (CAs) may issue counterfeit certificates due to misconduct or attacks. Attackers use counterfeit certificates to bind public keys to identities that do not belong to them, enabling man-in-the-middle or impersonation attacks. Traditional PKI systems lack the ability to monitor CAs and detect counterfeit certificates; even with rigorous certificate checks and verifications, clients often fail to identify them. The emergence of counterfeit certificates significantly undermines the trust provided by PKI systems.

[0004] To address the aforementioned issues, the Certificate Transparency (CT) solution was proposed to promptly detect fraudulent certificates and enhance the accountability of Certificate Authorities (CAs). Compared to traditional PKI systems, CT introduces a log server that can only be added to and cannot be tampered with. This log server publicly records every certificate issued by a CA and generates a Signed Certificate Timestamp (SCT) for each certificate, promising to publish it to the log server within a specified timeframe. This allows browsers joining the CT ecosystem to verify whether the certificate has been publicly recorded in the log and is auditable. Furthermore, CT introduces a core component called a monitor, allowing any entity to retrieve and monitor the certificate information recorded in the log, thereby identifying suspicious certificates. Any domain owner or public third party can act as a monitor to provide certificate retrieval or monitoring services.

[0005] Introducing the CT mechanism into the PKI system can effectively solve the problems caused by fake certificates, but it also inevitably introduces some privacy leakage issues. On the one hand, the domain information in the certificate may leak the company's internal network structure, cooperative relationships, and unreleased product information. For example, in October 2017, a certificate for "dst.tv" containing the subdomain "samsungtv" applied for by Company A was logged in the log server, and the related application was not launched on Company A's equipment until eight months later. On the other hand, some service providers, such as cloud hosting service providers, website building service providers, and homomorphic DNS providers, need to apply for independent private subdomain certificates for their users. These users build their own private service platforms through such service providers for personal or internal organizational use. The certificates applied for by the providers for these subdomains may contain sensitive information such as the user's private domain, related numbers, and email addresses, and the logging of these certificates to the log server will directly lead to the leakage of user privacy. For example, there is a blog service provider with the domain name blog.com, and the user's personal homepage domain name is secret.blog.com, where the secret field contains sensitive information that needs to be encrypted.

[0006] To address the aforementioned privacy concerns, existing CT enhancement technologies primarily employ a method of encrypting or hashing the domain information in the certificate to conceal certain parts. Such certificates are typically referred to as "editable certificates." Existing privacy protection solutions based on editable certificates can be categorized into two types.

[0007] One type of scheme replaces the domain information to be hidden in the certificate with its transformed result by performing a repeatable one-way transformation on the domain name (e.g., a hash function operation). For example, Hash(secret).example.com is used instead of secret.example.com, where Hash(secret) represents the hash value of secret. Entities possessing the domain information can determine the certificate associated with the domain they are looking for by comparing it with the set of edit certificates retrieved from the log server after performing the same one-way transformation. This type of scheme retains the transparency introduced by the CT scheme, i.e., the domain owner can audit and monitor all certificates associated with their domain through the CT log server. However, because domain names usually have deterministic semantics, and the input of the one-way transformation typically does not contain any other secret information besides the domain name, this scheme is vulnerable to dictionary attacks and rainbow table attacks.

[0008] Another type of scheme directly replaces the privacy information in the domain name with an identifier that contains no information (such as a "?" or "*" symbol), or introduces secret information in a one-way transformation. For example, replacing secret.example.com with ?.example.com or COMMIT(secret, r).example.com, where COMMIT(secret, r) represents a cryptographic commitment to the secret. This makes it impossible for even a known domain name to determine its binding relationship with the certificate. Therefore, this type of scheme can resist dictionary attacks, but it also loses some transparency. That is, the domain owner cannot accurately identify all the certificates related to their domain recorded in the logs, which contradicts the original design goal of CT. This type of scheme is suitable for scenarios where the domain owner is an organization, and the hidden information is from its subsidiaries. For example, the example of Company A mentioned above. However, when the information to be hidden is the identity information of an independent entity, such as the blog system mentioned above, this scheme is no longer applicable.

[0009] In conclusion, existing privacy enhancement solutions fail to effectively balance the needs for domain name privacy and certificate transparency. Summary of the Invention

[0010] The purpose of this invention is to provide a method for protecting identity privacy in PKI certificate transparency services, which improves domain name privacy while enhancing the effectiveness of existing PKI certificate transparency services.

[0011] To achieve the above objectives, the present invention provides the following solution:

[0012] A method for protecting identity privacy in a PKI certificate transparency service includes:

[0013] The service provider generates a trapdoor based on the domain name information of the domain name owner and sends it to the domain name owner;

[0014] The domain owner verifies the correctness of the trapdoor generated by the service provider based on the domain information; if the domain owner verifies that the trapdoor is correct, the domain owner sends an edit certificate generation request to the certificate authority.

[0015] After receiving the edit certificate generation request sent by the domain owner, the certificate authority generates an edit domain based on the domain owner's domain information, generates an edit certificate based on the edit domain, and sends the edit certificate to the log server.

[0016] The log server generates a signature certificate timestamp for the edit certificate and sends the signature certificate timestamp to the certificate authority.

[0017] The certificate authority sends the signature certificate timestamp and the edit certificate to the domain owner;

[0018] Once the domain owner verifies that the timestamp of the signing certificate matches the edit certificate, a domain binding commitment is generated for the edit certificate, and the TLS client initiates a connection request for the domain to the domain owner; the domain binding commitment is generated based on the domain information.

[0019] After receiving the connection request, the domain owner sends the domain binding commitment, the signing certificate timestamp, and the edit certificate to the TLS client;

[0020] The TLS client verifies whether the edit certificate and the domain name corresponding to the connection request match based on the received domain name binding commitment, the signing certificate timestamp, and the edit certificate. If they match, the TLS client continues to communicate with the domain name owner; otherwise, the TLS client terminates the connection with the domain name owner.

[0021] The monitor retrieves edit certificates related to the domain name of the domain owner from the log server and assists the domain owner in auditing the retrieved edit certificates; the edit certificates related to the domain name of the domain owner belong to the same parent domain.

[0022] Optionally, the monitor retrieves edit certificates related to the domain name of the domain owner from the log server and assists the domain owner in auditing the retrieved edit certificates, specifically including:

[0023] When the monitor is the domain owner, the domain owner retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider;

[0024] The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor;

[0025] The domain owner audits the retrieved editing certificates.

[0026] Optionally, the monitor retrieves edit certificates related to the domain name of the domain owner from the log server and assists the domain owner in auditing the retrieved edit certificates, specifically including:

[0027] When the monitor is a public third-party monitor that has not been authorized by the domain owner, the domain owner sends the parent domain provided by the service provider to the monitor;

[0028] The monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider, and sends the retrieved subdomain edit certificate back to the domain owner;

[0029] The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor;

[0030] The domain owner audits the retrieved editing certificates.

[0031] Optionally, the monitor retrieves edit certificates related to the domain name of the domain owner from the log server and assists the domain owner in auditing the retrieved edit certificates, specifically including:

[0032] When the monitor is a public third-party monitor authorized by the domain owner, the domain owner sends the parent domain provided by the service provider and the domain owner's trapdoor to the monitor;

[0033] The monitor retrieves the subdomain editing certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider;

[0034] The monitor retrieves the edit certificate bound to the domain name of the domain owner from the subdomain edit certificate according to the trapdoor, and sends the retrieved edit certificate back to the domain owner;

[0035] The domain owner audits the retrieved editing certificates.

[0036] Optionally, the monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider, specifically including:

[0037] The monitor retrieves, according to a set period, the subdomain edit certificates corresponding to the parent domain name newly added within the current set period from the log server based on the parent domain name provided by the service provider.

[0038] Optionally, the service provider generates a trapdoor based on the domain name information of the domain name owner and sends it to the domain name owner, specifically including:

[0039] The service provider uses Trapdoor = H1(id) α Generate a trapdoor, where Trapdoor represents the trapdoor, id represents the domain name information, H1() represents the first hash function, and α represents the private key of the service provider.

[0040] Optionally, the domain owner verifies the correctness of the trapdoor generated by the service provider based on the domain name information, specifically including:

[0041] The domain owner verification equation If the statement is valid, then the domain owner verification trap is correct.

[0042] Where H1() represents the first hash function, H2() represents the second hash function, Trapdoor represents the trapdoor, and id represents the domain name information, which is defined as... The bilinear mapping, where and Both are q-order groups, and g is a group. The generator, h = g α , Let represent the set of all elements in the remainder class modulo q that are relatively prime to q, where q is a large prime number.

[0043] Optionally, after receiving the edit certificate generation request sent by the domain owner, the certificate authority generates an edit domain name based on the domain owner's domain name information, generates an edit certificate based on the edit domain name, and sends the edit certificate to the log server, specifically including:

[0044] The domain owner sends a certificate generation edit request to the certificate authority, and simultaneously sends the domain information and a random number to the certificate authority; wherein the random number is a currently generated random number;

[0045] After receiving the edit certificate generation request, the certificate authority verifies whether the domain name information is valid. If valid, it generates an edit domain name based on the random number and the domain name information.

[0046] The certificate authority generates an editing certificate based on the edited domain name and sends the editing certificate to the log server.

[0047] Optionally, the formula for generating the edited domain name is expressed as:

[0048]

[0049] Where R(id) represents the edited domain name, R1 represents the first intermediate parameter, R2 represents the second intermediate parameter, r represents a random number, id represents the domain name information, H1() represents the first hash function, and H2() represents the second hash function. It is defined as bilinear mapping, and Both are q-order groups, and g is a group. The generator, h = g α , Let represent the set of all elements in the remainder class modulo q that are relatively prime to q, where q is a large prime number.

[0050] Optionally, the TLS client verifies whether the edited certificate and the domain name corresponding to the connection request match based on the received domain name binding commitment, the signing certificate timestamp, and the edited certificate. If they match, the TLS client continues to communicate with the domain name owner; otherwise, the TLS client terminates the connection with the domain name owner. Specifically, this includes:

[0051] Verify the equation With Equation Whether both conditions are met simultaneously: if both conditions are met, then the domain name corresponding to the edit certificate and the connection request matches; if not both conditions are met, then the domain name corresponding to the edit certificate and the connection request does not match.

[0052] Where H1() represents the first hash function, H2() represents the second hash function, Aux represents the domain name binding commitment, id represents the domain name information, R1 represents the first intermediate parameter, and R2 represents the second intermediate parameter. It is defined as bilinear mapping, and Both are q-order groups, and g is a group. The generator, h = g α , Let q represent the set of all elements in the residue class modulo q that are relatively prime to q, where q is a large prime number.

[0053] Aux = H1(id) r , where r represents a random number.

[0054] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0055] This invention is based on public-key searchable encryption technology. It enables the domain name in the certificate to be searched through a trapdoor in the encrypted state. The domain name owner can hold the trapdoor and authorize it by sharing the trapdoor information with a trusted entity. Thus, the encrypted domain name is only searchable by the entity holding the trapdoor. This improves the privacy of the domain name and enhances the effectiveness of the existing PKI certificate transparency service. Attached Figure Description

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

[0057] Figure 1 This is a schematic diagram of a method for protecting identity privacy in a PKI certificate transparency service provided by an embodiment of the present invention;

[0058] Figure 2 A relationship diagram of information interaction between the parties provided in an embodiment of the present invention;

[0059] Figure 3 This is a schematic diagram illustrating the interaction details of the trapdoor generation stage provided in an embodiment of the present invention;

[0060] Figure 4 This is a schematic diagram illustrating the interactive details of the certificate generation stage provided in an embodiment of the present invention;

[0061] Figure 5 A schematic diagram illustrating the interaction details of the certificate verification stage provided in an embodiment of the present invention;

[0062] Figure 6 A schematic diagram illustrating the interaction details of the certificate monitoring / retrieval phase (strong privacy) provided in an embodiment of the present invention;

[0063] Figure 7 A schematic diagram illustrating the interaction details of the certificate monitoring / retrieval phase (weak privacy) provided in an embodiment of the present invention;

[0064] Figure 8 This is a schematic diagram of the structure of the editing certificate provided in an embodiment of the present invention. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0066] The purpose of this invention is to provide a method for protecting identity privacy in PKI certificate transparency services, which improves domain name privacy while enhancing the effectiveness of existing PKI certificate transparency services.

[0067] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0068] This invention provides a method for protecting identity privacy in a PKI certificate transparency service, enabling identity privacy protection services within the CT ecosystem. While protecting certificate domain privacy, this invention ensures that certificates can be transparently audited within the CT system. Specifically, entities possessing relevant trapdoor information (e.g., domain owners (DOs) and related authorized entities) can efficiently and accurately retrieve the relevant certificates bound to their domains from the CT log server, while these certificates remain completely unrecognizable to other entities.

[0069] This invention first encrypts the domain name of the certificate to achieve privacy protection. The encrypted domain name is identifiable / searchable by specific entities (e.g., the domain owner, and entities authorized by the domain owner). Specifically, this invention is designed based on public-key searchable encryption technology, enabling the domain name in the certificate to be searchable through a trapdoor in its encrypted state. Ideally, only the DO (Document Authorization Entity) can hold the trapdoor and authorize it by sharing the trapdoor information with trusted entities, thus ensuring that the encrypted domain name is searchable only by the entity holding the trapdoor. Therefore, this invention fully considers the privacy of the trapdoor, ensuring that the DO does not need to provide trapdoor privacy during the certificate generation, verification, and search stages.

[0070] This invention involves five participants: DO (Dominator), Server Provider (SP), Certificate Authority (CA), Transport Layer Security (TLS) client, and CT Monitor. The DO is the entity that needs to hide its private domain information. This entity accepts relevant network services provided by the SP (e.g., a cloud service provider), applies for a certificate from the CA to prove its identity to the TLS client, and further uses the CT Monitor to help discover suspicious certificates related to its domain. Information exchange between the parties is as follows... Figure 2 As shown.

[0071] To further illustrate the security nature of the technical solution in this invention, the following security assumptions are first given: (1) The DO and TLS client are trusted; the DO strictly monitors and checks for fake certificates, and the TLS client strictly performs certificate verification; (2) The SP and CA are malicious or under attack, attempting to impersonate the DO, but will not actively disclose the DO's privacy; (3) To achieve more granular operation, the following two security assumptions are made for the CT Monitor. One assumption is that the Monitor is semi-honest, strictly performing the certificate monitoring and retrieval protocol, but attempting to obtain the DO's privacy information; the other assumption is that the Monitor is honest, strictly performing the protocol and not actively collecting the DO's privacy information. Based on the two different assumptions about the Monitor, the solution of this invention can achieve different degrees of privacy, which are distinguished as "strong privacy" and "weak privacy".

[0072] Domain name privacy protection is a primary security objective of this invention. Therefore, the scope of privacy protection is defined as follows: DO entities register with SPs and receive services from them. The DO's identity information is known to the SP; therefore, there is no need to consider protecting the DO's privacy against the SP. In this invention, the SP generates a trapdoor for the DO, which does not result in any additional privacy leaks.

[0073] In addition to TLS certificate scenarios, this invention can also be applied to other PKI application scenarios (e.g., electronic authentication, email certificates, code signing, etc.) where certificates contain private information and there is a need for transparent auditing, so as to achieve transparent auditing while ensuring that the privacy information of the certificate is not leaked.

[0074] The technical solution of this invention includes the following five stages:

[0075] The first phase is the initialization phase. The SP generates searchable, encrypted parameters based on a bilinear mapping. The private key is the SP's private parameter, while the remaining parameters are public parameters. The operations in the next four phases are all based on these parameters. Simultaneously, when the SP requests a certificate, it requests the CA to embed the public parameters into its certificate in X.509 extended form. This type of certificate is called a "parameter certificate," and all participating parties use it to securely and reliably transmit the public parameters. Subsequently, the SP or the CA that issued the parameter certificate for the SP submits the parameter certificate to the log server.

[0076] The second stage is the trapdoor generation stage. The DO sends a trapdoor generation request to the SP. The SP generates the trapdoor using its private key based on the domain information that the DO wants to hide. The DO can verify the correctness of the generated trapdoor according to the public parameters, ensuring that the SP does not provide an incorrect trapdoor that would prevent the DO from searching for the associated certificate. After successful verification, the DO proceeds to the next steps.

[0077] The third stage is the certificate generation stage. The DO sends the domain name, a random number, and parameter certificates to the CA to initiate a certificate request. After verifying the DO's identity and the validity of the parameter certificates (including signature, validity period, SCT, etc.), the CA encrypts the privacy-protected portion of the domain name based on the provided random number and public parameters, generating an edit certificate. The CA then submits the edit certificate to the log server and, upon receiving the feedback SCT, sends it along with the certificate in either an embedded or non-embedded form to the DO. Since the random number and public parameters are known to the DO, the DO can repeat the CA's domain name editing process to verify the correctness of the edit certificate, ensuring that the edit certificate strictly adheres to the protocol generation. After successful verification, the DO proceeds to subsequent steps.

[0078] The fourth stage is the certificate verification stage. When the DO establishes a communication link with the TLS client, the DO sends the edit certificate and parameter certificate to the client to prove its identity. The TLS client needs to verify the binding relationship between the edit certificate and the DO's domain name, as well as the searchability of the edit certificate, that is, to identify the actual domain name corresponding to the edit certificate through the corresponding trapdoor. Because the plaintext domain name information is hidden in the certificate, the TLS client cannot directly verify the correctness of the certificate based on the domain name; in addition, considering the privacy of the trapdoor, the TLS client cannot be required to verify the searchability of the certificate by obtaining the trapdoor. Therefore, this invention designs a "verification domain name binding commitment" sent by the DO to the TLS client. The domain name binding commitment is generated by the DO using the random number it sends to the CA and its own private domain name. This verification domain name binding commitment can prove the binding relationship between the edit certificate and the domain name, and that the DO of the edit certificate to the domain name is searchable, without disclosing any information about the trapdoor. Entities that do not have the domain name information cannot obtain any information related to the domain name binding relationship based solely on the domain name binding commitment.

[0079] The fifth stage is the certificate monitoring / retrieval stage, where the Domain Controller (DO) uses its trapdoor to search the logs for certificates bound to its domain. When a third-party monitor exists, the DO can delegate the certificate search task to it. Depending on the level of trust placed in the third-party monitor, the delegation can be differentiated as follows: If the DO does not trust the third-party monitor, it only provides the Service Provider (SP) information to the monitor; that is, the DO has not authorized the monitor. The monitor only retrieves the edit certificate of the subdomain corresponding to the parent domain from the log server and sends the retrieved subdomain edit certificate back to the domain owner. The domain owner then uses the trapdoor to retrieve the edit certificate bound to its domain from the subdomain edit certificates. If the DO fully trusts the third-party monitor, it can also delegate the trapdoor to the third-party monitor; that is, the DO authorizes the monitor, and the monitor uses the trapdoor to retrieve the edit certificate bound to the domain owner's domain from the log server. In addition, the third-party monitor has two working modes. In the first working mode, the DO actively initiates a query request to the monitor, and the monitor's search log sends all relevant certificates to the DO. In the second working mode, the DO subscribes to the monitor's service, and the monitor periodically searches the log and only sends the DO relevant certificates that have been added since the previous search result.

[0080] The two cryptographic tools involved in this invention are defined as follows:

[0081] 1) Bilinear mapping: Let and There are two groups of order q (where q is a large prime number), and the bilinear mapping is defined as follows: This mapping contains three properties: (i) Bilinearity: (ii) Non-degeneracy: Will not All point pairs in the map are mapped to The unit element, if g1 and g2 are respectively and The generator, then yes (iii) Computability: for any generator; and Mapping It is computable.

[0082] 2) Hash function:

[0083] This invention utilizes the two cryptographic tools described above to achieve privacy and searchability of the edit certificate.

[0084] The meanings of all the symbolic information involved in this example are as follows:

[0085] id: Represents the identity information that DO wants to hide.

[0086] server.com: This indicates the parent domain information provided by the SP.

[0087] id.server.com: This represents a subdomain of DO.

[0088] Trapdoor: a doorway leading into a hole.

[0089] q: a large prime number.

[0090] q-order group.

[0091] H1(m): The first type of hash function, representing the mapping.

[0092] H2(m): The second type of hash function, representing the mapping.

[0093] Bilinear mapping.

[0094] pk: Public key.

[0095] sk: Private key.

[0096] The set of all elements in the remainder class modulo q that are coprime to q.

[0097] R(id) = [R1, R2]: Edit the domain name, and also serve as the search index for editing certificates.

[0098] Aux: A commitment generated by DO to the binding relationship between the edit certificate and its corresponding domain name.

[0099] This invention discloses a method for protecting identity privacy in a PKI certificate transparency service, which specifically includes the following steps:

[0100] First, the initialization phase.

[0101] The service provider generates private and public parameters.

[0102] The private parameter is the private key of the service provider, and the public parameter includes the cyclic group, generator, and public key.

[0103] Service provider selection parameters: security parameter k, group and Generate the generator g. Generate a public-private key pair (pk, sk), where pk = [g, h = g]. α ], sk=α.

[0104] The certificate authority generates a parameter certificate based on the public parameters and sends the parameter certificate to the service provider and the log server, specifically including:

[0105] The certificate authority embeds the public parameters into the service provider's certificate in the form of an X.509 extension, generates a parameter certificate, and sends the parameter certificate to the service provider and the log server.

[0106] Second, the trapdoor generation stage.

[0107] like Figure 3 As shown, the trapdoor generation stage specifically includes the following steps.

[0108] Step 101: The service provider generates a trapdoor based on the domain name information of the domain name owner and sends it to the domain name owner.

[0109] The domain information is the domain information ID.

[0110] Among them, such as Figure 3 As shown, step 101 specifically includes:

[0111] Step 1011: The domain owner initiates a trapdoor generation request to the service provider and sends the domain information ID to the service provider.

[0112] Step 1012: After receiving the trapdoor generation request, the service provider generates a trapdoor Trapdoor = GenTrap(SK,id) using the private parameter SK and the domain name information id, and sends the parameter certificate and the generated trapdoor to the domain name owner through a secure channel.

[0113] In a specific implementation, the generation of a trapdoor is represented as Trapdoor = H1(id). α .

[0114] Step 102: The domain owner verifies the correctness of the trapdoor generated by the service provider based on the domain information; if the domain owner verifies that the trapdoor is correct, the domain owner sends an edit certificate generation request to the certificate authority.

[0115] Step 102 specifically includes:

[0116] After receiving the parameter certificate, the domain owner first verifies the validity of the parameter certificate (including verifying the SCT, signature, validity period, etc. of the parameter certificate). If the verification is successful, the owner uses the public key pk of the SP extracted from the parameter certificate extension and their own domain information id to verify the correctness of the trapdoor. If VerifyTrap(pk, id, Trapdoor) == True, the verification is successful. If the verification is successful, the subsequent steps are executed; otherwise, the process is stopped.

[0117] Specifically, VerifyTrap(pk, id, Trapdoor) == True means...

[0118] In a specific implementation, step 102 specifically includes: after receiving the parameter certificate, the domain owner first verifies the validity of the parameter certificate (including verifying the SCT, signature, validity period, etc. of the parameter certificate). After successful verification, the public key pk is extracted from the parameter certificate extension, and the equation is verified. If the condition is met, the verification passes, the trapdoor is saved, and the process continues; otherwise, the process is aborted.

[0119] Third, the certificate generation stage.

[0120] Step 103: After receiving the edit certificate generation request sent by the domain owner, the certificate authority generates an edit domain name based on the domain owner's domain name information, generates an edit certificate based on the edit domain name, and sends the edit certificate to the log server.

[0121] Among them, such as Figure 4 As shown, step 103 specifically includes:

[0122] Step 1031: The domain owner sends an edit certificate generation request to the certificate authority, and simultaneously sends the domain information id, random number r, and the parameter certificate to the certificate authority.

[0123] Specifically, step 1031 includes: DO sending an edit certificate generation request to CA, and simultaneously sending DO's domain name information and random number r to CA through a secure channel, while also sending parameter certificate to CA through a normal channel.

[0124] Step 1032: After receiving the edit certificate generation request, the certificate authority verifies whether the domain name information ID and the parameter certificate are valid. If valid, it generates the edit domain name based on the parameter certificate, the random number, and the domain name information ID.

[0125] Specifically, step 1032 includes: after receiving the edit certificate generation request, the certificate authority verifies the identity of the DO and whether the received parameter certificate is valid. If the verification is successful, the corresponding edit domain name R(id) = GenRedactedName(PK,r,id) is generated based on the public key PK, random number r, and DO domain name information id in the parameter certificate extension; otherwise, the program terminates.

[0126] In a specific implementation, step 1032 specifically includes: the CA verifying whether the DO's identity is correct and whether the parameter certificate is valid (i.e., whether the SCT, signature, validity period, and other information are valid). If correct, the subsequent steps continue; otherwise, the process is terminated.

[0127] After the CA verifies the DO's identity and confirms the correctness of the parameter certificate, it generates the editable domain based on the public key PK=[g,h] extracted from the parameter certificate extension, the random number r sent by the DO, and the domain information id that the DO wants to hide.

[0128] Where R(id) represents the edited domain name, R1 represents the first intermediate parameter, R2 represents the second intermediate parameter, r represents a random number, id represents the domain name information, H1() represents the first hash function, and H2() represents the second hash function. It is defined as bilinear mapping, and Both are q-order groups, and g is a group. The generator, h = g α , Let represent the set of all elements in the remainder class modulo q that are relatively prime to q, where q is a large prime number.

[0129] Step 1033: The certificate authority generates an editing certificate based on the edited domain name and sends the editing certificate to the log server.

[0130] Specifically, step 1033 includes: the certificate authority embeds the edit domain name into the edit certificate issued by the CA to generate an edit certificate.

[0131] Edit the certificate format as follows Figure 8 As shown. The edit certificate includes data, version, issuer, validity period, subject, subject public key information, X.509v3 extensions, signature algorithm, and signature value. X.509v3 extensions include the X.509v3 subject optional name, Domain Name System (DNS), edit domain, and other extensions.

[0132] Step 104: The log server generates a signature certificate timestamp for the edit certificate and sends the signature certificate timestamp to the certificate authority.

[0133] Step 105: The certificate authority sends the signature certificate timestamp and the edit certificate to the domain owner.

[0134] Specifically, step 105 includes: the certificate authority sending the signature certificate timestamp and the edit certificate to the domain owner in an embedded or non-embedded form.

[0135] The domain owner verifies the signature certificate timestamp (SCT) and other information to ensure they are correct. The domain owner then repeats the domain name generation process, verifying the signature of the edit certificate and the embedded edit domain name. If correct, proceed to step 106; otherwise, abort.

[0136] Fourth, the certificate verification stage.

[0137] Step 106: After the domain owner verifies that the timestamp of the signing certificate is correct with the editing certificate, a domain binding commitment is generated for the editing certificate, and the TLS client initiates a domain connection request to the domain owner; the domain binding commitment is generated based on the domain information.

[0138] Among them, such as Figure 5 As shown, step 106 specifically includes: the TLS client initiating a secure connection request to the DO server regarding the domain name "id.server.com".

[0139] Step 107: After receiving the connection request, the domain owner sends the domain binding commitment, the signing certificate timestamp, and the edit certificate to the TLS client.

[0140] Once the domain binding commitment is generated, it is stored locally on the domain owner's local machine and can be read directly when needed.

[0141] Specifically, step 107 includes: the domain owner executing Aux = GenAux(r, id) = H1(id). r Generate a domain binding commitment (Aux) and send the edit certificate, SCT, domain binding commitment, and parameter certificate to the TLS client.

[0142] Step 108: The TLS client verifies whether the domain name corresponding to the connection request matches the received domain name binding commitment, the signing certificate timestamp, and the edit certificate. If they match, the TLS client continues to communicate with the domain name owner; otherwise, the TLS client terminates the connection with the domain name owner.

[0143] Step 108 specifically includes: the TLS client verifying the validity of the signature, SCT, and validity period of the parameter certificate and the edit certificate. Then, based on the domain binding commitment Aux, it verifies the correctness and searchability of the edit certificate (VerifyCert(R(id),pk,id,Aux)==True). If correct, it continues to establish a secure connection; otherwise, it aborts.

[0144] Specifically, VerifyCert(R(id),pk,id,Aux)==True is an equation. With Equation Whether they are true at the same time.

[0145] In a specific implementation, step 108 includes: the TLS client first verifies whether the parameter certificate, the SCT of the edit certificate, the signature, and the validity period are correct; if correct, it verifies the equation. With Equation Are both equations true? If both equations are true, it proves that the edit certificate matches the domain name, and the DO for that domain name can definitely find the certificate through the Trapdoor it holds. The TLS client can continue communicating with the DO. If the verification fails, the TLS client terminates the connection.

[0146] Step 109: The monitor retrieves the edit certificate associated with the domain name of the domain owner from the log server and assists the domain owner in auditing the retrieved edit certificate.

[0147] The monitor is responsible for monitoring and retrieving suspicious certificate entities from the log server.

[0148] Step 109 specifically includes three scenarios:

[0149] In the first scenario: when the monitor is the owner of the domain name, the domain name owner retrieves the subdomain edit certificate corresponding to the parent domain name from the log server based on the parent domain name provided by the service provider.

[0150] The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor.

[0151] The domain owner audits the retrieved editing certificates.

[0152] The second scenario: When the monitor is a public third-party monitor that has not been authorized by the domain owner, the domain owner sends the parent domain provided by the service provider to the monitor.

[0153] The monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider, and sends the retrieved subdomain edit certificate back to the domain owner.

[0154] The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor.

[0155] The domain owner audits the retrieved editing certificates.

[0156] The third scenario: When the monitor is a public third-party monitor authorized by the domain owner, the domain owner sends the parent domain provided by the service provider and the domain owner's trapdoor to the monitor.

[0157] The monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider.

[0158] The monitor retrieves the edit certificate bound to the domain name of the domain owner from the subdomain edit certificate according to the trapdoor, and sends the retrieved edit certificate back to the domain owner.

[0159] The domain owner audits the retrieved editing certificates.

[0160] In a specific implementation, in the second and third cases, the domain owner initiates a certificate retrieval request, and the monitor retrieves all subdomain edit certificates corresponding to the parent domain from the log server based on the parent domain provided by the service provider; or the domain owner adopts a subscription mode, that is, the monitor retrieves newly added subdomain edit certificates corresponding to the parent domain within the current set period from the log server based on the parent domain provided by the service provider according to a set period.

[0161] The second scenario, where the monitor is not authorized by the domain owner (i.e., a strong privacy service), specifically includes:

[0162] The domain owner submits information about the service provider to the monitor to query or subscribe to the SP's subdomain editing certificate.

[0163] After receiving the information from the service provider, the monitor, according to the domain owner's request (query or subscription), checks the log server and sends the subdomain edit certificate of the service provider that meets the requirements to the domain owner.

[0164] The domain owner determines whether the subdomain edit certificate is bound to the domain of the domain owner based on the parameter certificate and the trapdoor. If a binding relationship exists, the subdomain edit certificate is audited.

[0165] Auditing refers to checking whether the edit certificate was issued with the authorization of the domain owner. The domain owner stores the authorized edit certificates.

[0166] When the monitor is not authorized by the domain owner, such as Figure 6 As shown, the second scenario includes more specific details:

[0167] DO submits SP information (including "server.com") to Monitor, and queries or subscribes to edit certificates for all subdomains of the SP.

[0168] Based on the DO's requirements, the Monitor checks the log server for query requests, identifies all SPs' subdomain edit certificates, and sends them to the DO; for subscription requests, it periodically checks the log server to identify SPs' subdomain edit certificates that have been newly submitted compared to the last check, and sends them to the DO.

[0169] DO verifies the equations for all certificates returned by the Monitor. To determine if the certificate is valid, check if it is bound to your domain. Then, audit the certificates bound to your domain, and report any malicious activity by the CA if a fake certificate is found.

[0170] In the third scenario, when the monitor is authorized by the domain owner, i.e., in the case of a weak privacy service, such as... Figure 7 As shown, it specifically includes:

[0171] The domain owner submits the service provider's information to the monitor, queries or subscribes to the SP's subdomain editing certificate, and simultaneously sends the trapdoor to the monitor.

[0172] After receiving the information from the service provider, the monitor, according to the DO's requirements, searches the log server for all subdomain edit certificates of the service provider in response to the query request; for the subscription request, it checks the log server to obtain all subdomain edit certificates of the service provider that have been added since the previous search, and checks each of the subdomain edit certificates obtained in the search according to the parameter certificate and the trapdoor, that is, checks whether there is a binding relationship between the edit certificate and the domain owner's domain. If a binding relationship exists, the checked subdomain edit certificates are sent to the domain owner.

[0173] The domain owner audits the subdomain edit certificate returned by the monitor.

[0174] As a specific implementation method, when the monitor is a monitor authorized by the domain name owner, the third case more specifically includes:

[0175] The DO submits SP information (including "server.com") to the Monitor, queries or subscribes to the SP's editable subdomain certificate, and simultaneously sends the trapdoor to the Monitor via a secure channel.

[0176] Based on the service requested by DO, Monitor checks the corresponding subdomain edit certificates of SP in the log server and verifies them one by one. To determine if the equation is true, all certificates that make the equation true are sent to the DO via a secure channel. Equation If established, the editing certificate is bound to the domain name of the domain owner.

[0177] DO directly audits the certificates returned by the Monitor, and reports malicious behavior of the CA if a fake certificate is found.

[0178] This invention provides a certificate editing service that combines privacy protection and transparent auditing within the PKI certificate transparency ecosystem. By editing the domain name information bound to the certificate, privacy protection for private domain names is achieved. At the same time, an entity that possesses the DO trapdoor can retrieve all related edited certificates of DO in the log server. Any entity in the system can verify the correctness and retrievability of the edited certificate without possessing the trapdoor.

[0179] The object of editing is the domain name. The edited result is transparent and searchable to entities that hold trapdoors, while maintaining privacy for entities that do not hold trapdoors. The purpose of editing is to generate an editing certificate.

[0180] The domain name bound to the edit certificate contains private information that is not convenient to be publicly disclosed in the log server. It is bound to the domain name of the corresponding DO, and the editing process and signing are completed by the CA. It can be retrieved in the log server by entities that have mastered the trapdoor. The binding relationship between the edit certificate and the domain name can be verified without disclosing the trapdoor information.

[0181] The trapdoor is bound to the domain name of the DO, generated by the SP using a private key, and used to retrieve the editing certificate. This ensures that the editing certificate is transparent and auditable, and should only be held by the SP, the DO, and entities trusted by the DO.

[0182] Retrieve Edit Certificate: Based on bilinear mapping, generated using SP's public key / parameters, and performed using a trapdoor; the retrieval can be performed by any entity that possesses the trapdoor information, including but not limited to DOs and entities trusted by DOs that provide the trapdoor information; the purpose of the retrieval is to ensure that the edit certificate is transparent and auditable.

[0183] Verifying the edit certificate: The entity performing the verification does not need to know the trapdoor information; the entity performing the verification needs to obtain the domain name binding commitment for the corresponding edit certificate from the DO beforehand; the verification process requires the domain name binding commitment and the SP public key / parameters; the verified edit certificate is bound to the corresponding domain name.

[0184] SP's public key / parameters are transmitted through SP domain certificate, making forgery easily detectable.

[0185] A domain binding commitment, generated by DO, is used to help entities that need to verify the correctness of an edit certificate. Its characteristic is that it is associated with a specific edit certificate and does not disclose trapdoor information.

[0186] This invention applies to educational institutions, cloud website building platforms and website hosting platforms (e.g., wixsite.com), and dynamic DNS service providers (e.g., duckdns.org). These entities have a large user base, providing each user with an independent domain name and applying for a certificate for that domain. The certificate is submitted to the CT log. The domain name may reveal a user's name, email address, phone number, affiliation, and partnership information. Once a domain name contains user privacy information, it can never be erased. For example, as a website administrator, the website is hosted by a website hosting platform, but it's not a public service; it only provides services to a specific group of people. Therefore, the website administrator doesn't want to expose the website's domain name in the CT log. Similarly, as a researcher at a university, the university has created an independent website for each researcher, using the researcher's name as a subdomain (this is highly likely, as such domains are more trustworthy). The researcher doesn't want to expose their name and affiliation in the CT log. Websites can be deleted, but the information recorded in the CT log can never be erased. This invention's solution is needed to protect the privacy of these domain names.

[0187] This invention, while protecting domain name privacy, also ensures that the original transparency function of the CT system is not weakened, that is, it supports domain name owners to discover fake certificates by monitoring / retrieving log servers through the Monitor. In this invention, attackers (e.g., malicious CAs, SPs, etc.) have two main objectives: (1) to attempt to impersonate a DO, communicate with TLS clients as a DO, and evade CT audits as much as possible; (2) to extract as much private information about the DO as possible from the logs (e.g., plaintext domain name information, which certificates correspond to a certain DO).

[0188] First, consider the first type of attack objective:

[0189] During the initialization phase, an attacker (e.g., a malicious CA) might obtain a fake parameter certificate. The attacker can then impersonate a legitimate Service Provider (SP). Furthermore, the attacker uses this fake parameter certificate to request the CA to generate a fake edit certificate and sends the matching fake edit certificate and fake parameter certificate during the TLS connection, thus impersonating a Dominant Provider (DO) to communicate with the TLS client. Because the public parameters used are different, the fake edit certificate cannot be detected by the DO's trapdoor. However, the fake parameter certificate will be discovered by stakeholders (e.g., SP, other DOs) through Counter-Security Detection (CT), thus preventing this attack from succeeding. Even if the fake parameter certificate generates a series of fake edit certificates, since the use of an edit certificate requires the existence of a matching parameter certificate, revoking a parameter certificate is equivalent to revoking all edit certificates generated from that certificate. Therefore, the security issues caused by these fake edit certificates do not need to be considered.

[0190] During the trapdoor generation phase, a malicious SP might generate an incorrect trapdoor for DO, causing DO to lose its ability to detect fake edit certificates. However, the incorrect trapdoor will be verified and detected by DO, so this attack cannot be carried out.

[0191] During the certificate generation phase, a fake edit certificate generated by a CA in accordance with the protocol can be detected by the DO through CT. On the other hand, if a CA generates a fake edit certificate in violation of the protocol, it cannot pass the verification of the TLS client (i.e., the edit domain name generated by the CA does not match the result of the bilinear mapping) and is not trusted by the TLS client. Therefore, neither of the two malicious behaviors of the CA can complete the attack.

[0192] During the certificate verification and inspection phase, both the TLS client and the Monitor strictly adhere to the protocol, so there is no need to consider attacks in this area.

[0193] Next, consider the second type of attack objective:

[0194] Private domain information cannot be derived simply by editing the certificate. This invention uses two trapdoor one-way functions to ensure the privacy of domain information when generating R(id). It is not feasible to deduce domain information from R(id) without knowing the mapping relationship between the trapdoors and the domain.

[0195] Without knowing the trapdoor, the Monitor has no way of knowing which certificates on the log server correspond to the same DO; it can only obtain this information when the trapdoor is delegated to the Monitor. DOs use different random numbers when applying for certificates. Therefore, an adversary cannot deduce the id information from R(id), nor can they observe which edit certificates on the log server correspond to the same DO. Furthermore, because the trapdoor is directly bound to the DO's domain information, when the DO delegates the trapdoor to the Monitor, the Monitor can retrieve all of the DO's edit certificates without needing to know the edit domain's random numbers.

[0196] To combat dictionary and rainbow table attacks, previous domain name editing solutions employed a method of performing repeatable one-way transformations of the domain name. Since this one-way transformation process is public, it is vulnerable to dictionary and rainbow table attacks. These attacks occur because attackers have control over the entire process of generating the editable domain from the original domain. They can then repeat this process, verifying a match with the target editable domain, and thus iterating to find the real domain. In this invention, a random number is introduced as a "salt" value during the generation of the editable domain, thus preventing rainbow table attacks. Furthermore, due to the privacy of the trapdoor information, attackers cannot verify the correspondence between the editable and real domains, thereby preventing dictionary attacks.

[0197] Based on the aforementioned security assumptions, using R(id) as the edit domain is reasonable. First, R(id) does not expose the domain information of the DO, ensuring domain privacy. Second, during TLS connections with clients, the client can use the domain binding commitment generated by the DO to verify the mapping relationship between R(id) and the domain information id. Furthermore, the domain binding commitment only contains the random number used to generate the corresponding edit certificate, without revealing the trapdoor information, thus ensuring both the privacy of the trapdoor and the validity of the certificate. Finally, using the trapdoor information, the mapping relationship between R(id) and id can be quickly verified, ensuring that the certificate can be monitored / retrieved by the entity that possesses the trapdoor, thereby achieving transparency in the edit certificate.

[0198] This invention also implements controllable privacy protection. The Do can choose a trusted entity to share the trapdoor information with. The entity possessing the trapdoor can use this information to monitor / retrieve all of the Do's edit certificates from the log server. During the certificate monitoring / retrieval phase, due to the lack of trapdoor information, the Monitor cannot directly and accurately identify the certificate associated with the Do from the SP's subdomain edit certificate set. At this point, due to the privacy considerations discussed above, the Monitor cannot obtain any information about the Do's domain; an honest and curious Monitor lacks the ability to steal the Do's privacy. Furthermore, a scenario where the Monitor is trusted can be considered. In this case, the Do can entrust the trapdoor to a trusted third-party Monitor for hosting services, allowing the Monitor to automatically retrieve and filter related fake certificates. This weakens the privacy of the solution to some extent but reduces the Do's workload. In this invention, the two service methods mentioned above are referred to as strong privacy and weak privacy, respectively.

[0199] The advantages and positive effects of this invention are as follows:

[0200] The technical solution of this invention can effectively protect domain name privacy information. Simultaneously, utilizing searchable encryption, a certificate editing scheme is constructed that ensures domain name privacy while maintaining certificate transparency. This scheme can effectively resist rainbow table attacks and dictionary attacks; it meets fine-grained security needs in different scenarios, allowing for adjustment of privacy protection levels as needed.

[0201] In summary, the method proposed in this invention enhances both domain name privacy and the effectiveness of existing PKI certificate transparency services.

[0202] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0203] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for protecting identity privacy in a PKI certificate transparency service, characterized in that, include: The service provider generates a trapdoor based on the domain name information of the domain name owner and sends it to the domain name owner; The domain owner verifies the correctness of the trapdoor generated by the service provider based on the domain information; If the domain owner verifies the trapdoor correctly, the domain owner sends a request to the certificate authority to generate an edited certificate. After receiving the edit certificate generation request sent by the domain owner, the certificate authority generates an edit domain based on the domain owner's domain information, generates an edit certificate based on the edit domain, and sends the edit certificate to the log server. The log server generates a signature certificate timestamp for the edit certificate and sends the signature certificate timestamp to the certificate authority. The certificate authority sends the signature certificate timestamp and the edit certificate to the domain owner; Once the domain owner verifies that the timestamp of the signing certificate is correct and the edit certificate is correct, a domain binding commitment is generated for the edit certificate, and the TLS client initiates a domain connection request to the domain owner; The domain name binding commitment is generated based on the domain name information; After receiving the connection request, the domain owner sends the domain binding commitment, the signing certificate timestamp, and the edit certificate to the TLS client; The TLS client verifies whether the edit certificate and the domain name corresponding to the connection request match based on the received domain name binding commitment, the signing certificate timestamp, and the edit certificate. If they match, the TLS client continues to communicate with the domain name owner; otherwise, the TLS client terminates the connection with the domain name owner. The monitor retrieves edit certificates associated with the domain name owner from the log server and assists the domain name owner in auditing the retrieved edit certificates; The edit certificates associated with the domain owner's domain belong to the same parent domain.

2. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The monitor retrieves edit certificates associated with the domain name owner from the log server and assists the domain name owner in auditing the retrieved edit certificates, specifically including: When the monitor is the domain owner, the domain owner retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider; The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor; The domain owner audits the retrieved editing certificates.

3. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The monitor retrieves edit certificates associated with the domain name owner from the log server and assists the domain name owner in auditing the retrieved edit certificates, specifically including: When the monitor is a public third-party monitor that has not been authorized by the domain owner, the domain owner sends the parent domain provided by the service provider to the monitor; The monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider, and sends the retrieved subdomain edit certificate back to the domain owner; The domain owner retrieves the edit certificate bound to the domain owner's domain from the subdomain edit certificate according to the trapdoor; The domain owner audits the retrieved editing certificates.

4. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The monitor retrieves edit certificates associated with the domain name owner from the log server and assists the domain name owner in auditing the retrieved edit certificates, specifically including: When the monitor is a public third-party monitor authorized by the domain owner, the domain owner sends the parent domain provided by the service provider and the domain owner's trapdoor to the monitor; The monitor retrieves the subdomain editing certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider; The monitor retrieves the edit certificate bound to the domain name of the domain owner from the subdomain edit certificate according to the trapdoor, and sends the retrieved edit certificate back to the domain owner; The domain owner audits the retrieved editing certificates.

5. The method for protecting identity privacy in PKI certificate transparency service according to claim 4, characterized in that, The monitor retrieves the subdomain edit certificate corresponding to the parent domain from the log server based on the parent domain provided by the service provider, specifically including: The monitor retrieves, according to a set period, the subdomain edit certificates corresponding to the parent domain name newly added within the current set period from the log server based on the parent domain name provided by the service provider.

6. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The service provider generates a trapdoor based on the domain owner's domain information and sends it to the domain owner, specifically including: The service provider uses Trapdoor = H1(id) α Generate a trapdoor, where Trapdoor represents the trapdoor, id represents the domain name information, H1() represents the first hash function, and α represents the private key of the service provider.

7. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The domain owner verifies the correctness of the trapdoor generated by the service provider based on the domain information, specifically including: The domain owner verification equation If the statement is valid, then the domain owner verification trap is correct. Here, H1() represents the first hash function, H2() represents the second hash function, Trapdoor represents a trapdoor, and id represents domain information. It is defined as The bilinear mapping, where and Both are q-order groups, and g is a group. The generator, h = g α , Let represent the set of all elements in the remainder class modulo q that are relatively prime to q, where q is a large prime number.

8. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, After receiving the edit certificate generation request from the domain owner, the certificate authority generates an edit domain name based on the domain owner's domain information, generates an edit certificate based on the edit domain name, and sends the edit certificate to the log server, specifically including: The domain owner sends a certificate generation edit request to the certificate authority, and simultaneously sends the domain information and a random number to the certificate authority; wherein the random number is a currently generated random number; After receiving the edit certificate generation request, the certificate authority verifies whether the domain name information is valid. If valid, it generates an edit domain name based on the random number and the domain name information. The certificate authority generates an editing certificate based on the edited domain name and sends the editing certificate to the log server.

9. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The formula for generating the edited domain name is expressed as follows: Where R(id) represents the edited domain name, R1 represents the first intermediate parameter, R2 represents the second intermediate parameter, r represents a random number, id represents the domain name information, H1() represents the first hash function, and H2() represents the second hash function. It is defined as bilinear mapping, and Both are q-order groups, and g is a group. The generator, h = g α , Let represent the set of all elements in the remainder class modulo q that are relatively prime to q, where q is a large prime number.

10. The method for protecting identity privacy in PKI certificate transparency service according to claim 1, characterized in that, The TLS client verifies whether the edit certificate and the domain name corresponding to the connection request match based on the received domain name binding commitment, the signing certificate timestamp, and the edit certificate. If they match, the TLS client continues communication with the domain name owner; otherwise, the TLS client terminates the connection with the domain name owner. Specifically, this includes: Verify the equation With Equation Whether both conditions are met simultaneously: if both conditions are met, then the domain name corresponding to the edit certificate and the connection request matches; if not both conditions are met, then the domain name corresponding to the edit certificate and the connection request does not match. Where H1() represents the first hash function, H2() represents the second hash function, Aux represents the domain name binding commitment, id represents the domain name information, R1 represents the first intermediate parameter, and R2 represents the second intermediate parameter. It is defined as bilinear mapping, and Both are q-order groups, and g is a group. The generator, h = g α , Let q represent the set of all elements in the residue class modulo q that are relatively prime to q, where q is a large prime number. Aux = H1(id) r , where r represents a random number.

Images