Cross-domain authentication method based on zero-knowledge proof

Abstract

The invention relates to the technical field of communication security, discloses a cross-domain authentication method based on zero-knowledge proof, and aims to improve security and privacy protection in a cross-domain authentication process. According to the method, the advanced zero-knowledge certification technology is used, the user is allowed to certify the certification qualification of the user to the certification server or the service provider under the condition that no personal sensitive information is leaked, the Groth16 zero-knowledge certification protocol is adopted, efficient, safe and anonymous cross-domain certification is achieved, and the method is suitable for application scenes needing high privacy protection and safety.

Description

Technical Field

[0001] The present application relates to the field of communication security technology, and specifically to a cross-domain authentication method based on zero-knowledge proof. Background Art

[0002] Internet users' demands for various resources and services on the network are constantly increasing. In order to meet user needs and build an information platform, data sharing has become a basic means. Through data sharing, various public information between different enterprises and institutions can be interconnected. However, in order to ensure the security of resources and services and prevent criminals from obtaining resources or accessing services within the domain, relatively independent trust domains are formed. Only trusted users and users within the domain can access its resources. Since users need to obtain different resources, cross-domain authentication issues arise.

[0003] At present, the more mainstream cross-domain authentication mechanisms include cross-domain authentication based on Public Key Infrastructure (PKI) and cross-domain authentication based on Identity Based Encryption (IBE). Since the cross-domain authentication methods and algorithms used between different domains may be different, cross-domain authentication between heterogeneous domains is difficult to achieve. Most cross-domain authentication schemes only study cross-domain authentication schemes between trust domains with the same authentication mechanism. Only a small number of schemes consider mutual authentication of devices in heterogeneous domains, and the authentication process is relatively cumbersome and inefficient. Summary of the invention

[0004] The purpose of this application is to provide a cross-domain authentication method based on zero-knowledge proof to solve the problems of insufficient privacy protection and low security in existing cross-domain authentication mechanisms, especially in terms of security authentication between heterogeneous domains.

[0005] To achieve the above objectives, the present application discloses the following technical solution: a cross-domain authentication method based on zero-knowledge proof, the method comprising the following steps:

[0006] S1. In the initialization phase, the authentication scheme and cryptographic algorithm information adopted by each participating domain are shared, and the Groth16 algorithm is initialized using secure multi-party computing to obtain the public reference string CRS;

[0007] S2, cross-domain initiator e i Generate a public-private key pair and send it to the authentication server AS in the originating domain. i Send a digital certificate request;

[0008] S3, cross-domain initiator i Apply for access credentials license from the target domain, using the authentication server ASi The public key of the authentication server AS encrypts the request message and sends it to the authentication server AS i ;

[0009] S4, authentication server AS of the initiating domain i After receiving the encrypted message, use the private key to decrypt it and verify the validity of the timestamp and certificate. If valid, generate a cross-domain initiator e i Real ID i ;

[0010] S5, authentication server AS i Real ID i , timestamp, cross-domain initiator i The public key of the cross-domain initiator e i The digital certificate and corresponding signature of the authentication server AS j The public key is encrypted and sent to the authentication server AS j ;

[0011] S6, authentication server AS j Decrypt the received message, verify whether the timestamp is valid, and then use the authentication server AS i The public key verifies the signature and verifies the real identity ID i If the authentication is successful, a real identity ID is generated. i The corresponding access credential license is sent back to the authentication server AS i ; Among them, the access credential license contains the real identity ID i and authentication server AS j The private key of

[0012] S7, authentication server AS i After receiving the access credential license, verify its validity and send it to the cross-domain initiator i ;

[0013] S8, cross-domain initiator i Initiate a cross-domain authentication request and send the access credential license, target domain, digital certificate, public key, communication public key, timestamp and corresponding signature encryption to the authentication server AS i ;

[0014] S9, authentication server AS i Generate proof π and send proof π and cross-domain initiator e i The communication public key and signature are sent to the authentication server AS j ;

[0015] S10, authentication server AS jUse the verification algorithm to verify the proof π. If the verification is successful, the user can be considered to have cross-domain access rights without obtaining the user's real identity.

[0016] S11, user e j Using the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiate a session key.

[0017] Preferably, the S1 specifically includes:

[0018] S101. In the initialization phase, the authentication scheme used by each participating domain, the algorithm for generating and verifying digital signatures, and the hash function used are shared;

[0019] S102. According to the scale of the circuit, the Groth16 algorithm is initialized to obtain a public reference string CRS. The public reference string CRS includes PK and VK, where PK is a parameter required by the prover to generate a proof, and VK is a parameter required by the verifier.

[0020] Preferably, the S2 specifically includes:

[0021] S201, when the cross-domain initiator e i The corresponding initiating domain is a PKI-based domain, and the public and private key pairs are generated locally; when the cross-domain initiator e i The corresponding initiating domain is a domain based on IBE. The public key is generated locally and sent to the key generation center KGC. The key generation center KGC combines the generated public key with its own master key to generate the user's private key, and then transmits the generated private key to the cross-domain initiator e through a secure channel. i And form a public-private key pair with the generated public key;

[0022] S202, cross-domain initiator e i To the authentication server AS of the originating domain i Send a digital certificate request to obtain the corresponding digital certificate.

[0023] Preferably, the S3 specifically includes:

[0024] S301, cross-domain initiator e i To the authentication server AS of the originating domain i Initiate a credential application request, which includes a digital certificate, a target domain, a public key, a timestamp, and a corresponding signature;

[0025] S302, using the authentication server AS i The public key of the authentication server AS encrypts the certificate application request and sends it to the authentication server AS i .

[0026] Preferably, the S6 specifically includes:

[0027] S601, authentication server AS j After receiving the message request, verify whether the timestamp is valid, and use the authentication server AS if the timestamp is valid i The public key verifies that the signature is correct and uses the cross-domain initiator e i Digital certificate to verify real identity ID i the legality of

[0028] S602: Generate real identity ID i The corresponding access credential license is sent to the authentication server AS i ; Access credential license binds authentication server AS j The real ID corresponding to the user's identity i , where the expression of access credential license is:

[0029]

[0030] Among them, G is the generator.

[0031] Preferably, the S7 specifically includes:

[0032] Authentication server AS i Get the authentication server AS j After the access credential license is sent, the correctness of the access credential license is verified through bilinear pairing. When the access credential license is verified to correspond to the authentication server AS j After issuance, it is sent to the cross-domain initiator e i .

[0033] Preferably, the S8 specifically includes:

[0034] S801, cross-domain initiator e i Generate a public and private key pair for communication;

[0035] S802, cross-domain initiator e i Initiate a cross-domain authentication request, use the public and private key pair used for communication to encrypt the access credential license, communication public key, timestamp and corresponding signature, and send them to the authentication server AS i .

[0036] Preferably, the S9 specifically includes:

[0037] S901, authentication server AS iVerify the legitimacy of the timestamp and signature in the cross-domain authentication request. If the verification is successful, generate a zero-knowledge proof.

[0038] S902, the prover Prover uses the parameter PK required to generate the proof to combine the statement φ and the private input ω to generate the proof π; according to the selected interpolation domain {r1,...,r d} Calculate the required interpolation polynomial t(x), then calculate the target polynomial h(x), and finally calculate the three points that prove π, π=(A,B,C); the calculation formula is as follows:

[0039]

[0040] a(x)b(x)-c(x)=t(x)h(x)

[0041]

[0042] Among them, α, β, δ and x are all secret values, r and s are randomly sampled random numbers, and H is a generator different from G.

[0043] Preferably, the S10 specifically includes:

[0044] S1001, authentication server AS j As a verifier, Verifier uses the common prefix to calculate D, which is used to subsequently verify the correctness of π. The calculation formula of D is:

[0045]

[0046] S1002. Prove the correctness of π through bilinear pairing verification, and the verification formula is: e(A,B)=e(αG,βH)·e(D,γH)·e(C,δH).

[0047] Preferably, the S11 specifically includes:

[0048] User j Successfully authenticated cross-domain initiator e i Then, use the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiate to use a symmetric key as the session key.

[0049] Compared with the prior art, this application has the following technical effects:

[0050] (1) Privacy protection: The user's real identity information and access footprint are protected during the authentication process and are not leaked to other domains;

[0051] (2) Enhanced compatibility: Cross-domain authentication is achieved through zero-knowledge proof, which can realize mutual authentication between heterogeneous domains;

