Identity attribute verification method, device and storage medium

Abstract

This application provides an identity attribute verification method, device, and storage medium. The method includes: obtaining a first hash value corresponding to the target identity attribute information that needs to be verified to access the target service; querying the hash values ​​of other users with the same identity attribute description from the blockchain network, and randomly selecting a preset number of second hash values ​​from them; randomly sorting the second hash values ​​and the first hash values ​​to construct an anonymous set; obtaining the blockchain transaction identifier corresponding to each hash value in the anonymous set; generating a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymous set; and sending the blockchain transaction identifier and the zero-knowledge proof as proof credentials to the service provider, so that the service provider can verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether the client is authorized to access the target service. This can effectively prevent the leakage and tracing of user identity information and access behavior.

Description

Technical Field

[0001] This application relates to the field of identity verification technology, and in particular to an identity attribute verification method, device and storage medium. Background Technology

[0002] Due to compliance and regulatory requirements, as well as service security needs, many online services only grant access to users who meet specific criteria (such as being 18 years of age or older, or possessing a master's degree or higher). Therefore, when a user accesses a service, they typically need to prove to the service provider that they meet the corresponding attribute conditions.

[0003] However, in existing decentralized identity systems, users often directly disclose complete attribute values ​​(such as specific birth dates or degree names) to service providers, rather than merely proving that they meet the required conditions. This violates the principle of least disclosure in privacy protection and increases the risk of leakage and misuse of sensitive user information. Furthermore, in such decentralized identity systems, the identity credentials submitted by users across different sessions are usually fixed, allowing service providers to associate multiple requests with the same user based on the credential content, thereby compromising user anonymity and session non-linkability.

[0004] Therefore, there is an urgent need for an identity attribute verification scheme that can both protect user privacy and achieve session non-linkability. Summary of the Invention

[0005] This application provides an identity attribute verification method, device, and storage medium, which can prove to the verification end that the corresponding target identity attribute meets the access conditions of the target service without revealing the specific value of the target identity attribute and the user's real identity, while realizing the non-linkability between different sessions.

[0006] In a first aspect, embodiments of this application provide an identity attribute verification method applied to a client, the method comprising: In response to a user-triggered access request to a target service, a first hash value corresponding to the target identity attribute information required for the user to access the target service is obtained; the first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description. The system queries the blockchain network for hash values ​​of other users whose identity attributes are identical to the first hash value, and randomly selects a preset number of second hash values ​​from the hash values ​​and randomly sorts them with the first hash value to construct an anonymous set. Obtain the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network; Based on the target identity attribute information, the identity attribute description, and the anonymous set, a zero-knowledge proof is generated; the zero-knowledge proof is used to prove that the target identity attribute information satisfies the target service access conditions without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set. The blockchain transaction identifier and the zero-knowledge proof are sent to the service provider corresponding to the target service, so that the service provider can obtain the anonymity set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value in the anonymity set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service.

[0007] Secondly, embodiments of this application provide an identity attribute verification device applied to a client, the device comprising: The response module is used to respond to a user-triggered access request to a target service and obtain a first hash value corresponding to the target identity attribute information that the user needs to verify to access the target service; the first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description. The construction module is used to query the hash values ​​of other users with the same identity attribute description from the blockchain network, and randomly select a preset number of second hash values ​​from the hash values ​​and randomly sort them with the first hash values ​​to construct an anonymous set; The acquisition module is used to acquire the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network; The generation module is used to generate a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymity set; the zero-knowledge proof is used to prove that the target identity attribute information satisfies the target service access conditions without disclosing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymity set; The sending module is used to send the blockchain transaction identifier and the zero-knowledge proof to the service provider corresponding to the target service, so that the service provider can obtain the anonymity set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value in the anonymity set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service.

[0008] Thirdly, embodiments of this application provide an electronic device applied to a client, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the identity attribute verification method as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the identity attribute verification method as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the identity attribute verification method as described in the first aspect.

[0011] Sixthly, embodiments of this application provide an identity attribute verification method, applied to a service provider, the method comprising: Receive the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set sent by the client; Based on the blockchain transaction identifier, the anonymous set is obtained from the blockchain network; Verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether the client is authorized to access the target service; Wherein, the hash value is an identity credential generated by the identity provider based on the identity attribute information and its corresponding identity attribute description required for accessing the target service. The anonymous set is constructed by randomly selecting a preset number of second hash values ​​from the hash values ​​of other users with the same identity attribute description found in the blockchain network and randomly sorting them with the user's first hash value. The zero-knowledge proof is generated based on the user's target identity attribute information, the identity attribute description, and the anonymous set. It is used to prove that the target identity attribute information meets the access conditions of the target service without disclosing the specific value of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

[0012] Seventhly, embodiments of this application provide an identity attribute verification device, applied to a service provider, the device comprising: The receiving module is used to receive the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set sent by the client; The acquisition module is used to obtain the anonymous set from the blockchain network based on the blockchain transaction identifier; The verification module is used to verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof, so as to confirm whether the client is authorized to access the target service; Wherein, the hash value is an identity credential generated by the identity provider based on the identity attribute information and its corresponding identity attribute description required for accessing the target service. The anonymous set is constructed by randomly selecting a preset number of second hash values ​​from the hash values ​​of other users with the same identity attribute description found in the blockchain network and randomly sorting them with the user's first hash value. The zero-knowledge proof is generated based on the user's target identity attribute information, the identity attribute description, and the anonymous set. It is used to prove that the target identity attribute information meets the access conditions of the target service without disclosing the specific value of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

[0013] Eighthly, this application provides an electronic device for use in a verification terminal, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the identity attribute verification method as described in the sixth aspect.

[0014] In a ninth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the identity attribute verification method as described in the sixth aspect.

[0015] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the identity attribute verification method as described in the sixth aspect.

[0016] In the identity attribute verification scheme provided in this application embodiment, it can be applied to the client to generate a proof credential to prove to the service provider that the target identity attribute meets the access conditions of the target service. Based on the proof credential, the service provider verifies whether the user's target identity attribute meets the access conditions of the target service, so as to determine whether to authorize the client to access the target service.

[0017] In practice, firstly, in response to a user-triggered access request to the target service, the system obtains the first hash value corresponding to the target identity attribute information that the user needs to verify to access the target service. This first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description. Next, the system queries the blockchain network for hash values ​​of other users whose identity attribute descriptions are identical to the target identity attribute information, and randomly selects a predetermined number of second hash values ​​from the retrieved hash values. These predetermined number of second hash values ​​and the user's first hash value are combined and randomly sorted to construct an anonymous set. This anonymous set contains hash values ​​arranged in a randomly shuffled manner to hide the position of the first hash value within it. Then, the system obtains the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network. Finally, based on the target identity attribute information, the identity attribute description, and the anonymous set, a zero-knowledge proof is generated. This zero-knowledge proof is used to prove, without revealing the specific values ​​of the target identity attribute information, that the target identity attribute information meets the access conditions for the target service, and that the first hash value is hidden within the anonymous set. Finally, the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set are sent as proof credentials to the service provider. This enables the service provider to obtain the anonymous set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value and the zero-knowledge proof in the anonymous set to confirm whether to authorize the client to access the target service.

[0018] In the above scheme, each time a user accesses the target service, a preset number of second hash values ​​are randomly selected from the hash values ​​of all users with the same identity attribute description as the target identity attribute information to be verified. These second hash values ​​are then combined with the user's first hash value and randomly sorted to dynamically construct an anonymous set. This not only hides the position of the user's first hash value in the anonymous set, but also ensures that the anonymous set constructed for each access to the target service is different. Therefore, the service provider cannot identify multiple accesses from the same user by comparing the anonymous set or blockchain transaction identifiers, achieving non-linkability between different sessions. Furthermore, when generating proof credentials, zero-knowledge proofs are generated by constructing dynamic anonymous sets and based on the target identity attribute information, identity attribute description, and anonymous sets. This is used to prove to the service provider that the target identity attribute information meets the access conditions of the target service without revealing the specific values ​​of the target identity attribute information or the user's true identity. This achieves anonymous protection of user identity, effectively preventing the leakage and tracing of user identity information and access behavior, while ensuring that the identity verification process is compliant and verifiable. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of an identity verification system provided in an embodiment of this application; Figure 2 A flowchart illustrating an authentication method provided in this application embodiment; Figure 3 A flowchart for generating zero-knowledge proofs is provided as an embodiment of this application; Figure 4 A flowchart illustrating another authentication method provided in this application embodiment; Figure 5 A schematic diagram of the structure of an identity verification device provided in an embodiment of this application; Figure 6 To and Figure 5 A schematic diagram of the electronic device corresponding to the authentication device provided in the illustrated embodiment; Figure 7 A schematic diagram of another authentication device provided in this application embodiment; Figure 8 To and Figure 7 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the authentication device. Detailed Implementation

[0021] 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one. It should be understood that the term “and / or” as used herein is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character “ / ” in this document generally indicates that the preceding and following related objects are in an “or” relationship. Depending on the context, the words “if” or “when” as used herein can be interpreted as “when…” or “when…”.

[0023] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0024] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0025] In traditional decentralized identity systems, users often disclose complete attribute values ​​(such as specific birth dates or degree names) directly to the service provider (SP), rather than merely proving that they meet the required conditions. This violates the principle of least disclosure in privacy protection and increases the risk of sensitive information being leaked and misused.

