A method for protecting privacy of a CA based on a blockchain

Abstract

This invention discloses a method for protecting CA privacy in a blockchain-based PKI system. The method first generates a user's private and public keys, along with corresponding parameters, and the issuing CA generates a chainable ring signature for message m. Next, the domain owner performs certificate registration and requests certificate renewal from the ring CA before the certificate expires. Upon successful verification, the certificate is renewed for the domain owner. Then, if the domain owner's personal information changes, or if the certificate's private key is lost or leaked, the domain owner requests certificate revocation from the ring CA. Upon successful verification, the certificate is revoked for the domain owner. Finally, when a client initiates a TLS connection request to the domain, the client verifies the validity and authenticity of the certificate. Upon successful certificate verification, the client establishes a TLS connection with the domain. This invention prevents attackers from launching attacks against the issuing CA of high-value target domains, improves the security of the PKI system, and enhances the efficiency of rapid certificate response.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology application and mainly relates to a method for protecting CA privacy based on blockchain PKI. Background Technology

[0002] With the widespread adoption of the internet, people are increasingly valuing privacy and security in online communication. Transport Layer Security (TLS), a commonly used encryption protocol in network communication, provides security and data integrity. In particular, authentication and secure communication within TLS are built on Public Key Infrastructure (PKI). PKI uses public key digital certificates to verify the identity of websites, and its core component is the Certificate Authority (CA), which is responsible for issuing, managing, and revoking certificates. Therefore, the security of PKI largely depends on the CA that issues TLS certificates to websites.

[0003] However, the numerous security vulnerabilities that have emerged in CAs in recent years have brought great challenges to secure communication in reality. These include single points of failure for CAs, high-value domains being vulnerable to targeted attacks, lax auditing by Registry Authorities (RAs), and CAs having excessive power to issue certificates to any domain in the network.

[0004] The introduction of blockchain provides a solution to the problems or challenges that arise in traditional PKI. The decentralized, immutable, and traceable characteristics of blockchain are well-suited to the PKI system, while also taking into account low-cost trust and public auditability, thus providing a solution to address single points of failure of CAs and improper behavior of CAs.

[0005] However, existing blockchain-based PKI solutions still suffer from problems such as excessive power of a single CA, privacy leaks when issuing CAs, and low efficiency and slow certificate response times due to the blockchain. Summary of the Invention

[0006] To address the aforementioned issues, this invention proposes a method for protecting CA privacy using blockchain-based PKI. By combining linkable ring signatures with blockchain-based PKI, the method solves the problems of CA issuance vulnerability to attacks and slow certificate response in blockchain-based PKI, thereby improving the security of the PKI system.

[0007] The present invention provides a method for protecting CA privacy based on blockchain PKI, comprising the following steps.

[0008] Step 1: Generate system parameters, including the user's private and public keys, and the corresponding parameters for the elliptic curve.

[0009] Step 2: Generate a linkable ring signature and issue it to the CA using the private key sk. πGenerate a linkable ring signature for message m using the public key list L of the same level CA.

[0010] Step 3: Certificate Registration. After the domain owner's information is approved by the RA, the ring CA performs the certificate registration operation for the domain owner.

[0011] Step 4: Certificate renewal. Before the certificate expires, the domain owner applies to the Ring CA for a certificate renewal. After the Ring CA verifies the application, it performs the certificate renewal operation for the domain owner.

[0012] Step 5: Certificate Revocation. When the domain owner's personal information changes, or the certificate's private key is lost or leaked, the owner applies to the Ring CA to revoke the certificate. After the Ring CA verifies the application, it performs the certificate revocation operation for the domain owner.

[0013] Step 6: Certificate verification. When the client initiates a TLS connection request to the domain, the client verifies the validity and authenticity of the certificate through the blockchain and CRL. After the certificate verification is successful, the client establishes a TLS connection with the domain.

[0014] Furthermore, step 1 includes the following specific steps:

[0015] Step 1.1: Choose a large prime number p, E(F p ) is defined in the finite field F p An elliptic curve on a given elliptic curve; an additive group consisting of points on the given elliptic curve. Let G be a group whose order is a prime number q. The generator.

[0016] Step 1.2: For two secure hash functions.

[0017] Step 1.3: Randomly select a user's private key as... Calculate the public key as PK i =sk i ·G.

[0018] Furthermore, step 2 includes the following specific steps:

[0019] Step 2.1: Issue a public key list L = {PK1, PK2, ..., PK1} by randomly selecting the public keys of n-1 peer CAs and its own public key. n The CA is issued by the π-th user (1≤π≤n), and the CA is issued using the private key sk. π Generate a linkable ring signature for message m using the public key list L of the same level CA.

