An identity verification system, method, electronic device and readable storage medium

Abstract

The present application relates to the technical field of information security and privacy protection, and particularly relates to an identity authentication system and method, an electronic device and a readable storage medium, the system comprising a client, a token issuing end and an identity authentication end; the client is used for determining an identity binding commitment, a token binding commitment, a structured message coding and a first proof based on an identity key pair and identity permissions, and sending them to the token issuing end, so that the token issuing end generates a master token of the client based on an issuer key pair and the structured message coding after verifying the effectiveness of the first proof based on the public key of the client; the token issuing end generates a binding token of the client based on the master token, the identity key pair and the identity permissions of the client; and the token issuing end sends the master token and the binding token to the identity authentication end, so that the identity authentication end verifies whether the identity of the client is valid. In this way, the accuracy of the publicly verifiable anonymous token identity authentication is improved through the combination of the double-token binding mechanism and the zero-knowledge proof.

Description

Technical Field

[0001] This invention relates to the fields of information security and privacy protection technology, and in particular to an authentication system, method, electronic device, and readable storage medium. Background Technology

[0002] Anonymous tokens are credentials used for identity authentication and authorization. They are constructed using blind signatures, unintentional pseudo-random functions, and algebraic message authentication codes, providing users with anonymity and verifiability, allowing users to securely access services or resources while maintaining privacy.

[0003] Existing non-transferable anonymous tokens cannot be publicly verified, requiring verifiers to share keys with issuers, hindering their deployment in open scenarios. Conversely, existing publicly verifiable anonymous tokens lack a non-transfer mechanism, allowing users to resell tokens, thus violating the "trust binding" principle of anonymous tokens and resulting in lower accuracy for identity verification. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one authentication system, method, electronic device, and readable storage medium, which improves the accuracy of publicly verifiable anonymous token authentication by combining a dual-token binding mechanism with zero-knowledge proofs.

[0005] This application mainly includes the following aspects:

[0006] In a first aspect, embodiments of this application provide an authentication system, comprising: a client, a token issuing end, and an authentication end; the client is communicatively connected to both the token issuing end and the authentication end; wherein...

[0007] The client is configured to determine, based on its identity key pair and identity permissions, an identity binding commitment, a token binding commitment, a structured message code, and a first proof, and send these to the token issuing end. The first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment. The client receives its master token returned by the token issuing end and generates a binding token based on the master token, the client's identity key pair, and identity permissions. The client sends the master token and the binding token to the authentication end. The binding token includes a second proof and a third proof. The second proof proves the binding relationship between the client and the master token, and the third proof proves that the client's identity permissions satisfy the usage permissions of the master token.

[0008] The token issuing terminal is used to verify the validity of the first proof based on the client's public key, and after the verification is successful, to generate the client's master token based on the issuer key pair of the token issuing terminal and the structured message encoding; the issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group;

[0009] The authentication terminal is used to verify the validity of the client's identity based on the client's master token and binding token.

[0010] Secondly, embodiments of this application also provide an authentication method applied to a client of the authentication system described above, the authentication method comprising:

[0011] Based on the client's identity key pair and identity permissions, the client's identity binding commitment, token binding commitment, structured message encoding, and first proof are determined; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment.

[0012] The client's identity binding commitment, token binding commitment, structured message encoding, and first proof are sent to the token issuing end, so that the token issuing end can verify the validity of the first proof based on the client's public key. After successful verification, the token issuing end generates the client's master token based on the token issuing end's issuer key pair and the structured message encoding. The issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group.

[0013] The system receives the client's master token returned by the token issuing terminal, and generates a binding token for the client based on the master token, the client's identity key pair, and identity permissions. The binding token includes a second proof and a third proof. The second proof is used to prove the binding relationship between the client and the master token, and the third proof is used to prove that the client's identity permissions satisfy the usage permissions of the master token.

[0014] The master token and the binding token are sent to the authentication terminal so that the authentication terminal can verify the validity of the client's identity based on the client's master token and binding token.

[0015] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory through the bus, and the machine-readable instructions are executed by the processor to perform the steps of the authentication method as described above.

[0016] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the authentication method described above.