[0026] Furthermore, in this decentralized identity system, the identity credentials submitted by users across different sessions are typically fixed, allowing service providers (SPs) to associate multiple requests with the same user based on the credential content, thereby compromising user anonymity and session unlinkability. Even more serious is the fact that most current decentralized identity systems rely on classic public-key cryptographic algorithms such as RSA and ECDSA, which are vulnerable to efficient cracking in the face of future quantum computing attacks, making long-term security difficult to guarantee.

[0027] To address the aforementioned technical issues, this application proposes an authentication scheme. In this scheme, each time a user proves to the service provider that they meet the access conditions for the target service, they construct a dynamic anonymous set by mixing and randomly sorting a first hash value representing their identity credential with hash values ​​from other users randomly selected from the blockchain network. This prevents the service provider from associating different authentication sessions of the same user through the composition and sorting of the anonymous set, thus achieving session unlinkability. Furthermore, based on this anonymous set, the user's target identity attribute information, and their corresponding identity attribute descriptions, a zero-knowledge proof is generated. This allows the service provider to verify whether the user truly meets the attribute conditions required for access without obtaining the user's specific identity attributes or real identity.

[0028] The authentication scheme will be illustrated below with reference to the following embodiments.

[0029] Figure 1 This is a schematic diagram of an identity verification system provided in an embodiment of this application. Figure 1 As shown, the identity verification system includes a client, a service provider, an identity provider, and a blockchain network.

[0030] The client can be any device that needs to initiate a target service access request to the service provider, generate a key pair, and construct a zero-knowledge proof to prove identity attributes. Specifically, the client can be a mobile phone, PC, tablet, configuration application, etc. It can also be any device capable of providing computing services, such as a cluster server, regular server, cloud server, cloud host, virtual center, etc.

[0031] The service provider can be any device that receives the client's request to access the target service and verifies the credentials provided by the user to confirm whether the client is authorized to access the target service and to provide the target service. Specifically, the service provider can be a mobile phone, personal computer (PC), tablet computer, configuration application, etc. It can also be any device capable of providing computing services, such as a cluster server, regular server, cloud server, cloud host, virtual data center, etc. Furthermore, both the service provider and the client are equipped with the identity attribute verification device described in this application to perform the corresponding identity attribute verification operation.

[0032] Among them, the identity provider is responsible for verifying the authenticity of the user's identity attribute information, generating a hash value that represents the user's identity certificate, and using a quantum-resistant signature to sign the identity hash value and its corresponding identity attribute description, and transmitting the signature to any device on the blockchain network for on-chain storage.

[0033] In this context, the blockchain network is used to store hash values ​​representing user identity credentials and their corresponding metadata on any device. The metadata includes an identity attribute description corresponding to the hash value, a signature containing the hash value and its corresponding identity attribute description, and the revocation status corresponding to the hash value.

[0034] In practical applications, when a client wants to access a target service provided by a service provider, the user can use the client to trigger an access request for the target service. This allows the client to construct an anonymous set using its authentication device, and generate a zero-knowledge proof based on the anonymous set, the user's target identity attribute information, and their corresponding identity attribute descriptions. The generated zero-knowledge proof, along with the blockchain transaction identifier corresponding to each hash value in the anonymous set, is then sent as proof credentials to the corresponding service provider. Upon receiving the proof credentials, the service provider can use its authentication device to perform the corresponding verification operation to confirm whether the client is authorized to access the target service.

[0035] In practice, the client first responds to a user-triggered access request for a target service by obtaining the first hash value corresponding to the target attribute information required for verification when the user accesses the target service. This first hash value is the identity credential generated by the identity provider based on the user's target identity attribute information and its corresponding identity attribute description. Furthermore, in practical applications, after generating the first hash value corresponding to the target attribute information, the identity provider signs the first hash value and its corresponding identity attribute description, and uploads the signed first hash value and its corresponding identity attribute description to the blockchain network for on-chain storage. This prevents the plaintext leakage of the original identity attribute information and, relying on the immutable and traceable characteristics of the blockchain, ensures the authenticity and integrity of the identity attribute data, preventing unauthorized alteration or forgery.

[0036] The client then queries the blockchain network for hash values ​​of other users whose identity attribute descriptions match the first hash value. From all the retrieved hash values, a preset number of second hash values ​​are randomly selected. The first hash value and the preset number of second hash values ​​are combined and randomly sorted to construct an anonymous set. This hides the user's first hash value within the anonymous set, making it impossible to trace the real user's identity using a single hash value, and also preventing the identification of the user's first hash value from the anonymous set, effectively protecting identity privacy. After constructing the anonymous set, the blockchain transaction identifier corresponding to each hash value in the anonymous set is retrieved from the blockchain network.