[0052] (3) Efficiency improvement: The Groth16 algorithm is used to improve the efficiency of proof generation and verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0054] Figure 1 The architecture diagram corresponding to the cross-domain authentication method based on zero-knowledge proof provided in the embodiment of the present application. DETAILED DESCRIPTION

[0055] The technical solutions in the embodiments of the present application are described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application.

[0056] In this article, the term "comprising" is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of more restrictions, the elements defined by the sentence "comprising..." do not exclude the presence of other identical elements in the process, method, article or device that includes the elements.

[0057] Embodiment: A cross-domain authentication method based on zero-knowledge proof, that is, a cross-domain authentication scheme based on zero-knowledge proof, supports cross-domain authentication between heterogeneous domains. Zero-knowledge proof adopts the most efficient algorithm currently, and the proof is generated by the authentication server of the domain, which reduces the user's tasks. Zero-knowledge proof plays a very powerful role in protecting user privacy and achieving zero trust. In cross-domain authentication, users need to prove their identity to the target domain to obtain access rights, but for the sake of their own privacy protection, users may not want to reveal their true identity. Using zero-knowledge proof, users can generate a proof to prove that they have valid identity credentials without revealing actual identity information. In general, the cross-domain authentication scheme based on zero-knowledge proof in this embodiment includes three stages: initialization setup, Cross-domain license, and Cross-domainAuthentication. The corresponding authentication system architecture diagram is shown in the following figure. Figure 1 As shown. Figure 1 In the example, domainA is PKI-based domain A, and domain B is IBE-based domain B. i e to domain B j Send a cross-domain authentication request. Once the authentication is successful, the devices between the two domains use a secure key exchange protocol to negotiate the session key to ensure the security of subsequent communications. In the following content, the cross-domain authentication between domainA and domainB is used as an example.

[0058] Specifically, a cross-domain authentication method based on zero-knowledge proof includes the following steps:

[0059] Step 1: During the initialization setup phase, in order to ensure that cross-domain authentication and communication are not restricted, the authentication scheme and cryptographic algorithm used by each domain need to be shared among the authentication servers AS of all participating domains. It is worth noting that modern cryptographic designs all follow the Kerckhoffs principle. Therefore, the disclosure of this information will not affect the security of the system, and the AS of each domain holds the basic information of other domains. Blockchain technology can also be introduced to jointly maintain a chain containing the authentication scheme and cryptographic algorithm information used by all participating domains to improve efficiency. In addition, the Groth16 algorithm needs to be initialized. The initialization steps can be summarized as follows: share the authentication scheme and cryptographic algorithm information adopted by each participating domain, and use secure multi-party computing to initialize the Groth16 algorithm to obtain the public reference string CRS. The specific process is:

[0060] S101. In the initialization phase, the authentication scheme used by each participating domain, the algorithm for generating and verifying digital signatures, and the hash function used are shared;

[0061] S102. According to the scale of the circuit, the Groth16 algorithm is initialized to obtain the public reference string CRS. The public reference string CRS includes PK and VK, where PK is the parameter required by the prover to generate the proof, and VK is the parameter required by the verifier. In the public reference string CRS, R is a binary relationship that can be determined in polynomial time. For the public reference string CRSσ, based on the statement φ and the evidence ω, if there is a tuple (φ, ω)∈R, then the zero-knowledge cross-domain authentication is successful, that is, (σ, τ)←Setup(R).

[0062] Combination Figure 1 The cross-domain authentication between domainA and domain B is shown. The initialization setup phase is as follows:

[0063] S11', share authentication schemes and cryptographic algorithms to ensure interoperability between different systems. By sharing standardized authentication schemes and algorithms, different systems can understand and exchange authentication information with each other, thus achieving smooth cross-domain authentication.

[0064] S12'、e i Generate a pair of keys (pk i ,sk i ) and apply for a certificate from the CA. After CA verification, e i Keep your own digital certificate i .

[0065] S13'、e j Prove your identity to KGC and send an easily recognizable string as your public key pk j Give it to KGC and request the private key. KGC combines pk j Generate user private key sk with your own master private key j and sent to e via a secure channel j .

[0066] S14', in the initialization phase of Groth16, some public parameters CRS need to be generated to facilitate the generation of proofs later, using Type-F Pairing bilinear pairing. It can be generated through secure multi-party computation, G and H are the generators of G1 and G2 respectively. According to the circuit C generation, the points on G1 that need to be calculated are:

[0067] αG, βG, γG

[0068] G,xG,x 2 G,…,x d-1 G

[0069]

[0070] The points that need to be calculated on G2 are:

[0071] βH,γH,δH

[0072] H,xH,x 2 H,…x d-1 H

[0073] Among them, d is related to the circuit, and the five numbers α, β, γ, δ, and x are secret values. The security of the algorithm is related to the confidentiality of these values. In addition, these points implicitly contain many α-pairs, β-pairs, δ-pairs, and γ-pairs, which are very critical to the successful verification of the Groth16 algorithm.

[0074] Step 2: In the Cross-domain license phase, the cross-domain initiator e iNeed to provide user j Apply for access credentials license to facilitate the subsequent cross-domain authentication process. i Generate a public-private key pair and send it to the authentication server AS in the originating domain. i Send a digital certificate request; cross-domain initiator i Apply for access credentials license from the target domain, using the authentication server AS i The public key of the authentication server AS encrypts the request message and sends it to the authentication server AS i .

[0075] Among them, for the cross-domain initiator e i Generate a public-private key pair and send it to the authentication server AS in the originating domain. i Sending a digital certificate request includes:

[0076] S201, when the cross-domain initiator e i The corresponding initiating domain is a PKI-based domain, and the public and private key pairs are generated locally; when the cross-domain initiator e i The corresponding initiating domain is a domain based on IBE. The public key is generated locally and sent to the key generation center KGC. The key generation center KGC combines the generated public key with its own master key to generate the user's private key, and then transmits the generated private key to the cross-domain initiator e through a secure channel. i And form a public-private key pair with the generated public key;

[0077] S202, cross-domain initiator e i To the authentication server AS of the originating domain i Send a digital certificate request to obtain the corresponding digital certificate.

[0078] For cross-domain initiators i Apply for access credentials license from the target domain, using the authentication server AS i The public key of the authentication server AS encrypts the request message and sends it to the authentication server AS i Specifically, they include:

[0079] S301, cross-domain initiator e i To the authentication server AS of the originating domain i Initiate a credential application request, which includes a digital certificate, a target domain, a public key, a timestamp, and a corresponding signature;

[0080] S302, using the authentication server AS i The public key of the authentication server AS encrypts the certificate application request and sends it to the authentication server AS i .

[0081] Combination Figure 1The cross-domain authentication between domainA and domain B is shown. The specific contents of the Cross-domain license phase are as follows:

[0082] S21', when cross-domain authentication starts, e i Apply for identification code Licensing, certificate cert i , Destination B 、Public key pk i , timestamp T1 and corresponding signature Sign A To the AS of the domain.

[0083]

[0084] S22'、AS i After receiving M1, first verify whether the timestamp T1 is legal, and then use e i The public key pk i Verify the signature A Is it correct? If they are all correct, calculate e i Corresponding identity ID i =Hash(cert i ), where the hash function uses the SHA-256 algorithm.

[0085]

[0086] S23'、AS j After receiving M2, verify T2 and ID i Legality: If correct, generate the corresponding license and send it back to AS i .

[0087]

[0088] S24,AS i verify in After verification, the license will be sent to e i .

[0089] Step 3: In the Cross-domain Authentication phase, e i Need to AS j The authentication server AS of the initiating domain is used to verify the validity of the license and successfully authenticate without revealing specific information. i After receiving the encrypted message, use the private key to decrypt it and verify the validity of the timestamp and certificate. If valid, generate a cross-domain initiator e i Real IDi ;Authentication server AS i Real ID i , timestamp, cross-domain initiator i The public key of the cross-domain initiator e i The digital certificate and corresponding signature of the authentication server AS j The public key is encrypted and sent to the authentication server AS j ;Authentication server AS j Decrypt the received message, verify whether the timestamp is valid, and then use the authentication server AS i The public key verifies the signature and verifies the real identity ID i If the authentication is successful, a real identity ID is generated. i The corresponding access credential license is sent back to the authentication server AS i ; Among them, the access credential license contains the real identity ID i and authentication server AS j Private key of the authentication server AS i After receiving the access credential license, verify its validity and send it to the cross-domain initiator i ; Cross-domain initiator i Initiate a cross-domain authentication request and send the access credential license, target domain, digital certificate, public key, communication public key, timestamp and corresponding signature encryption to the authentication server AS i ;Authentication server AS i Generate proof π and send proof π and cross-domain initiator e i The communication public key and signature are sent to the authentication server AS j ;Authentication server AS j Use the verification algorithm to verify the proof π. If the verification is successful, the user can be considered to have cross-domain access rights without obtaining the user's real identity. j Using the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiate a session key.