[0017] This application provides an authentication system, method, electronic device, and readable storage medium. The system includes a client, a token issuing end, and an authentication end. The client is communicatively connected to both the token issuing end and the authentication end. The client determines its identity binding commitment, token binding commitment, structured message encoding, and first proof based on its identity key pair and identity permissions, and sends these to the token issuing end. The first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment. The client receives its master token returned by the token issuing end and, based on the master token and the client's identity key pair... The system generates a client-side binding token based on a key pair and identity permissions. The master token and binding token are then sent to the authentication end. The binding token includes a second proof and a third proof. The second proof demonstrates the binding relationship between the client and the master token, while the third proof demonstrates that the client's identity permissions satisfy the master token's usage permissions. The token issuing end verifies the validity of the first proof based on the client's public key. Upon successful verification, it generates the client's master token based on the issuer's key pair and structured message encoding. The issuer's key pair and the identity key pair are generated using generators from the same elliptic curve group. The authentication end verifies the validity of the client's identity based on the client's master token and binding token. This combination of a dual-token binding mechanism and zero-knowledge proofs improves the accuracy of publicly verifiable anonymous token authentication.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This paper shows a schematic diagram of the structure of an identity verification system provided in an embodiment of this application;

[0021] Figure 2 A flowchart of an authentication method provided by an embodiment of this application is shown;

[0022] Figure 3 A flowchart of another authentication method provided by an embodiment of this application is shown;

[0023] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.

[0026] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of an identity verification system provided in an embodiment of this application. Figure 1 As shown in the figure, the authentication system 100 provided in this application embodiment includes: a client 110, a token issuing terminal 120, and an authentication terminal 130. Specifically, the client 110 is communicatively connected to both the token issuing terminal 120 and the authentication terminal 130.

[0027] Client 110 is used to determine the client 110's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client 110's identity key pair and identity permissions, and send the client 110's identity binding commitment, token binding commitment, structured message encoding, and first proof to token issuing terminal 120; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment; receive the client 110's main token returned by token issuing terminal 120, and generate the client 110's binding token based on the main token, the client 110's identity key pair, and identity permissions; send the main token and binding token to authentication terminal 130; the binding token includes a second proof and a third proof; the second proof is used to prove the binding relationship between the client 110 and the main token, and the third proof is used to prove that the client 110's identity permissions satisfy the main token's usage permissions.

[0028] In this embodiment, the client 110 first generates an identity binding commitment based on its own identity key pair and identity permissions. Token binding commitment Structured message coding And the first proof Among them, client 110 possesses an identity key pair. The identity key pair includes the client's private key. and client public key Client private key and client public key It is based on a preset elliptic curve group. generator The settings are used for signature and encryption operations during the authentication process, where, Identity binding commitment Used to bind client identity to a token, structured message encoding First proof of client identity information and permission requirements This is used to prove to the token issuer, through zero-knowledge proof (ZKP), that the client knows and agrees to the identity-bound commitment. The client private key of the corresponding identity key pair The entire process requires no disclosure of private key information, ensuring the security and privacy of identity verification. Subsequently, the client 110 binds its identity to the commitment. Token binding commitment Structured message coding And the first proof Send it to token issuer 120 so that token issuer 120 can verify the identity and permissions of client 110 and generate a master token. (Public Token), Master Token The token is issued by the token issuer 120 using a public signature algorithm and can be verified by any authentication terminal 130, ensuring the token's public verifiability. During this process, the client 110 does not need to reveal its true identity information, only providing cryptographic proof, thus guaranteeing the anonymity of the client 110. When the client 110 receives the master token returned by the token issuer 120... Then, client 110 based on the master token The client 110 generates a binding token using its own identity key pair and identity permissions. This binding token is a non-interactive zero-knowledge proof generated by the client 110 during the client redemption phase, proving that the client 110 holds the client private key bound to the main token. Furthermore, since client 110's identity and permissions satisfy the usage permissions of the master token, authentication terminal 130 can verify the legitimacy of client 110 holding the token without establishing a communication connection with token issuing terminal 120. The bound token includes a second proof. and third proof Second proof Used to prove to authentication terminal 130 that client 110 is associated with the master token The binding relationship, third proof Used to prove that client 110's identity and permissions meet the master token requirements. Access permissions; finally, client 110 will grant the master token. The binding token is sent to the authentication end 130 for authentication.