[0037] Next, the client generates a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymous set. This zero-knowledge proof proves that the target identity attribute satisfies the target service access conditions without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set. Finally, the client sends the blockchain transaction identifier corresponding to each hash value in the anonymous set and the zero-knowledge proof as proof credentials to the service provider.

[0038] After receiving the proof credentials from the client, the service provider retrieves the corresponding hash value from the blockchain network based on the blockchain transaction identifier in the proof credentials to obtain the corresponding anonymity set. It then verifies the validity of each hash value in the anonymity set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service. Once all verifications pass, the service provider can confirm authorization for the client to access the target service and provide the target service to the user.

[0039] In summary, in this embodiment, when the client proves to the service provider that it meets the attribute conditions for accessing the target service, it does not directly disclose the corresponding target identity attribute information or identity identifier. Instead, it constructs a dynamic temporary anonymous set composed of multiple legitimate users, hiding the corresponding target identity attribute values ​​within this temporary anonymous set. This prevents the service provider from associating different verification sessions of the same user through the composition and order of the anonymous set, thus achieving session unlinkability. Furthermore, by combining zero-knowledge proofs and blockchain technology, the validity of the target identity attribute information is verified while concealing the user's true identity.

[0040] To facilitate understanding of the specific process of identity attribute verification between the client and service provider described above, combined with... Figure 2 The specific process of identity attribute verification performed by the client is illustrated by an example.

[0041] Figure 2 A flowchart illustrating an authentication method provided in this application embodiment; as follows: Figure 2 As shown, this method is applied to the client side, and specifically, the method may include the following steps: 201. In response to a user-triggered access request to the target service, obtain the first hash value corresponding to the target identity attribute information required for the user to access the target service.

[0042] 202. Query the hash values ​​of other users with the same identity attribute description from the blockchain network, and randomly select a preset number of second hash values ​​from the hash values ​​and randomly sort them with the first hash values ​​to construct an anonymous set.

[0043] 203. Obtain the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network.

[0044] 204. Generate a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymous set. The zero-knowledge proof is used to prove that the target identity attribute information satisfies the target service access conditions without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

[0045] 205. Send the blockchain transaction identifier and zero-knowledge proof to the service provider corresponding to the target service, so that the service provider can obtain the anonymous set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service.

[0046] In practical applications, users need to prove to service providers that they possess the corresponding qualifications or permissions. Often, users only need to prove that a certain identity attribute meets specific conditions (such as "age not less than 18 years old" or "credit score higher than a threshold"), without revealing the specific value of that identity attribute, in order to avoid leaking sensitive data and prevent the proofs of the same user in different access sessions from being linked, thus compromising user anonymity. Therefore, in order to prove to the service provider that the target identity attribute possesses the corresponding qualifications or permissions with the principle of minimum disclosure, while better protecting user privacy and achieving session non-linkability, the identity verification scheme provided in this application can be used to submit proof credentials containing scope proof and membership relationship to the service provider, completing condition compliance verification without revealing the original attribute value corresponding to the target identity attribute.

[0047] Before accessing the target service, a user can first generate a corresponding public and private key, and then obtain the corresponding identity credentials from the identity provider based on the user's public key and the target identity attribute information. Specifically, before verifying the target identity attribute information, the user triggers an identity credential request through the client for the target identity attribute information to be verified. The identity credential request includes the user's public key and the target identity attribute information.

[0048] The client forwards the identity credential request to the identity provider, which then verifies the authenticity of the target identity attribute information offline or off-chain. Based on the target identity attribute information, its corresponding identity attribute description, the user's public key, and a randomly generated salt, the identity provider calculates the first hash value. The identity attribute description identifies the semantic type of the proven identity attribute, such as "age" or "education level," ensuring that different identity attributes are not confused.

[0049] For example, suppose a user's target identity attribute information is Priv, and the user's public key is PK. The identity provider obtains the user's proof documents to verify the authenticity of the user's target identity attribute information. After determining the identity attribute description corresponding to the target identity attribute, it generates a random salt value, salt, which is known only to the user and the identity provider. The identity attribute description, random salt value, user's public key, and corresponding target identity attribute information are concatenated, and the concatenation result is hashed to calculate the first hash value, i.e., the first hash value H = Hash(attr||Priv||PK||salt).

[0050] After generating the corresponding first hash value, the identity provider combines the first hash value with its corresponding identity attribute description, signs the combination, and stores the signature result in the blockchain network as an immutable identity credential. Furthermore, to enhance the anti-attack capability of the identity credential in long-term storage and future security environments, in an optional embodiment, the identity provider can use a quantum-resistant digital signature algorithm to sign the combination of the first hash value and its corresponding identity attribute description, and store the signature result in the blockchain network to obtain the corresponding blockchain transaction identifier. Specifically, the quantum-resistant digital signature algorithm can be a standardized algorithm based on lattice cryptography, such as Dilithium, Falcon, or SPHINCS+, to resist potential quantum computing attacks and ensure that the authenticity and integrity of the user's identity credential can still be effectively guaranteed even with the widespread adoption of quantum computers in the future.

[0051] Subsequently, the identity provider returns a random salt value and an identity attribute description to the client via a secure and trusted channel (such as an encrypted communication link). Upon receiving this information, the client can secretly store it so that when the target service accesses the application, it can generate a corresponding zero-knowledge proof based on the random salt value and identity attribute description.

[0052] Based on this, when a user subsequently needs to access the target service, they can initiate an access request using a client and complete privacy-protected authentication based on the obtained first hash value, random salt value, and identity attribute description. Specifically, when a user needs to access a target service provided by a service provider, and accessing the target service requires demonstrating eligibility to the service provider, the user can use a client to trigger an access request for the target service.

[0053] Based on an access request for a target service, the target identity attribute information required for verifying access to the target service can be determined first, and the first hash value corresponding to the target identity attribute information can be obtained from the blockchain network. The target identity attribute information refers to the specific identity attributes that a user needs to use for conditional verification during this verification process. For example, the target identity attribute can be any one of age, income, credit score, nationality, education level, or account status. For example, assume that the target identity attribute information is m[j], and the access condition corresponding to its target service is 18 < age < 45. The user hopes to prove to the verification end that the target identity attribute information 18 < m[j] < 45.

[0054] Among them, the first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description. And in practical applications, after generating the first hash value corresponding to the target attribute information, the identity provider signs the first hash value and its corresponding identity attribute description, and uploads the signed first hash value and its corresponding identity attribute description to the blockchain network for on-chain storage, avoiding the plaintext leakage of the original identity attribute information. At the same time, relying on the immutable and traceable characteristics of the blockchain, it ensures the authenticity and integrity of the identity attribute data, preventing the data from being tampered with or forged privately.

[0055] That is, the first hash value can be used as an immutable and verifiable commitment of the user to this identity attribute on the blockchain, for subsequent membership verification and attribute binding in zero-knowledge proofs.