[0020] Step 2.2: Calculate the link tag Qπ = sk π ·H p (PK π ).

[0021] Step 2.3: Select a random number Calculate c π+1 =H1(L, Q) π ,m,k π ·G,k π ·H p (PK π )).

[0022] Step 2.4: Select a random number and scalar c i Calculate L i =s i ·G+c i ·PK i ;R i =s i ·H p (PK i )+c i ·Q π ;c i+1 =H1(L, Q) π ,m,L i R i ); where c1 = c n+1 .

[0023] Step 2.5: Calculate s π =(k π -c π ·sk π )mod q.

[0024] Step 2.6: Output the signature σ of the linkable ring. L (m)=(Q π c1, s1, ..., s n ).

[0025] Furthermore, step 3 includes the following specific steps:

[0026] Step 3.1: The root CA registers in the blockchain, and the child CAs register in the blockchain based on the certificates issued by the root CA, thereby making the public keys of each CA public.

[0027] Step 3.2: After the domain owner's information is approved by the Registration Authority (RA), the issuing CA uses its own private key, public key, and the public keys of other peer CAs to form a ring CA to perform a ring signature on the certificate registration transaction, and submits the certificate registration transaction to the blockchain to await verification by the verification nodes.

[0028] Step 3.3: The verification node verifies the transaction, packages the transaction into a block and broadcasts it to the network, and then sends the block number of the transaction to the ring CA.

[0029] Step 3.4: The ring CA generates an X.509 certificate based on the block number. The field value of the certificate operation is certificate registration, and the certificate is stored in the InterPlanetary File System (IPFS).

[0030] Furthermore, step 5 includes the following specific steps:

[0031] Step 5.1: When the domain owner's personal information changes, or the certificate's private key is lost or leaked, the domain owner submits a certificate revocation request to Ring CA.

[0032] Step 5.2: At this point, the issuing CA in the ring CA can only perform subsequent operations on the certificate if it has passed the verification of the Link(L, M1, M2, σ1, Q1, σ2, Q2) → linked|unlinked linking algorithm. That is, only the one who issued the certificate has the right to revoke it.

[0033] Step 5.3: Maintain a global state table certRevRequest, with the key being the certificate serial number and the value being the certificate status 0 or 1. The default certificate status is 1. When the domain owner submits a certificate revocation request, the certificate status is changed to 0.

[0034] Step 5.4: The ring CA signs this revocation request and publishes it to the blockchain. An X.509 certificate is generated based on the block number of the transaction. The field value of the certificate operation is certificate revocation. The certificate is stored in IPFS.

[0035] Step 5.5: The ring CA sends this certificate to the issuing CA's Certificate Revocation List (CRL), which stores the serial number and revocation date of the revoked certificate.

[0036] This invention offers the following advantages: The issuing CA (Certificate Authority) is anonymous. Even if an attacker impersonates a legitimate domain owner, the true identity of the issuing CA remains unknown because the domain owner communicates with the CA throughout the process. Furthermore, the anonymity of the issuing CA prevents attacks targeting high-value domains, avoiding public exposure and increasing the attacker's cost, thus significantly improving the security of the PKI system. In addition, using IPFS to store certificates reduces the pressure on certificate operations on the blockchain, decoupling the blockchain layer from the storage layer and further improving the efficiency of rapid certificate response. Therefore, this invention improves the security and efficiency of blockchain-based PKI systems through privacy protection and decentralized storage. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating a method for protecting CA privacy based on blockchain PKI according to the present invention.

[0038] Figure 2This is a comparison diagram of the novel certificate formats of the present invention;

[0039] Figure 3 This is a diagram of the ring CA structure of the present invention;

[0040] Figure 4 This is a flowchart of the certificate registration and update process for this invention.

[0041] Figure 5 This is a flowchart illustrating the certificate revocation process of the present invention.

[0042] Figure 6 This is a flowchart of the certificate verification process for the present invention. Detailed Implementation

[0043] To better understand the purpose, structure, and function of this invention, the following detailed description of a blockchain-based PKI method for protecting CA privacy is provided in conjunction with the accompanying drawings.

[0044] like Figure 1 As shown, a method for protecting CA privacy based on blockchain PKI includes the following steps:

[0045] Step 1: Generate system parameters: Generate the user's private and public keys, as well as the corresponding parameters for the elliptic curve. The implementation method is as follows:

[0046] Step 1.1: Choose a large prime number p to provide sufficient safety, E(F p ) is defined in the finite field F p An elliptic curve on a given elliptic curve; an additive group consisting of points on the given elliptic curve. Let G be a group whose order is a prime number q. The generator.