[0029] The token issuer 120 is used to verify the validity of the first proof based on the client's public key, and after the verification is successful, it generates the main token of the client 110 based on the issuer key pair and the structured message encoding of the token issuer 120; the issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group.

[0030] In this embodiment, the token issuing terminal 120 possesses the issuer key pair. The issuer key pair includes the issuer's private key. and the issuer's public key issuer's private key and the issuer's public key Based on the same elliptic curve group as the identity key pair of client 110 generator The settings are used for signature and encryption operations during the authentication process, where, The token issuer 120 first utilizes the elliptic curve group shared with the client 110. generator For the client's public key With the first proof Perform a consistency verification to confirm that client 110 does indeed possess the commitment bound to the identity. Corresponding client private key After successful verification, the token issuer 120 uses its own issuer private key. Encoding of structured messages Perform a signature to generate a master token containing the client's identity and permissions. The token issuance is completed. This process does not require the client's private key. This ensures both the credibility of the token's origin and the anonymity of the client 110.

[0031] The authentication terminal 130 is used to verify the validity of the identity of client 110 based on the master token and binding token of client 110.

[0032] In this embodiment, the authentication terminal 130, based on the main token and binding token of the client 110, can verify the legitimacy of the client 110's identity and the compliance of its permissions through zero-knowledge proof without interacting with the token issuing terminal 120. This achieves the public verifiability of anonymous tokens, improves the accuracy of authentication, and enhances the system's flexibility and scalability.

[0033] Furthermore, identity permissions include token usage restrictions and token time window restrictions; when client 110 determines client 110's identity binding commitment, token binding commitment, structured message encoding, and first proof based on client 110's identity key pair and identity permissions, client 110 specifically uses the following methods:

[0034] Based on the client's private key and the generator of the elliptic curve group in the identity key pair, the identity binding commitment and token binding commitment of client 110 are calculated; the token usage restriction, token time window restriction, client public key, identity binding commitment and token binding commitment are concatenated and encoded in a preset order to obtain the structured message encoding of client 110; based on the first random number, the generator of the elliptic curve group, the identity binding commitment, the secure hash function and the non-interactive zero-knowledge proof algorithm, the first challenge value and the first response value are calculated, and the first challenge value and the first response value are determined as the first proof of client 110.

[0035] In this embodiment, client 110 uses the client private key in the identity key pair. and elliptic curve group generator Constructing identity binding commitment Token binding commitment This binds the client's identity to the token. Client 110's identity permissions include restrictions on token usage. and token time window limit Restrict the use of tokens Token time window limit Client public key Identity binding commitment Commitment to binding tokens Fields are concatenated and encoded according to a preset order to obtain the structured message encoding for client 110. This restricts the use of tokens. Token time window limit Explicitly adding this information to the signature field enables attribute binding and tamper-proofing of the token, facilitating timeliness control and usage limitation. Next, a non-interactive zero-knowledge proof algorithm is used to generate a non-interactive zero-knowledge proof (NIZK), i.e., the first proof. To prove that client 110 "knows" , making and "This means that the client is aware of and committed to identity binding." The client private key of the corresponding identity key pair Specifically, first select the first random number. Calculate commitment Calculate the first challenge value ,in, A secure hash function (Cryptographic Hash Function) is used to compress input data of arbitrary length into a fixed-length hash value; it also calculates the first response value. The first proof was obtained. .

[0036] Furthermore, when the token issuer 120 is used to verify the validity of the first proof based on the client's public key, the token issuer 120 is specifically used for:

[0037] Based on the client's public key, the generator of the elliptic curve group, the identity binding commitment, the first challenge value and the first response value in the first proof, the first challenge value is reconstructed; the reconstructed first challenge value is compared with the first challenge value in the first proof; if the reconstructed first challenge value is equal to the first challenge value in the first proof, then the first proof is determined to be valid.