[0056] In order to achieve the unlinkability of the user's identity and privacy protection in the subsequent identity verification process, after obtaining the first hash value, the hash values of other users with the same identity attribute description corresponding to the target identity attribute information can be queried from the blockchain network first, to randomly select a preset number of second hash values, and randomly sort the preset number of second hash values and the first hash value to construct an anonymous set. That is to say, the hash values in this anonymous set are completely isomorphic in form, all corresponding to the same type of identity attribute (for example, all are the commitment values of the "age" attribute), and it is impossible to distinguish which one is the real credential of the current user through appearance. And only one of the hash values (that is, the first hash value) belongs to the current user, and the rest are interference items from other legitimate users. In this way, the anonymous set provides confusion for zero-knowledge proofs, so that the service verification end cannot identify the real identity of the user or associate it with other sessions while confirming that the user meets the target service access conditions, thus effectively protecting the long-term privacy and anti-tracking ability of the user.

[0057] Furthermore, for each user's access request to the target service, i.e. for each session, an anonymous set is dynamically constructed. The hash values ​​of other users with the same identity attribute type selected in the anonymous set are all different, and the order of each hash value in the anonymous set is randomly shuffled to ensure that there is no correlation between different sessions. The service provider cannot determine the user's real identity or the user's first hash value by comparing the anonymous set.

[0058] Next, the blockchain transaction identifier corresponding to each hash value in the anonymous set is retrieved from the blockchain network. This blockchain transaction identifier is a unique hash or number associated with the hash value when it is uploaded to the blockchain, used to accurately locate and verify the stored record of the identity credential on the blockchain. The blockchain transaction identifier itself does not contain user identity information, but it serves as a public index, allowing the service provider to independently verify that each hash value has indeed been issued and persistently stored in the blockchain by a legitimate identity provider without accessing an off-chain database.

[0059] Then, based on the target identity attribute information, the identity attribute description, and the anonymous set, a zero-knowledge proof is generated. This zero-knowledge proof is primarily used to prove that the target identity attribute information satisfies the target service access conditions without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set. This zero-knowledge proof may include multiple preset relationships to prove to the service provider, enabling the service provider to confirm that the user possesses the legal qualifications to access the target service without knowing the user's private key, the original identity attribute value, or its actual position in the anonymous set.

[0060] Specifically, this zero-knowledge proof can be achieved in the following ways: proving that the user's public key is correctly generated from their private key using a cryptographically secure hash or key derivation function, thereby ensuring the authenticity of the public key ownership; proving that the value of the target identity attribute information strictly falls within the range of attribute values ​​specified by the service provider, without disclosing the specific value of the attribute; and proving that the first hash value is indeed an element in the anonymous set, and that the matching relationship is concealed through a secret choice vector, making it impossible for the service provider to identify the specific index of the first hash value in the anonymous set.

[0061] Through the joint proof of the above multi-dimensional constraints, this solution fully meets the service provider's comprehensive verification requirements for the legality of credentials, the compliance of attributes, and the anonymity and untraceability while protecting user identity privacy.

[0062] Furthermore, in practical implementation, zero-knowledge proofs can be generated based on target identity attribute information, identity attribute descriptions, and anonymity sets using a zero-knowledge proof system. Such a system could be Plonky2, etc.

[0063] Finally, the blockchain transaction identifier and zero-knowledge proof for each hash value pair in the anonymous set are sent as proof credentials to the service provider of the target service. This allows the service provider to retrieve the anonymous set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value and the zero-knowledge proof in the anonymous set to confirm whether the client is authorized to access the target service.

[0064] In summary, in this embodiment, each time a user accesses a target service, a preset number of second hash values ​​are randomly selected from the hash values ​​of all users with the same identity attribute description as the target identity attribute information to be verified. These second hash values ​​are then combined with the user's first hash value and randomly sorted to dynamically construct an anonymous set. This not only hides the position of the user's first hash value in the anonymous set, but also ensures that the anonymous set constructed for each access to the target service is different. Therefore, the service provider cannot identify multiple accesses from the same user by comparing the anonymous set or blockchain transaction identifiers, achieving non-linkability between different sessions. Furthermore, when generating proof credentials, a zero-knowledge proof is generated by constructing a dynamic anonymous set and based on the target identity attribute information, identity attribute description, and anonymous set. This proof is used to demonstrate to the service provider that the target identity attribute information meets the access conditions of the target service without revealing the specific values ​​of the target identity attribute information or the user's true identity. This achieves anonymous protection of the user's identity, effectively preventing the leakage and tracing of user identity information and access behavior, while ensuring that the identity verification process is compliant and verifiable.

[0065] In the technical solution of this application, zero-knowledge proof serves as the core mechanism for achieving privacy-preserving identity verification, and its construction directly affects the system's security, efficiency, and scalability. In specific implementation, a general-purpose zero-knowledge proof system can be used to transform the identity verification logic into an arithmetic constraint circuit. By leveraging the user's secret input and public parameters, a concise, verifiable, and privacy-free proof can be collaboratively generated, thereby fully achieving the verification goals of attribute compliance, credential legitimacy, and identity anonymity. To more clearly illustrate the generation process of zero-knowledge proof in the embodiments of this application, this process is described in detail below.

[0066] Figure 3 A flowchart for generating zero-knowledge proofs is provided for embodiments of this application, such as... Figure 3 As shown, the method may specifically include the following steps: 301. Obtain the user's private key, the random salt value used to generate the first hash value, and the range of attribute values ​​required to access the target service.

[0067] 302. Using the user's private key, random salt value, and target identity attribute information as secret inputs, and the identity attribute description, anonymous set, and attribute value range as public inputs, generate a zero-knowledge proof through a zero-knowledge proof system.

[0068] When generating a zero-knowledge proof using a zero-knowledge proof system, the first steps are to obtain the user's private key, a random salt value used to generate the first hash value, and the required attribute value range for accessing the target service. The user's private key is the core of user authentication, ensuring that only users with the correct private key can perform the corresponding operations or access the target service. The required attribute value range for accessing the target service refers to the conditions or standards that a user must meet to access a specific target service or resource. Examples include age, membership level, and education level.

[0069] Since a user's private key, random verification, and target identity attribute information are sensitive privacy information, their leakage could lead to the exposure of the user's identity, attribute tracking, or key theft. Therefore, in order to ensure that the service provider cannot see this information, when generating zero-knowledge proofs using a zero-knowledge proof system, the user's private key, random salt value, and target identity attribute information can be used as secret inputs.

[0070] In this context, the attribute value range refers to the boundary conditions that the identity attribute information corresponding to the target service must meet. For example, if the target service is a community joining access service that requires users to have at least 10 and no more than 200 historical interactions, the corresponding identity attribute is described as "interactTimes," and its value range is a closed interval consisting of 10 to 200 interactions. Similarly, if the target service is an online course registration service that requires users to have a learning level of at least beginner level 3, the identity attribute is described as "studyLevel," and its value range is a closed interval consisting of level 3 to the highest level. By transforming such service rules into explicit value ranges and incorporating them as public input into zero-knowledge proofs, the service provider can verify whether a user meets the access conditions without needing to know the specific values ​​of the user's historical interaction count, learning level, etc.