[0047] Step 1.2: For two secure hash functions.

[0048] Step 1.3: Randomly select a user's private key as... Calculate the public key as PK i =sk i ·G.

[0049] Step 2: Generate a linkable ring signature: The issuing CA uses the private key sk π Generate a linkable ring signature for message m using the public key list L of peer CAs. The implementation method is as follows:

[0050] Step 2.1: Issue a public key list L = {PK1, PK2, ..., PK1} by randomly selecting the public keys of n-1 peer CAs and its own public key. nThe CA is issued by the π-th user (1≤π≤n), and the CA is issued using the private key sk. π Generate a linkable ring signature for message m using the public key list L of the same level CA.

[0051] Step 2.2: Calculate the link tag Q π =sk π ·H p (PK π In subsequent certificate operations, it is necessary to refer to Q. π This is used to verify the consistency of the issuing CA, that is, the chainability of the signature.

[0052] Step 2.3: Select a random number Calculate c π+1 =H1(L, Q) π ,m,k π ·G,k π ·H p (PK π )).

[0053] Step 2.4: Select a random number and scalar c i random number s i Each key corresponds to a public key, and L is calculated. i =s i ·G+c i ·PK i ;R i =s i ·H p (PK i )+c i ·Q π ;c i+1 =H1(L, Q) π ,m,L i R i ); where c1 = c n+1 In the verification of a linkable ring signature, it is necessary to check whether c1 equals c. n+1 To determine the validity of a chainable ring signature.

[0054] Step 2.5: Calculate s π =(k π -c π ·sk π )mod q.

[0055] Step 2.6: Output the signature σ of the linkable ring. L (m)=(Q π c1, s1, ..., s n ).

[0056] Step 3 Certificate Registration: After the domain owner's information is approved by the RA, the ring CA performs the certificate registration operation for the domain owner, such as... Figure 4 As shown, its implementation method is as follows:

[0057] Step 3.1: The root CA registers in the blockchain, and the child CAs register in the blockchain based on the certificates issued by the root CA, thereby making the public keys of each CA public and facilitating subsequent operations on the public key list of the ring CA.

[0058] Step 3.2: After the domain owner's information is approved by the Registration Authority (RA), the issuing CA uses its own private key, public key, and the public keys of other peer CAs to form a ring CA to perform a ring signature on the certificate registration transaction, and submits the transaction to the blockchain to await verification by the verification nodes. The structure of the ring CA is as follows: Figure 3 As shown, the left side of the image represents a traditional certificate trust chain. The public disclosure of the issuing CA in the certificate provides attackers with valuable information. In this invention, we use linkable ring signatures to form a ring CA instead of a single issuing CA, thus protecting the privacy of the issuing CA.

[0059] Step 3.3: The verification node verifies the transaction, packages the transaction into a block and broadcasts it to the network. Then, it sends the block number of the transaction to the ring CA. The block number, which is the block height value, needs to be embedded in the certificate to facilitate certificate verification.

[0060] Step 3.4: The ring CA generates an X.509 certificate based on the block number. The field value of the certificate operation is certificate registration. Recording the field value of the certificate operation is to ensure that the certificate operation exists in the blockchain during certificate verification. The certificate is stored in IPFS to ensure decentralized storage and accessibility. The certificate used in this invention is as follows: Figure 2 As shown, we have added fields such as ring CA, IPFS link, block height, and certificate operation to the original X.509 standard certificate format, which makes it easier to locate each operation of the certificate in the blockchain and enhances the traceability and verifiability of the certificate.

[0061] Step 4: Certificate Renewal: Before the certificate expires, the domain owner applies for a certificate renewal from the Ring CA. After verification, the Ring CA performs the certificate renewal operation for the domain owner, such as... Figure 4 As shown, its implementation method is as follows:

[0062] Step 4.1: Before the certificate expires, the domain owner submits a certificate renewal request to the ring CA. The issuing CA in the ring CA verifies the certificate's validity or changes the key pair using the Link(L, M1, M2, σ1, Q1, σ2, Q2) → linked|unlinked linkage algorithm. This linkage algorithm determines whether the signatures are from the same signer based on the output. If the output is linked, it is from the same signer; if the output is unlinked, it is from different signers. The purpose of this is to ensure that the issuing CA performing certificate registration and certificate renewal is the same CA, preventing other CAs in the ring CA from maliciously manipulating the certificate.

[0063] Step 4.2: The ring CA signs this transaction using a linkable ring signature and publishes it to the blockchain. Subsequently, a new X.509 certificate is generated based on the block number of the transaction. The field value of the certificate operation is certificate update, and the certificate is stored in IPFS.