[0090] For the authentication server AS of the originating domain i After receiving the encrypted message, use the private key to decrypt it and verify the validity of the timestamp and certificate. If valid, generate a cross-domain initiator e i Real ID i Specifically, they include:

[0091] AS i After receiving the message, use your own private key to decrypt it, verify the validity of the timestamp and certificate, and then generate e i Real IDi =Hash(cert i ).

[0092] For the authentication server AS i Real ID i , timestamp, cross-domain initiator i The public key of the cross-domain initiator e i The digital certificate and corresponding signature of the authentication server AS j The public key is encrypted and sent to the authentication server AS j Specifically, they include:

[0093] AS i Using AS j The public key of ID i , timestamp, e i The public key and corresponding signature are encrypted and sent to AS j Signing messages is also to prevent message tampering during transmission.

[0094] For the authentication server AS j Decrypt the received message, verify whether the timestamp is valid, and then use the authentication server AS i The public key verifies the signature and verifies the real identity ID i If the authentication is successful, a real identity ID is generated. i The corresponding access credential license is sent back to the authentication server AS i ; Among them, the access credential license contains the real identity ID i and authentication server AS j For the private key, it specifically includes:

[0095] S601、AS j After receiving the message request, verify whether the timestamp is valid, and then use AS i The public key verifies the signature to ensure that the request is indeed made by AS i Sent and using e i Digital certificate verification ID i the legitimacy of.

[0096] S602: Generate ID i The corresponding license is sent to the AS i . License Binding AS j The ID corresponding to the user identity i .

[0097] For the authentication server AS iAfter receiving the access credential license, verify its validity and send it to the cross-domain initiator i Specifically, they include:

[0098] AS i Get AS j After sending the license, the correctness of the license is verified through bilinear pairing to ensure that the certificate is issued by AS j Issued, and then sent to e i .

[0099] For cross-domain initiators i Initiate a cross-domain authentication request and send the access credential license, target domain, digital certificate, public key, communication public key, timestamp and corresponding signature encryption to the authentication server AS i Specifically, they include:

[0100] S801, e i The public and private key pairs used for communication are generated and sent to the target domain together with the certificate in the subsequent process.

[0101] S802, e i Initiate a cross-domain authentication request and use the AS to pass the license, communication public key, timestamp, etc. i The public key is encrypted and sent to AS i .

[0102] For the authentication server AS i Generate proof π and send proof π and cross-domain initiator e i The communication public key and signature are sent to the authentication server AS j For example, π←Prove(R,σ,φ,w):, the proof algorithm takes the CRS string σ and (φ,w)∈R as input and outputs a proof π, where π contains only three elliptic curve points. Specifically, it includes:

[0103] S901、AS i Verify the legitimacy of the timestamp and signature in the cross-domain authentication request. If successful, generate a zero-knowledge proof.

[0104] S902, need to AS j Prove that the license is valid without leaking the user's identity information. Circuit satisfiability is an NPC problem. The generated circuit is converted into an R1CS problem, then into a QAP problem, and then a zksnark is constructed to generate proof π. Prover uses PK to combine statement φ and private input w to generate proof. According to the selected interpolation domain {r1,...,r d}Calculate the required interpolation polynomial t(x), then calculate the target polynomial h(X), and then calculate the three points π, π=(A,B,C).

[0105]

[0106] a(X)b(X)-c(X)=t(X)h(X)

[0107]

[0108] For the authentication server AS j Use the verification algorithm to verify the proof π. If the verification succeeds, the user can be considered to have cross-domain access rights without obtaining the user's real identity. 0 / 1←Veriy(R,σ,φ,π): The verification algorithm takes the CRS string σ, statement φ and proof π as input, and outputs 0 for rejection and 1 for acceptance. Specifically, it includes:

[0109] S1001、AS j As a Verifier, D is calculated using the common prefix for subsequent verification of the correctness of π. The Verifier participates in part of the calculation to ensure the consistency of the calculation.