[0071] Furthermore, when generating zero-knowledge proofs, the user's identity attribute description, anonymous set, and attribute value range do not directly involve the user's sensitive privacy information. In fact, these can be the verification rules themselves. The service provider needs to know this information to determine whether the generated zero-knowledge proofs are valid and thus whether to authorize the client to access the target service. Therefore, the identity attribute description, anonymous set, and attribute value range can be used as public inputs to generate corresponding zero-knowledge proofs using the zero-knowledge proof system.

[0072] In practical implementation, when generating a zero-knowledge proof through a zero-knowledge proof system, a selected zero-knowledge proof protocol can be used, combined with secret and public inputs, to generate a proof that can prove that a user meets specific conditions without revealing their actual identity information.

[0073] In one optional embodiment, before generating the corresponding zero-knowledge proof using the zero-knowledge proof system, the constraints to be verified can be determined in advance, and a proof circuit can be constructed based on the constraints. The corresponding proof circuit is then executed using the zero-knowledge proof system to generate the corresponding zero-knowledge proof.

[0074] Specifically, the target attribute conditions that need to be proven to the service provider are determined, and based on these conditions, the constraints to be verified are determined. A zero-knowledge proof circuit is constructed based on these constraints, using the user's private key, random salt value, and target identity attribute information as secret inputs, and identity attribute descriptions, anonymity sets, and attribute value ranges as public inputs. The zero-knowledge proof circuit is then executed through a zero-knowledge proof system to generate a zero-knowledge proof.

[0075] The constraints include a first constraint that the user's public key is derived from the user's private key through a hash function; a second constraint that the value of the target identity attribute information is within the range of attribute values; a third constraint that the user's first hash value is generated by hashing the identity attribute description, the target identity attribute information, the public key, and the random salt value; and a fourth constraint that the first hash value belongs to the anonymous set and its position in the anonymous set is unidentifiable.

[0076] For example, suppose the user's private key is sk and the user's public key is... PK Therefore, the first constraint is PK = Hash(sk). This first constraint is used to construct a proof circuit to prove to the service provider that the user's private key and the publicly disclosed public key are mapped, with the public key generated from the hash of the user's private key, thus proving that the user is the holder of the public key. Assume the user's target identity attribute information is... Priv The attribute value range is ( min , maIf x), then the second constraint is max > Priv > min. This second constraint can be used to construct a proof circuit to prove to the service provider that the user's target identity attribute information Priv is within a preset attribute value range, completing the attribute range compliance verification without disclosing the specific plaintext of Priv. Assuming the random salt is salt and the identity attribute description corresponding to the target identity attribute information is attr, then the third constraint is H = Hash(attr||Priv||PK||salt), that is, H is the user's first hash value. This third constraint can be used to construct a proof circuit to prove to the service provider that the identity hash value H stored on the chain is legally generated by hashing the user attribute description information attr, the target identity attribute information Priv, the user's public key PK, and the random salt value salt according to specified rules. The identity hash matches the user's original associated data and has not been tampered with. Assuming the anonymous set is... S H , S H If the set contains n hash values, then the fourth constraint is: H ∈ S H .

[0077] After identifying the constraints to be verified, corresponding sub-circuits can be constructed based on multiple constraints, and a corresponding proof circuit can be generated based on the constructed sub-circuits. Specifically, a first hash calculation sub-circuit is constructed based on the first constraint; a range proof sub-circuit is constructed based on the second constraint; a second hash calculation sub-circuit is constructed based on the third constraint; and a membership concealment sub-circuit is constructed based on the fourth constraint.

[0078] Specifically, the first hash calculation sub-circuit and the second hash calculation circuit can employ SHA-256 circuits. For the membership concealment sub-circuit, to ensure user anonymity—that is, to ensure the first hash value belongs to the anonymous set and its position within the anonymous set is unidentifiable—the membership concealment sub-circuit can be constructed as follows: A selection vector consisting of multiple selection bits is introduced, the length of which is equal to the number of hash values ​​in the anonymous set; a sum constraint is set on the selection vector such that the sum of all selection bits in the selection vector equals one; a Boolean constraint is applied to each selection bit in the selection vector to ensure that each selection bit can only be zero or one; for each bit of the first hash value, using the selection bits in the selection vector as weights, a weighted sum is calculated for the bits at the same position of each hash value within the anonymous set, and the weighted sum is then made equal to the current bit of the first hash value; the selection vector is embedded as part of the secret input into the membership concealment sub-circuit.

[0079] For example, suppose the anonymous set contains n hash values. We can first select a random vector b, which consists of n selected bits, i.e., b = (b1,...,bn). Furthermore, this random vector satisfies... Furthermore, for each selection bit bi, each of its selection bits satisfies a Boolean constraint, namely, for each selection bit bi · (1 - bi) = 0. This ensures that bi can only be 0 or 1, and there is only one bi = 1, representing the anonymous set. S H There is only one first hash value H for the user. Furthermore, for each bit of the user's first hash value H... Where Hi[j] is S H The j-th bit of the i-th hash value. Because... There must exist a unique i* such that bi* = 1, and all other bi = 0. Therefore, the above constraint is equivalent to H = H i ∗, that is, H ∈ S H However, the verifier cannot determine the correspondence between H and H. S H Which element in?

[0080] As can be seen from the above description: by selecting the bit vector b and the constraints Implementing H∈ in zero-knowledge proof circuits S H Anonymous verification is used, and membership proofs are transformed into linear combination constraints, avoiding direct exposure of H. S H The position of the SH (Signature) is such that even if the same user submits proof in different sessions, the verifier cannot pass the comparison due to the different composition of the SH. S H Or txids identifies the same user.

[0081] In summary, in this embodiment, by using the user's private key, target identity attribute information, and random salt value as secret inputs, and the identity attribute description, anonymous set, and attribute value range as public inputs, a zero-knowledge proof circuit conforming to the range verification rules is constructed. The zero-knowledge proof system is then invoked to generate the corresponding zero-knowledge proof. This achieves efficient and reliable proof to the service provider that the user's identity attributes meet the access conditions without disclosing the user's private key, original attribute values, and their true position in the anonymous set. At the same time, it ensures the legitimacy of the identity credential and the unlinkability of the session, thus balancing privacy protection, security verification, and compliant access.

[0082] In practical applications, the service provider can act as the verification end. Upon receiving the proof credentials submitted by the user, it needs to verify the zero-knowledge proof contained in the proof credentials to confirm that the user meets multiple constraints. This process will be described in detail below with reference to the following embodiments.

[0083] Figure 4 A flowchart illustrating another authentication method provided in this application embodiment; see attached document. Figure 4 As shown, this method can be applied to the service provider side. Specifically, based on the above embodiments, the method includes the following steps: 401. Receive the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set sent by the client.

[0084] 402. Obtain an anonymous set from the blockchain network based on blockchain transaction identifiers.