[0038] In this embodiment of the application, the token issuing terminal 120 receives... Then, the first challenge value is reconstructed. To verify the first proof Whether it holds true. Specifically, recalculate. Calculate the first challenge value after reconstruction. ,verify Is it true? If so... The first proof is valid, indicating that client 110 knows about the... and corresponding .

[0039] Furthermore, when generating the master token for client 110 based on the issuer key pair and structured message encoding of token issuer 120, token issuer 120 specifically performs the following functions:

[0040] The message digest of client 110 is calculated based on the structured message encoding and the secure hash function; the master token of client 110 is determined based on the second random number, the generator of the elliptic curve group, the structured message encoding, the message digest, the issuer's private key in the issuer key pair, and the structured signature algorithm.

[0041] In this embodiment, the token issuing terminal 120 issues tokens using a structured signature algorithm, first calculating the message digest. Select random numbers Calculate token issuance commitment Computational token issuance challenge Calculate the token issuance response Obtain the master token from client 110. .

[0042] Furthermore, when generating a binding token for client 110 based on the master token, client 110's identity key pair, and identity permissions, client 110 specifically uses the following methods:

[0043] Based on the third random number, the generator of the elliptic curve group, the identity binding commitment, the token binding commitment, the secure hash function, and the discrete logarithm equality zero-knowledge proof algorithm, the second challenge value and the second response value are calculated and determined as the second proof of client 110. The matching relationship between the identity key pair and the identity binding commitment, the matching relationship between the master token and the structured message encoding, and the matching relationship between the identity permissions of client 110 and the usage permissions of the master token are encoded into the zero-knowledge proof circuit, and the zero-knowledge concise non-interactive knowledge proof algorithm is used to compile the zero-knowledge proof circuit to obtain the third proof of client 110. The second proof and the third proof are determined as the binding token of client 110.

[0044] In this embodiment, client 110 constructs two parallel proofs. First, client 110 generates a zero-knowledge binding proof, i.e., the second proof, using the Discrete-Logarithm Equality (DLEQ) zero-knowledge proof algorithm. , used to prove " ,Right now Commitment to Token Binding "Binding". Specifically, select a second random number. Calculate commitment , Calculate the second challenge value Calculate the second response value A second proof was obtained. Next, client 110 binds the identity key pair and token to the commitment. Matching relationship, master token and structured message encoding The matching relationship, as well as the client 110's identity permissions and master token. The matching relationship of usage permissions is encoded into a zero-knowledge circuit (ZKC), which is a specialized structure that transforms the "statement to be proved" into a computable Boolean or arithmetic circuit to facilitate the generation and verification of proofs using a zero-knowledge proof algorithm. Next, the zero-knowledge proof circuit is compiled using the zero-knowledge succinct non-interactive argument of knowledge (zkSNARK) algorithm to obtain the third proof for client 110. Specifically, the third proof As a zero-knowledge property proof, it is used to prove that "the client knows..." satisfy and ;sign To Structured signature; current time at Within the scope and meet the purpose The construction process is as follows: constrain " ; ;sign , ; Matches the current context; "The code is used to enter the zero-knowledge proof circuit, which is then compiled using zkSNARK to generate a third proof." The second proof and third proof It was determined to be the binding token of client 110.

[0045] Furthermore, when verifying the validity of the client 110's identity based on the client 110's master token and binding token, the authentication terminal 130 specifically performs the following functions:

[0046] Based on structured message encoding and structured signature algorithms, the validity of the main token of client 110 is verified. The second challenge value is reconstructed based on the client's public key, the generator of the elliptic curve group, the identity binding commitment, the token binding commitment, the second challenge value in the second proof, and the second response value. The reconstructed second challenge value is compared with the second challenge value in the second proof to verify the validity of the second proof. The validity of the third proof is verified based on the common input part of the structured message encoding, the pre-published public reference string of the zero-knowledge concise non-interactive knowledge proof algorithm, and the zero-knowledge proof circuit description. If both the second and third proofs of the main token and the binding token are valid, then the identity of client 110 is determined to be valid.