[0110]

[0111] S1002. Verify the correctness of π through bilinear pairing. Since Prover uses two random numbers r and s for randomization in the generation, the proof has zero knowledge and Verifier cannot obtain user identity information.

[0112] e(A,B)=e(αG,βH)·e(D,γH)·e(C,δH)

[0113] In the QAP problem, the verifier’s goal is to prove that t(x) divides a polynomial This is equivalent to the existence of a target polynomial h(x) that satisfies:

[0114]

[0115] In the proof of point A of π, there is an item The corresponding point B has an item

[0116] When the Verifier verifies the proof, it calculates e(A,B) to get the left side of the above equation.

[0117] Point C contains And e(C,δH) is equivalent to directly multiplying δ. The missing part from 1 to n is supplemented by D of Verifier, that is, e(D,γH), thus obtaining the right part.

[0118] For user e j Using the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiating the session key includes:

[0119] Symmetric encryption algorithms are usually faster than asymmetric encryption algorithms. j Successfully authenticated i Afterwards, the symmetric key obtained through negotiation can be used as the subsequent session key, thereby improving the overall encryption performance. Each session key is unique and forward secure.

[0120] Combination Figure 1 The cross-domain authentication between domainA and domain B is shown. The specific content of the Cross-domainAuthentication stage is as follows:

[0121] S31'、e i Send license, target domain Destination B , certificate cert i , public key pk i , communication public key pk' i , timestamp T4, and corresponding signature Sign' A

[0122]

[0123] S32'、AS i After receiving M4 and verifying it, the proof π is calculated based on the values ​​of CRS, license, etc., where license is the private input witness, and M5 is sent to AS j .

[0124]

[0125] Prove that π contains three elliptic curve points, and the calculation process of π=(A,B,C) is as follows:

[0126] e i As a Prover, first randomly sample two random numbers r and s, and calculate

[0127]

[0128] Next, settle three points:

[0129] Point A∈G

[0130]

[0131] Point B∈H

[0132]

[0133] Point C∈G

[0134]

[0135] S33'、AS j After receiving M5 and verifying it, calculate

[0136]

[0137] Combined with π, verify that the following formula holds:

[0138] e(A,B)=e(αG,βH)·e(D,γH)·e(C,δH)

[0139] S34', after successful authentication, e i and e j A key exchange protocol is performed to negotiate the session key.

[0140] Based on the above, this embodiment allows users to prove their valid certification qualifications without revealing personal sensitive information through zero-knowledge proof technology. This method does not rely on additional trusted third parties and improves the security and privacy protection of the authentication process.

[0141] Finally, it should be noted that the above are only preferred embodiments of the present application and are not intended to limit the present application. Although the present application has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments, or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A cross-domain authentication method based on zero-knowledge proof, characterized in that: The method comprises the following steps: S1. In the initialization phase, the authentication scheme and cryptographic algorithm information adopted by each participating domain are shared, and the Groth16 algorithm is initialized using secure multi-party computing to obtain the public reference string CRS; S2, cross-domain initiator e i Generate a public-private key pair and send it to the authentication server AS in the originating domain. i Send a digital certificate request; S3, cross-domain initiator i Apply for access credentials license from the target domain, using the authentication server AS i The public key of the authentication server AS encrypts the request message and sends it to the authentication server AS i ; S4, authentication server AS of the initiating domain i After receiving the encrypted message, use the private key to decrypt it and verify the validity of the timestamp and certificate. If valid, generate a cross-domain initiator e i Real ID i ; S5, authentication server AS i Real ID i , timestamp, cross-domain initiator i The public key of the cross-domain initiator e i The digital certificate and corresponding signature of the authentication server AS j The public key is encrypted and sent to the authentication server AS j ; S6, authentication server AS j Decrypt the received message, verify whether the timestamp is valid, and then use the authentication server AS i The public key verifies the signature and verifies the real identity ID i If the authentication is successful, a real identity ID is generated. i The corresponding access credential license is sent back to the authentication server AS i ; Among them, the access credential license contains the real identity ID i and authentication server AS j The private key of S7, authentication server AS i After receiving the access credential license, verify its validity and send it to the cross-domain initiator i ; S8, cross-domain initiator i Initiate a cross-domain authentication request and send the access credential license, target domain, digital certificate, public key, communication public key, timestamp and corresponding signature encryption to the authentication server AS i ; S9, authentication server AS i Generate proof π and send proof π and cross-domain initiator e i The communication public key and signature are sent to the authentication server AS j ; S10, authentication server AS j Use the verification algorithm to verify the proof π. If the verification is successful, the user can be considered to have cross-domain access rights without obtaining the user's real identity. S11, user e j Using the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiate a session key.

2. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S1 specifically includes: S101. In the initialization phase, the authentication scheme used by each participating domain, the algorithm for generating and verifying digital signatures, and the hash function used are shared; S102. According to the scale of the circuit, the Groth16 algorithm is initialized to obtain a public reference string CRS. The public reference string CRS includes PK and VK, where PK is a parameter required by the prover to generate a proof, and VK is a parameter required by the verifier.

3. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S2 specifically includes: S201, when the cross-domain initiator e i The corresponding initiating domain is a PKI-based domain, and the public and private key pairs are generated locally; when the cross-domain initiator e i The corresponding initiating domain is a domain based on IBE. The public key is generated locally and sent to the key generation center KGC. The key generation center KGC combines the generated public key with its own master key to generate the user's private key, and then transmits the generated private key to the cross-domain initiator e through a secure channel. i And form a public-private key pair with the generated public key; S202, cross-domain initiator e i To the authentication server AS of the originating domain i Send a digital certificate request to obtain the corresponding digital certificate.

4. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S3 specifically includes: S301, cross-domain initiator e i To the authentication server AS of the originating domain i Initiate a credential application request, which includes a digital certificate, a target domain, a public key, a timestamp, and a corresponding signature; S302, using the authentication server AS i The public key of the authentication server AS encrypts the certificate application request and sends it to the authentication server AS i .

5. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S6 specifically includes: S601, authentication server AS j After receiving the message request, verify whether the timestamp is valid, and use the authentication server AS if the timestamp is valid i The public key verifies that the signature is correct and uses the cross-domain initiator e i Digital certificate to verify real identity ID i the legality of S602: Generate real identity ID i The corresponding access credential license is sent to the authentication server AS i ; Access credential license binds authentication server AS j The real ID corresponding to the user's identity i , where the expression of access credential license is: Among them, G is the generator.

6. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S7 specifically includes: Authentication server AS i Get the authentication server AS j After the access credential license is sent, the correctness of the access credential license is verified through bilinear pairing. When the access credential license is verified to correspond to the authentication server AS j After issuance, it is sent to the cross-domain initiator e i .

7. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S8 specifically includes: S801, cross-domain initiator e i Generate a public and private key pair for communication; S802, cross-domain initiator e i Initiate a cross-domain authentication request, use the public and private key pair used for communication to encrypt the access credential license, communication public key, timestamp and corresponding signature, and send them to the authentication server AS i .

8. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S9 specifically includes: S901, authentication server AS i Verify the legitimacy of the timestamp and signature in the cross-domain authentication request. If the verification is successful, generate a zero-knowledge proof. S902, the prover Prover uses the parameter PK required to generate the proof to combine the statement φ and the private input ω to generate the proof π; according to the selected interpolation domain {r1,...,r d } Calculate the required interpolation polynomial t(x), then calculate the target polynomial h(x), and finally calculate the three points that prove π, π=(A,B,C); the calculation formula is as follows: a(x)b(x(-c(x)=t(x)h(x) Among them, α, β, δ and x are all secret values, r and s are randomly sampled random numbers, and H is a generator different from G.

9. The cross-domain authentication method based on zero-knowledge proof according to claim 8, characterized in that: The S10 specifically includes: S1001, authentication server AS j As a verifier, Verifier uses the common prefix to calculate D, which is used to subsequently verify the correctness of π. The calculation formula of D is: S1002. Prove the correctness of π through bilinear pairing verification, and the verification formula is: e(A,B)=e(αG,βH)·e(D,γH)·e(C,δH).

10. The cross-domain authentication method based on zero-knowledge proof according to claim 1, characterized in that: The S11 specifically includes: User j Successfully authenticated cross-domain initiator e i Then, use the cross-domain initiator i The communication public key of the cross-domain initiator e i Negotiate to use a symmetric key as the session key.

Images