[0085] 403. Verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether the client is authorized to access the target service.

[0086] Once the service verification end receives the credentials sent by the client, it verifies whether the client meets multiple constraints based on the credentials to determine whether the client has the corresponding qualifications or permissions to access the target service.

[0087] The proof credentials include the blockchain transaction identifier corresponding to each hash value in the anonymous set and zero-knowledge proofs.

[0088] In this system, the hash value is an identity credential generated by the identity provider based on the identity attribute information and its corresponding description required for accessing the target service. The anonymous set is constructed by randomly selecting a preset number of second hash values ​​from the hash values ​​of other users with the same identity attribute description found in the blockchain network, and randomly sorting them with the user's first hash value. The zero-knowledge proof is generated based on the user's target identity attribute information, identity attribute description, and anonymous set. It is used to prove that the target identity attribute information meets the access conditions of the target service without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set. Furthermore, the specific implementation process for generating the hash value, anonymous set, and zero-knowledge proof can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0089] After obtaining the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set, before performing verification, the corresponding anonymous set can be obtained from the blockchain network based on the blockchain transaction identifier corresponding to each hash value, that is, each hash value in the anonymous set.

[0090] Then, the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof are verified to confirm whether the client is authorized to access the target service. Specifically, during the verification, it is possible to verify whether the identity attribute description corresponding to each hash value in the anonymous set is consistent and whether each hash value has not been revoked; and to verify the zero-knowledge proof to confirm whether the user's public key is derived from the user's private key through a hash function, whether the user's target identity attribute information meets the access conditions of the target service, whether the user's first hash value is generated by hashing the identity attribute description, the user's target identity attribute information, the user's public key, and a random salt value, and whether the anonymous set contains the first hash value.

[0091] In the specific implementation process, if the identity attribute description corresponding to each hash value in the anonymous set is consistent, and each hash value has not been revoked, and the user is confirmed to meet the four constraints, then the user is confirmed to be verified, the client can be authorized to access the target service, and the target service can be provided to the client.

[0092] This application embodiment receives a blockchain transaction identifier and a zero-knowledge proof submitted by the client at the service provider end, and dynamically obtains an anonymous set from the blockchain network based on the transaction identifier. Then, it performs dual verification on the on-chain validity of each hash value in the anonymous set and the cryptographic correctness of the zero-knowledge proof. This achieves secure, reliable, and privacy-preserving user identity authorization without relying on a centralized identity database, without knowing the user's real identity attribute values, and without being able to identify the user's specific position in the anonymous set. It effectively balances the compliance of access control, the unforgeability of identity credentials, and the untraceability of the user's long-term behavior.

[0093] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0094] To facilitate understanding of the authentication process described above, an example of the authentication process in a specific application scenario is provided. In practical applications, users can request a first hash value containing the target identity attribute information from the identity provider through the client in advance, and use it as an identity credential.

[0095] In practice, the client first generates the public and private keys corresponding to the user.

[0096] Specifically, a hash function can be used to generate the user's public and private keys. That is, the generated user's private key is sk, and the user's public key is PK = Hash(sk). The hash function can be a hash algorithm such as SHA-256, ensuring that the private key cannot be derived from the public key, while also guaranteeing the uniqueness and determinism of the public key.

[0097] Subsequently, in response to the identity credential application request triggered by the user for the target identity attribute information to be verified, the client forwards the identity credential application request to the identity provider. The identity credential application request includes the user's public key PK and the target identity attribute information Priv = 25.

[0098] After receiving the identity credential application request triggered by the client, the identity provider, while verifying the authenticity of the target identity attribute information Priv, generates a first hash value based on the target identity attribute information, the corresponding identity attribute description, the user's public key, and a random salt value, and performs a quantum-resistant signature on the first hash value and its corresponding identity attribute description and stores them in the blockchain network, and obtains the corresponding blockchain transaction identifier txid0. The signature algorithm can use Dilithium (quantum-resistant signature), which can effectively resist quantum attacks.

[0099] Specifically, the first hash value can be generated using the hash function H = Hash(attr||Priv||PK||salt). In the implementation of this application, the target identity attribute information Priv = 25 corresponding to the client, then the corresponding first hash value generated is H = Hash(age||25||PK||salt). Here, attr is the attribute description of Priv (such as age), salt is the random salt value, a long-term fixed random confusion factor configured for the user's sensitive attributes, and is used to confuse the original data during the hash calculation process.

[0100] Moreover, the identity provider sends the random salt value, the identity attribute description, the user's public key, and the target identity attribute information to the client. The client receives the random salt value, the identity attribute description, the user's public key, and the target identity attribute information sent by the identity provider through a trusted channel and stores these information secretly.

[0101] When the user wants to access the target service, an access request for the target service is triggered through the client. After receiving the access request, the client, in response to the access request for the target service triggered by the user, determines that the condition for the identity attribute information required for the user to access the target service to be verified is 18 < age < 45, and obtains the first hash value H corresponding to the target identity attribute information Priv = 25 required for the user to access the target service.

[0102] Moreover, the client queries all the hash values of the age attribute on the blockchain network, randomly selects 127 of them, and combines them with the user's own first hash value H to form and randomly sort to construct an anonymous set S H (n = 128), that is, the anonymous set includes 128 hash values. The size n of the anonymous set is preferably set to 128 or 256 to balance anonymity and computational overhead.

[0103] In other words, by randomly selecting n-1 different hash values ​​from other users during each proof, different anonymity sets are constructed. S H Even if the same user submits proof in different sessions, because... S H Because their compositions differ, verifiers cannot identify the same user by comparing SH or txids.

[0104] Then, obtain the blockchain transaction identifier txids = {txid1, txid2, ..., txidn} corresponding to each hash value in the anonymous set from the blockchain network. txids is the blockchain transaction identifier corresponding to all n hash values ​​in SH.

[0105] Next, the client generates a zero-knowledge proof based on the target identity attribute information, identity attribute description, and anonymity set. Specifically, it calls the zero-knowledge proof system to generate a zero-knowledge proof π, proving that: PK = Hash(sk), 18 < 25 < 45, H = Hash(age||25||PK||salt), H ∈ S H .

[0106] Before generating a zero-knowledge proof using a zero-knowledge proof system, a circuit can be constructed based on multiple constraints. This circuit has approximately 35,000-40,000 gates (depending on the attribute range and set size). The resulting zero-knowledge proof is approximately 150-200 KB in size and requires only about 2-3 seconds of proof time (on standard hardware).

[0107] Among them, zero-knowledge proof systems can be based on post-quantum-secure mathematical structures to effectively resist quantum attacks.

[0108] Finally, the client submits the generated zero-knowledge proof π and the blockchain transaction identifiers txids corresponding to each hash value in the anonymous set to the service provider. The hash function can be SHA-256 (256-bit output). The zero-knowledge proof system can be Plonky2 (based on STARKs).