[0047] In this embodiment, the authentication terminal 130 independently completes three verifications: first, using structured message encoding... Verify the master token with the structured signature algorithm The authenticity of the data; and then the elliptic curve group. generator Identity binding commitment Token binding commitment and the second proof The second challenge value With the second response value Reconstruct the second challenge value; if they match, it confirms that client 110 and the master token are compatible. The binding is correct; then, according to the structured message encoding... Given the public input, a pre-published Common Reference String (CRS), and a zero-knowledge proof circuit description, run a concise, non-interactive zero-knowledge proof algorithm to verify the third proof. The validity of the message digest is determined; if all three criteria are met, the client 110's identity is deemed valid, requiring no interaction with the token issuer 120 throughout the process, thus achieving anonymous yet publicly verifiable identity verification. Specifically, the message digest is first calculated. Reconstruct token issuance challenge value Check the signature equation To determine if the statement is valid, verify the master token. Is a structured signature an encoding of a structured message? A valid signature. Next, calculate... , Calculate the second challenge value after reconstruction. ,verify Whether it is true or not, to determine the second proof Whether the DLEQ binding relationship holds. Finally, using the pre-published CRS (public reference string) and circuit description from zkSNARK, a third proof is used. and structured message encoding Public input, verification Is this a valid proof of zkSNARK based on the agreed circuit? If all verifications pass, it means that the anonymous token of client 110 was indeed issued by the corresponding token issuing terminal 120, and client 110 is consistent with its bound identity. The token's time limit is within the valid range, and the token's usage restriction meets the intended purpose. Therefore, the anonymous token can be used legally, allowing the user to access the corresponding resources.

[0048] In one possible implementation, the master token of client 110 is embedded with a revocation handle; client 110 is also used to, after receiving the master token of client 110 returned by token issuer 120, in response to the user's token revocation operation, sign the master token identifier of client 110 using the client private key in the identity key pair, generate a token denial statement of client 110, and send the token denial statement to token issuer 120.

[0049] The token issuer 120 is also used to add the revocation handle of the client 110's master token to the public token revocation list based on a token rejection statement.

[0050] The authentication terminal 130 is also used to query the publicly available token revocation list before verifying the master token and binding token of the client 110; if the revocation handle of the master token of the client 110 exists in the token revocation list, it is determined that the master token of the client 110 has been revoked, and authentication of the client 110 is refused.

[0051] In this embodiment of the application, to enhance the controllability and security of the system, the solution embeds a revocation handle in the main token structure. Will cancel handle The field is incorporated into the structured signature field, i.e., the master token. Client 110 may wish to proactively refuse to use a master token it already holds. A token rejection statement can be constructed as a signature proof, i.e., by the client 110 based on the unique token identifier, i.e., the main token identifier. With client private key The token is signed and submitted to the token issuer 120. After verifying the signature, the token issuer 120 can issue the revocation handle corresponding to the token. Add to undo list This implements a user-controllable token revocation mechanism. In this embodiment, the token issuing terminal 120 maintains a publicly available token revocation list. A revocation handle used to issue revoked tokens. Before verifying the token, authentication terminal 130 first checks the master token. In The system checks whether the request is valid. If valid, the token is deemed revoked and the verification request is rejected; otherwise, the normal verification process continues. This mechanism does not expose the client's real identity and does not affect the master token. With the anonymity and zero-knowledge proof structure of the bound token, it can provide practical and feasible token revocation control capabilities under the premise of anonymity protection, and is suitable for typical scenarios such as prevention of malicious abuse, voluntary abandonment by users, and access failure.

[0052] This application provides an authentication system, including a client, a token issuing end, and an authentication end. The client is communicatively connected to both the token issuing end and the authentication end. The client determines its identity binding commitment, token binding commitment, structured message encoding, and a first proof based on its identity key pair and identity permissions, and sends these to the token issuing end. The first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment. The client receives its master token returned by the token issuing end and generates an authentication system based on the master token, the client's identity key pair, and identity permissions. The client generates a binding token; the master token and binding token are sent to the authentication end; the binding token includes a second proof and a third proof; the second proof proves the binding relationship between the client and the master token, and the third proof proves that the client's identity permissions satisfy the master token's usage permissions; the token issuing end verifies the validity of the first proof based on the client's public key, and after successful verification, generates the client's master token based on the issuer key pair and structured message encoding; the issuer key pair and the identity key pair are generated based on the same elliptic curve group generator; the authentication end verifies the validity of the client's identity based on the client's master token and binding token. Thus, by combining the dual-token binding mechanism with zero-knowledge proofs, the accuracy of publicly verifiable anonymous token authentication is improved.