[0064] Step 5: Certificate Revocation: When the domain owner's personal information changes, or the certificate's private key is lost or leaked, the domain owner requests certificate revocation from the Ring CA. After verification, the Ring CA performs the certificate revocation operation for the domain owner. Figure 5 As shown, its implementation method is as follows:

[0065] Step 5.1: When the domain owner's personal information changes, or the certificate's private key is lost or leaked, the domain owner submits a certificate revocation request to Ring CA.

[0066] Step 5.2: At this point, only the issuing CA in the ring CA can perform subsequent operations on the certificate if it has passed the verification of the Link(L, M1, M2, σ1, Q1, σ2, Q2) → linked|unlinked linkage algorithm. That is, only the one who issued the certificate has the right to revoke it, to prevent other CAs in the issuing CA from acting maliciously and arbitrarily revoking the certificate.

[0067] Step 5.3: To ensure the timeliness of subsequent certificate verification, we will maintain a global status table certRevRequest, with the certificate serial number as the key and the certificate status as 0 or 1 as the value. The default certificate status is 1. When the domain owner submits a certificate revocation request, the certificate status is changed to 0. This is to prevent the certificate from being revoked but not updated in the CRL.

[0068] Step 5.4: Since certificates cannot be directly deleted in the blockchain, and also considering the integrity of the certificate process audit, the Ring CA signs this revocation transaction and publishes it to the blockchain. An X.509 certificate is generated based on the block number of the transaction. The field value of the certificate operation is certificate revocation, and the certificate is stored in IPFS.

[0069] Step 5.5: The ring CA sends this certificate to the CRL of the issuing CA. The CRL stores the serial number and revocation date of the revoked certificate. Each issuing CA in the ring CA maintains its own corresponding CRL.

[0070] Step 6 Certificate Verification: When a client initiates a TLS connection request to the domain, the client verifies the validity and authenticity of the certificate using the blockchain and CRL. After successful certificate verification, the client establishes a TLS connection with the domain, such as... Figure 6 As shown, its implementation method is as follows:

[0071] Step 6.1: When the client establishes a TLS connection with the target domain, the client will receive a certificate from the domain. The client needs to verify the validity and authenticity of this certificate. Only if both are verified can the client establish a TLS connection with the domain.

[0072] Step 6.2: The client extracts the public key from the ring CA member and verifies it using the Verify(PP, M, L, σ, Q) algorithm. π → accept|reject Verify whether the ring signature of this certificate is valid. If the status is reject, terminate the connection; if the status is accept, continue to the next verification step.

[0073] Step 6.3: The client verifies whether the certificate is valid by checking the Validity field value. If it is not valid, the connection is terminated; if it is valid, the client continues to the next verification step.

[0074] Step 6.4: Certificate operation existence check. The client locates the certificate operation transaction based on the certificate's block height and checks whether the certificate registration or update operation exists in the blockchain. If it does not exist, the connection is terminated; if it exists, the next verification step is continued.

[0075] Step 6.5: The client requests the CRL from the ring CA. The issuing CA of the certificate in the ring CA verifies the CRL using the Link(L, M1, M2, σ1, Q1, σ2, Q2) → linked|unlinked linkage algorithm and then sends the corresponding CRL to the client. This is to ensure that the client receives the CRL of the issuing CA of the certificate.

[0076] Step 6.6: The client verifies whether the certificate's serial number exists in the CRL. If it exists, the connection is terminated. If it does not exist, the client checks the global hash table certRevRequest to verify whether there is a revocation request for the certificate. This is to prevent the certificate from being revoked without being updated in the CRL. If the return value is 0, the connection is terminated. If the return value is 1, the client establishes a TLS connection with the domain.

[0077] It is understood that the present invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, under the teachings of the present invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of the present invention.

Claims