[0109] Furthermore, this zero-knowledge proof is mainly used to prove to the service provider that the user's public key is derived from the private key held by the user through a hash function, that the value of the user's target identity attribute information is within the range of attribute values, that the user's first hash value is generated by hashing the identity attribute description, the target identity attribute information, the public key and the random salt value, and that the first hash value belongs to the anonymous set and its position in the anonymous set is unidentifiable.

[0110] The specific value of the attribute Priv is completely hidden. It is only proven that it satisfies the range condition max>Priv>min, which can realize the principle of minimum exposure and better protect user privacy information.

[0111] After receiving the generated zero-knowledge proof π and the blockchain transaction identifier txids corresponding to each hash value in the anonymity set, the service provider retrieves the blockchain transaction identifier txids from the chain. S H The system verifies that all hash values' `attr` is `age` and has not been revoked. It also verifies `π` to confirm that the user meets all conditions. This verification process takes only about 10 milliseconds. In other words, it verifies the data via blockchain. S H The authenticity and validity of all hash values ​​in the data cannot be verified, and the user's true identity cannot be determined.

[0112] Once a user passes all verifications, the service provider offers the target service, but cannot determine the user's true age or identity.

[0113] In this embodiment of the application, an anonymous set is constructed. S H By introducing a chosen bit vector b, anonymous membership verification of identity hash values ​​is achieved in zero-knowledge proofs, thereby realizing session unlinkability, the principle of minimum exposure, and resistance to quantum attacks. This method can be widely applied to decentralized identity systems, privacy-preserving identity authentication, attribute proof, and other scenarios.

[0114] The authentication apparatus of one or more embodiments of this application will be described in detail below. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0115] Figure 5 This is a schematic diagram of the structure of an authentication device provided in an embodiment of this application, applied to a client, such as... Figure 5 As shown, the device includes: a response module 11, a construction module 12, an acquisition module 13, a generation module 14, and a sending module 15.

[0116] The response module 11 is used to respond to a user-triggered access request for a target service and obtain a first hash value corresponding to the target identity attribute information that the user needs to verify to access the target service; the first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description.

[0117] The construction module 12 is used to query the hash values ​​of other users with the same identity attribute description from the blockchain network, and randomly select a preset number of second hash values ​​from the hash values ​​and randomly sort them with the first hash values ​​to construct an anonymous set.

[0118] The acquisition module 13 is used to acquire the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network.

[0119] The generation module 14 is used to generate a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymous set; the zero-knowledge proof is used to prove that the target identity attribute information satisfies the target service access conditions without disclosing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

[0120] The sending module 15 is used to send the blockchain transaction identifier and the zero-knowledge proof to the service provider corresponding to the target service, so that the service provider can obtain the anonymous set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service.

[0121] Optionally, the response module 11 is further configured to: respond to an identity credential application request triggered by a user for the target identity attribute information to be verified, forward the identity credential application request to the identity provider, so that the identity provider, after verifying the authenticity of the target identity attribute information, generates a first hash value based on the target identity attribute information, the corresponding identity attribute description, the user's public key, and a random salt value, and stores the first hash value and its corresponding identity attribute description in the blockchain network using a quantum-resistant signature; receive the random salt value and the identity attribute description sent by the identity provider through a trusted channel; wherein, the identity credential application request includes the user's public key and the target identity attribute information.

[0122] Optionally, the generation module 14 is specifically used to: obtain the user's private key, a random salt value for generating the first hash value, and the required attribute value range for accessing the target service; take the user's private key, the random salt value, and the target identity attribute information as secret inputs, and take the identity attribute description, the anonymous set, and the attribute value range as public inputs, and generate a zero-knowledge proof through the zero-knowledge proof system.

[0123] Optionally, the generation module 14 is specifically used to: determine the constraints to be verified based on the target attribute conditions that need to be proved to the service provider; construct a zero-knowledge proof circuit based on the constraints; and generate the zero-knowledge proof by executing the zero-knowledge proof circuit through the zero-knowledge proof system, using the user's private key, the random salt value, and the target identity attribute information as secret inputs, and the identity attribute description, the anonymity set, and the attribute value range as public inputs.

[0124] Optionally, the constraints include a first constraint that the user's public key is derived from the user's private key through a hash function, a second constraint that the value of the target identity attribute information is within the range of the attribute values, a third constraint that the user's first hash value is generated by hashing the identity attribute description, the target identity attribute information, the public key, and the random salt value, and a fourth constraint that the first hash value belongs to the anonymous set and its position in the anonymous set is unidentifiable.

[0125] Optionally, the generation module 14 is specifically used to: construct a first hash calculation sub-circuit based on the first constraint; construct a range proof sub-circuit based on the second constraint; construct a second hash calculation sub-circuit based on the third constraint; and construct a membership concealment sub-circuit based on the fourth constraint.

[0126] Optionally, the generation module 14 is specifically configured to: introduce a selection vector consisting of multiple selection bits, the length of which is equal to the number of hash values ​​in the anonymous set; set a sum constraint on the selection vector such that the sum of the values ​​of all selection bits in the selection vector is equal to one; apply a Boolean constraint to each selection bit in the selection vector to constrain the value of each selection bit to be either zero or one; for each bit of the first hash value, using the selection bits in the selection vector as weights, perform a weighted summation on the bits at the same position of each hash value in the anonymous set, and establish an equality constraint between the weighted sum and the current bit of the first hash value; and embed the selection vector as part of the secret input into the membership concealment sub-circuit.

[0127] Figure 5 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0128] In one possible design, the above Figure 5 The structure of the authentication device shown can be implemented as an electronic device, such as... Figure 6As shown, the electronic device may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores executable code, which, when executed by the processor 22, enables the processor 22 to at least implement the authentication method performed by the client as provided in the foregoing embodiments.

[0129] Figure 7 This is a schematic diagram of another authentication device provided in an embodiment of this application, applied to a service provider, such as... Figure 7 As shown, the device includes: a receiving module 31, an acquisition module 32, and a verification module 33.

[0130] The receiving module 31 is used to receive the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set sent by the client.

[0131] The acquisition module 32 is used to acquire the anonymous set from the blockchain network based on the blockchain transaction identifier.

[0132] Verification module 33 is used to verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof, in order to confirm whether the client is authorized to access the target service.

[0133] Wherein, the hash value is an identity credential generated by the identity provider based on the identity attribute information and its corresponding identity attribute description required for accessing the target service. The anonymous set is constructed by randomly selecting a preset number of second hash values ​​from the hash values ​​of other users with the same identity attribute description found in the blockchain network and randomly sorting them with the user's first hash value. The zero-knowledge proof is generated based on the user's target identity attribute information, the identity attribute description, and the anonymous set. It is used to prove that the target identity attribute information meets the access conditions of the target service without disclosing the specific value of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

[0134] Optionally, the verification module 33 is specifically used to: verify whether the identity attribute description corresponding to each hash value in the anonymous set is consistent, and whether each hash value has not been revoked; verify the zero-knowledge proof to confirm whether the user's public key is derived from the user's private key through a hash function, whether the user's target identity attribute information satisfies the target service access conditions, whether the user's first hash value is generated by hashing the identity attribute description, the user's target identity attribute information, the user's public key, and the random salt value, and whether the anonymous set contains the first hash value.