[0053] Based on the same application concept, this application also provides an authentication method corresponding to the authentication system provided in the above embodiments. Since the principle of the method in this application is similar to that of the authentication system in the above embodiments of this application, the implementation of the method can refer to the implementation of the system, and the repeated parts will not be described again.

[0054] The authentication method provided in this application embodiment is applied to the client 110 of the authentication system 100 provided in the above embodiment. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating an authentication method provided in an embodiment of this application. Figure 2 As shown, the authentication methods include:

[0055] S201, the client determines the client's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client's identity key pair and identity binding commitment; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment.

[0056] S202, the client sends its identity binding commitment, token binding commitment, structured message encoding, and first proof to the token issuer.

[0057] S203, the token issuing end receives the client's identity binding commitment, token binding commitment, structured message encoding, and first proof sent by the client.

[0058] S204, the token issuer verifies the validity of the first proof based on the client's public key, and after successful verification, generates the client's master token based on the issuer key pair and structured message encoding of the token issuer; the issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group.

[0059] S205, the token issuer sends the client's master token to the client.

[0060] S206, The client receives the client's master token sent by the token issuer.

[0061] S207, the client generates a binding token based on the master token, the client's identity key pair, and identity permissions; the binding token includes a second proof and a third proof; the second proof is used to prove the binding relationship between the client and the master token, and the third proof is used to prove that the client's identity permissions satisfy the use permissions of the master token.

[0062] S208, the client sends the master token and binding token to the authentication end.

[0063] S209, the authentication terminal receives the master token and binding token sent by the client.

[0064] S210, the authentication end verifies the validity of the client's identity based on the client's master token and binding token.

[0065] In one possible implementation, a revocation handle is embedded in the master token of client 110. See also... Figure 3 , Figure 3 A flowchart illustrating another authentication method provided in an embodiment of this application. Figure 3 As shown, the authentication methods also include:

[0066] S301, the client determines the client's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client's identity key pair and identity binding commitment; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment.

[0067] S302, the client sends its identity binding commitment, token binding commitment, structured message encoding, and first proof to the token issuer.

[0068] S303, the token issuing end receives the client's identity binding commitment, token binding commitment, structured message encoding, and first proof sent by the client.

[0069] S304, the token issuer verifies the validity of the first proof based on the client's public key, and after successful verification, generates the client's master token based on the issuer key pair and structured message encoding of the token issuer; the issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group.

[0070] S305, the token issuer sends the client's master token to the client.

[0071] S306, The client receives the client's master token sent by the token issuer.

[0072] S307, in response to the user's token revocation operation, the client signs the client's master token identifier using the client's private key in the identity key pair, generating the client's token denial statement.

[0073] S308, the client sends a token rejection statement to the token issuer.

[0074] S309, the token issuer receives a token rejection statement sent by the client.

[0075] S310, the token issuer adds the revocation handle of the client's master token to the public token revocation list.

[0076] S311, the client generates a binding token based on the master token, the client's identity key pair, and identity permissions; the binding token includes a second proof and a third proof; the second proof is used to prove the binding relationship between the client and the master token, and the third proof is used to prove that the client's identity permissions satisfy the use permissions of the master token.

[0077] S312, the client sends the master token and binding token to the authentication end.

[0078] S313, the authentication end receives the master token and binding token sent by the client.

[0079] S314, the authentication end queries the publicly available token revocation list.

[0080] S315, if the client's master token revocation handle exists in the token revocation list, the authentication end determines that the client's master token has been revoked and refuses to authenticate the client.

[0081] S316 If the client's master token revocation handle does not exist in the token revocation list, the authentication end verifies the validity of the client's identity based on the client's master token and bound token.