1. A method for protecting CA privacy based on blockchain PKI, characterized in that, Comprise the following steps: Step 1: generate the user's private key and public key, and the corresponding parameters of elliptic curve, the specific process is as follows: Step 1.1: Choose a large prime number , is an elliptic curve defined over a finite field ; given a point on the elliptic curve forms an additive group , the order of this group is a prime number , let be a generator of the group ; Step 1.2: , are two secure hash functions; Step 1.3: Randomly select a user's private key as , and calculate the public key as = ; Step 2: The issuing CA uses the private key and the list of sibling certificate authority CA public keys generate a linkable ring signature on the message , as follows: Step 2.1: The issuing CA randomly selects n-1 public keys of peer CAs and the public key of the issuing CA itself to form a public key list , the issuing CA generates a linkable ring signature for the message ;​​​ Step 2.2: Calculate link tags ​​ Step 2.3: Select a random number , compute ; Step 2.4: Select a random number and a scalar , compute ; ; ; where ; Step 2.5: Calculation q; Step 2.6: Output linkable ring signature ; Step 3: the information of the domain owner is audited by the registration center RA, and the ring CA performs the certificate registration operation for the domain owner, the specific process is as follows: Step 3.1: the root CA is registered in the blockchain, and the sub-CA is registered in the blockchain according to the certificate issued by the root CA, so as to disclose the public keys of each CA; Step 3.2: when the information of the domain owner is audited by the registration center RA, the issuing CA uses the ring CA composed of its own private key, public key and the public keys of other peer CAs to sign the certificate registration transaction, and submits the certificate registration transaction to the blockchain for verification by the verification node; Step 3.3: the verification node verifies the transaction, packs the transaction into a block and broadcasts it to the network, and then sends the block number where the transaction is located to the ring CA; Step 3.4: the ring CA generates X.509 certificate according to the block number, the field value of the certificate operation is certificate registration, and the certificate is stored in the interstellar file system IPFS; Step 4: the domain owner applies to the ring CA for updating the certificate before the certificate expires, and the ring CA verifies and performs the certificate update operation for the domain owner after verification; Step 5: when the personal information of the domain owner changes, the private key of the certificate is lost or leaked, the ring CA applies for revoking the certificate, and the ring CA verifies and performs the certificate revocation operation for the domain owner after verification; Step 6: when the client initiates a transport layer security protocol TLS connection request to the domain, the client verifies the validity and authenticity of the certificate through the blockchain and the certificate revocation list CRL, and establishes a TLS connection with the domain after the certificate verification is passed.

2. The method for protecting CA privacy based on blockchain PKI according to claim 1, characterized in that, The specific process of step 4 is as follows: Step 4.1: The domain owner submits a certificate renewal request to the CA before the certificate expires, the signing CA in the CA verifies the request and issues a new certificate After the link algorithm is verified, the validity period of the updated certificate is verified or the key pair is replaced; Step 4.2: the ring CA signs the transaction using linkable ring signature and publishes it to the blockchain, and then generates a new X.509 certificate according to the transaction block number, the field value of the certificate operation is certificate update, and the certificate is stored in IPFS.

3. The method for protecting CA privacy based on blockchain PKI according to claim 2, characterized in that, The specific process of step 5 is as follows: Step 5.1: when the personal information of the domain owner changes, the private key of the certificate is lost or leaked, the domain owner applies for certificate revocation to the ring CA; Step 5.2: at this time, the signing CA in the ring CA can only pass The validation of the chaining algorithm enables subsequent operations on the certificate, i.e. who issued who has the right to revoke; Step 5.3: maintain a global state table certRevRequest, the key is the certificate serial number, and the value is the certificate state 0 or 1, the default state of the certificate is 1, and when the domain owner submits a certificate revocation application, the certificate state is changed to 0; Step 5.4: the ring CA signs the revocation application and publishes it to the blockchain, generates X.509 certificate according to the transaction block number, the field value of the certificate operation is certificate revocation, and the certificate is stored in IPFS; Step 5.5: the ring CA sends the certificate to the certificate revocation list CRL of the signing CA, and the CRL saves the serial number and revocation date of the revoked certificate.

4. The method for protecting CA privacy based on blockchain PKI according to claim 3, characterized in that, The specific process of step 6 is as follows: Step 6.1: when the client establishes a TLS connection with the target domain, the client receives the certificate from the domain; Step 6.2: the client extracts the public keys in the ring CA members, and verifies the certificate through the verification algorithm Verify the validity of the ring signature of this certificate, if the status is valid, then continue to the next step of verification; Step 6.3: The client verifies whether the certificate is in the valid period, if it is in the valid period, then continue to the next step verification; Step 6.4: The certificate operation existence check is carried out, the client locates the certificate operation transaction according to the block height of the certificate, checks whether the registration or update operation of the certificate exists in the blockchain, if it does not exist, then terminate the connection; if it exists, then continue to the next step of verification; Step 6.5: The client requests the CRL from the CA in the circle, whose issuing CA is verified by the chaining algorithm The corresponding CRL is sent to the client after the chaining algorithm is verified. Step 6.6: The client verifies whether the serial number of the certificate exists in the CRL, if it exists, then terminate the connection; if it does not exist, the client checks the certRevRequest to verify whether the certificate has a revocation request, which is to prevent the certificate from being revoked without being updated to the CRL, if the return value is 0, then terminate the connection.

Images