[0135] Figure 7The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0136] In one possible design, the above Figure 7 The structure of the authentication device shown can be implemented as an electronic device, such as... Figure 8 As shown, the electronic device may include: a memory 41, a processor 42, and a communication interface 43. The memory 41 stores executable code, which, when executed by the processor 42, enables the processor 42 to at least implement the authentication method performed by the service provider as described in the foregoing embodiments.

[0137] Furthermore, this application embodiment also provides a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the authentication method provided in the foregoing embodiments.

[0138] In addition, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, enable the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by a computer program or instructions.

[0139] In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0140] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0141] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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.

Claims

1. An identity attribute verification method, characterized by, Applied to a client, the method includes: In response to a user-triggered access request to a target service, a first hash value corresponding to the target identity attribute information required for the user to access the target service is obtained; the first hash value is an identity credential generated by the identity provider based on the target identity attribute information and its corresponding identity attribute description. The system queries the blockchain network for hash values ​​of other users whose identity attributes are identical to the first hash value, and randomly selects a preset number of second hash values ​​from the hash values ​​and randomly sorts them with the first hash value to construct an anonymous set. Obtain the blockchain transaction identifier corresponding to each hash value in the anonymous set from the blockchain network; Based on the target identity attribute information, the identity attribute description, and the anonymous set, a zero-knowledge proof is generated; the zero-knowledge proof is used to prove that the target identity attribute information satisfies the target service access conditions without revealing the specific values ​​of the target identity attribute information, and that the first hash value is hidden in the anonymous set. The blockchain transaction identifier and the zero-knowledge proof are sent to the service provider corresponding to the target service, so that the service provider can obtain the anonymity set from the blockchain network based on the blockchain transaction identifier and verify the validity of each hash value in the anonymity set and the validity of the zero-knowledge proof to confirm whether to authorize the client to access the target service.

2. The method of claim 1, wherein, The method further includes: In response to a user's identity credential application request triggered by the target identity attribute information to be verified, the identity credential application request is forwarded to the identity provider, so that the identity provider, after verifying the authenticity of the target identity attribute information, generates a first hash value based on the target identity attribute information, the corresponding identity attribute description, the user's public key, and a random salt value, and stores the first hash value and its corresponding identity attribute description in the blockchain network using a quantum-resistant signature. Receive the random salt value and the identity attribute description sent by the identity provider through a trusted channel; The identity credential request includes the user's public key and the target identity attribute information.

3. The method of claim 1, wherein, The step of generating a zero-knowledge proof based on the target identity attribute information, the identity attribute description, and the anonymity set includes: Obtain the user's private key, the random salt value used to generate the first hash value, and the required attribute value range for accessing the target service; The user's private key, the random salt value, and the target identity attribute information are used as secret inputs, while the identity attribute description, the anonymous set, and the attribute value range are used as public inputs. The zero-knowledge proof system is then used to generate a zero-knowledge proof.

4. The method of claim 3, wherein, The process of generating a zero-knowledge proof using the user's private key, the random salt value, and the target identity attribute information as secret inputs, and the identity attribute description, the anonymity set, and the attribute value range as public inputs, through the zero-knowledge proof system, includes: Based on the target attribute conditions that need to be proved to the service provider, determine the constraints to be verified; Construct a zero-knowledge proof circuit based on the aforementioned constraints; Using the user's private key, the random salt value, and the target identity attribute information as secret inputs, and the identity attribute description, the anonymity set, and the attribute value range as public inputs, the zero-knowledge proof system executes the zero-knowledge proof circuit to generate the zero-knowledge proof.

5. The method of claim 4, wherein, The constraints include a first constraint that the user's public key is derived from the user's private key through a hash function; a second constraint that the value of the target identity attribute information is within the range of the attribute values; a third constraint that the user's first hash value is generated by hashing the identity attribute description, the target identity attribute information, the public key, and the random salt value; and a fourth constraint that the first hash value belongs to the anonymous set and its position in the anonymous set is unidentifiable.

6. The method of claim 5, wherein, The construction of the zero-knowledge proof circuit based on the constraints includes: Based on the first constraint, a first hash calculation sub-circuit is constructed; Based on the second constraint, a range proof sub-circuit is constructed; Based on the third constraint, a second hash calculation sub-circuit is constructed; Based on the fourth constraint, a membership relationship concealment sub-circuit is constructed.

7. The method of claim 6, wherein, The construction of the membership concealment sub-circuit based on the fourth constraint includes: A selection vector consisting of multiple selection bits is introduced, the length of which is equal to the number of hash values ​​in the anonymous set; A summation constraint is set on the selection vector such that the sum of the values ​​of all selection bits in the selection vector equals one. Apply a Boolean constraint to each selection bit in the selection vector to ensure that the value of each selection bit can only be zero or one. For each bit of the first hash value, using the selected bits in the selection vector as weights, perform a weighted sum on the bits at the same position of each hash value in the anonymous set, and establish an equality constraint between the weighted sum and the current bit of the first hash value; The selection vector is embedded as part of the secret input into the membership concealment sub-circuit.

8. An identity attribute verification method, characterized by, Applied to the service provider, the method includes: Receive the blockchain transaction identifier and zero-knowledge proof corresponding to each hash value in the anonymous set sent by the client; Based on the blockchain transaction identifier, the anonymous set is obtained from the blockchain network; Verify the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof to confirm whether the client is authorized to access the target service; Wherein, the hash value is an identity credential generated by the identity provider based on the identity attribute information and its corresponding identity attribute description required for accessing the target service. The anonymous set is constructed by randomly selecting a preset number of second hash values ​​from the hash values ​​of other users with the same identity attribute description found in the blockchain network and randomly sorting them with the user's first hash value. The zero-knowledge proof is generated based on the user's target identity attribute information, the identity attribute description, and the anonymous set. It is used to prove that the target identity attribute information meets the access conditions of the target service without disclosing the specific value of the target identity attribute information, and that the first hash value is hidden in the anonymous set.

9. The method of claim 8, wherein, The verification of the validity of each hash value in the anonymous set and the validity of the zero-knowledge proof includes: Verify whether the identity attribute descriptions corresponding to each hash value in the anonymous set are consistent, and whether each hash value has not been revoked; The zero-knowledge proof is verified to confirm whether the user's public key is derived from the user's private key through a hash function, whether the user's target identity attribute information satisfies the target service access conditions, whether the user's first hash value is described by the identity attribute, the user's target identity attribute information, the user's public key, and the random salt value are jointly hashed, and whether the anonymity set contains the first hash value.

10. An electronic device, comprising: include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, which, when executed by the processor, causes the processor to perform the identity attribute verification method as described in any one of claims 1 to 7 or 8 to 9.

11. A non-transitory machine-readable storage medium, comprising: The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the identity attribute verification method as described in any one of claims 1 to 7 or 8 to 9.

Images