[0082] This application provides an authentication method applied to a client of an authentication system. The method includes: determining the client's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client's identity key pair and identity permissions; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment; sending the client's identity binding commitment, token binding commitment, structured message encoding, and first proof to a token issuing end, so that the token issuing end verifies the validity of the first proof based on the client's public key, and after successful verification, generating the client's master token based on the token issuing end's issuer key pair and structured message encoding; the issuer key pair and the identity key pair are generated based on the same elliptic curve group generator; receiving the client's master token returned by the token issuing end, and generating the client's binding token based on the master token, the client's identity key pair, and identity permissions; the binding token includes a second proof and a third proof; the second proof is used to prove the binding relationship between the client and the master token, and the third proof is used to prove that the client's identity permissions satisfy the use permissions of the master token; sending the master token and binding token to an authentication end, so that the authentication end verifies whether the client's identity is valid based on the client's master token and binding token. In this way, the accuracy of publicly verifiable anonymous token authentication is improved by combining the dual-token binding mechanism with zero-knowledge proofs.

[0083] Based on the same application concept, please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0084] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 and the memory 420 communicate through the bus 430. The machine-readable instructions are executed by the processor 410 to perform the steps of the authentication method provided in the above embodiment. For specific implementation details, please refer to the method embodiment, which will not be repeated here.

[0085] Based on the same concept, this application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it executes the steps of the authentication method provided in the above embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0087] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0089] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0091] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0092] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. An identity verification system, characterized in that, The authentication system includes: a client, a token issuing terminal, and an authentication terminal; the client is communicatively connected to both the token issuing terminal and the authentication terminal; wherein... The client is configured to determine, based on its identity key pair and identity permissions, an identity binding commitment, a token binding commitment, a structured message encoding, and a first proof, and send these commitments to the token issuing end. The identity key pair includes a client private key and a client public key. The identity permissions include token usage restrictions and token time window restrictions. The first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment. The client receives its master token returned by the token issuing end and generates a binding token based on the master token, the client's identity key pair, and identity permissions. The client sends the master token and the binding token to the authentication end. The binding token includes a second proof and a third proof. The second proof proves the binding relationship between the client and the master token, and the third proof proves that the client's identity permissions satisfy the usage permissions of the master token. The token issuing terminal is used to verify the validity of the first proof based on the client's public key, and after the verification is successful, to generate the client's master token based on the issuer key pair of the token issuing terminal and the structured message encoding; the issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group; The authentication terminal is used to verify whether the client's identity is valid based on the client's master token and binding token; Specifically, when the client is used to determine the client's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client's identity key pair and identity permissions, the client is used to: Based on the client's private key in the identity key pair and the generator of the elliptic curve group, the client's identity binding commitment and token binding commitment are calculated; the token usage restriction, the token time window restriction, the client's public key, the identity binding commitment, and the token binding commitment are concatenated and encoded in a preset order to obtain the client's structured message encoding; based on a first random number, the generator of the elliptic curve group, the identity binding commitment, a secure hash function, and a non-interactive zero-knowledge proof algorithm, a first challenge value and a first response value are calculated, and the first challenge value and the first response value are determined as the client's first proof.

2. The identity verification system according to claim 1, characterized in that, When the token issuing terminal is used to verify the validity of the first proof based on the client's public key, the token issuing terminal is specifically used for: Based on the client public key, the generator of the elliptic curve group, the identity binding commitment, the first challenge value and the first response value in the first proof, the first challenge value is reconstructed; the reconstructed first challenge value is compared with the first challenge value in the first proof. If the reconstructed first challenge value is equal to the first challenge value in the first proof, then the first proof is determined to be valid.

3. The identity verification system according to claim 1, characterized in that, When the token issuing terminal generates the client's master token based on the issuer key pair and the structured message encoding, the token issuing terminal is specifically used for: The message digest of the client is calculated based on the structured message encoding and the secure hash function; the master token of the client is determined based on the second random number, the generator of the elliptic curve group, the structured message encoding, the message digest, the issuer's private key in the issuer key pair, and the structured signature algorithm.

4. The identity verification system according to claim 3, characterized in that, When the client generates a binding token for the client based on the master token, the client's identity key pair, and identity permissions, the client is specifically used for: Based on the third random number, the generator of the elliptic curve group, the identity binding commitment, the token binding commitment, the secure hash function, and the discrete logarithm equal zero-knowledge proof algorithm, the second challenge value and the second response value are calculated, and the second challenge value and the second response value are determined as the second proof of the client. The matching relationship between the identity key pair and the identity binding commitment, the matching relationship between the master token and the structured message encoding, and the matching relationship between the client's identity permissions and the master token's usage permissions are encoded into a zero-knowledge proof circuit, and the zero-knowledge concise non-interactive knowledge proof algorithm is used to compile the zero-knowledge proof circuit to obtain the client's third proof; The second proof and the third proof are determined as the binding token of the client.

5. The identity verification system according to claim 4, characterized in that, When the authentication terminal is used to verify the validity of the client's identity based on the client's master token and binding token, the authentication terminal is specifically used for: Based on the structured message encoding and the structured signature algorithm, verify whether the client's master token is valid; based on the client's public key, the generator of the elliptic curve group, the identity binding commitment, the token binding commitment, the second challenge value and the second response value in the second proof, reconstruct the second challenge value; compare the reconstructed second challenge value with the second challenge value in the second proof to verify whether the second proof is valid; based on the common input part of the structured message encoding and the pre-published public reference string and zero-knowledge proof circuit description of the zero-knowledge concise non-interactive knowledge proof algorithm, verify whether the third proof is valid; If the second and third proofs of the master token and the binding token are both valid, then the client's identity is determined to be valid.

6. The identity verification system according to claim 1, characterized in that, The client's master token has an embedded revocation handle; the client is also used to, after receiving the client's master token returned by the token issuing end, respond to the user's token revocation operation, sign the client's master token identifier using the client's private key in the identity key pair, generate the client's token denial statement, and send the token denial statement to the token issuing end; The token issuing terminal is also used to add the revocation handle of the client's master token to a public token revocation list based on the token rejection statement; The authentication terminal is also used to query the publicly available token revocation list before verifying the client's master token and binding token; If the revocation handle of the client's master token exists in the token revocation list, then it is determined that the client's master token has been revoked, and authentication of the client is refused.

7. An authentication method, characterized in that, The authentication method, applied to a client of any of the authentication systems described in claims 1-6, comprises: Based on the client's identity key pair and identity permissions, the client's identity binding commitment, token binding commitment, structured message encoding, and first proof are determined; the identity key pair includes the client's private key and client's public key; the identity permissions include token usage restrictions and token time window restrictions; the first proof is used to prove the binding relationship between the identity key pair and the identity binding commitment; The client's identity binding commitment, token binding commitment, structured message encoding, and first proof are sent to the token issuing end, so that the token issuing end can verify the validity of the first proof based on the client's public key. After successful verification, the token issuing end generates the client's master token based on the token issuing end's issuer key pair and the structured message encoding. The issuer key pair and the identity key pair are generated based on the same generator of the elliptic curve group. The system receives the client's master token returned by the token issuing terminal, and generates a binding token for the client based on the master token, the client's identity key pair, and identity permissions. The binding token includes a second proof and a third proof. The second proof is used to prove the binding relationship between the client and the master token, and the third proof is used to prove that the client's identity permissions satisfy the usage permissions of the master token. The master token and the binding token are sent to the authentication terminal so that the authentication terminal can verify the validity of the client's identity based on the client's master token and binding token; The step of determining the client's identity binding commitment, token binding commitment, structured message encoding, and first proof based on the client's identity key pair and identity permissions includes: Based on the client's private key in the identity key pair and the generator of the elliptic curve group, the client's identity binding commitment and token binding commitment are calculated; The token usage restriction, the token time window restriction, the client public key, the identity binding commitment, and the token binding commitment are concatenated and encoded in a preset order to obtain the structured message encoding of the client; Based on the first random number, the generator of the elliptic curve group, the identity binding commitment, the secure hash function, and the non-interactive zero-knowledge proof algorithm, the first challenge value and the first response value are calculated, and the first challenge value and the first response value are determined as the first proof of the client.

8. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the machine-readable instructions are executed by the processor to perform the steps of the authentication method as described in claim 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the authentication method as described in claim 7.

Images