A Distributed Trusted Digital Identity Authentication Method Based on Smart Contracts
By adopting linkable ring signature, zero-knowledge proof, dynamic accumulator and multi-signature mechanism in the blockchain smart contract digital identity authentication system, security and privacy issues in the identity authorization and authentication process are solved, the autonomy and flexible control characteristics of the identity are enhanced, and the authenticity and credibility of the identity are realized.
Patent Information
- Application Number
- CN202410589021.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-05-13
- Publication Date
- 2025-05-27
- Estimated Expiration
- 2044-05-13
AI Technical Summary
The existing blockchain-based smart contract digital identity authentication system has security and privacy issues in the process of identity authorization and authentication, and the autonomous and flexible management characteristics are insufficient.
Linkable ring signature is used to sign the user's digital identity, hidden public keys are used to proof of non-interactive zero-knowledge, revocable credentials are issued using cryptographic dynamic accumulator, and the identity is decoupled from attributes, and the multi-signature mechanism is used to recover the loss of identity.
It improves the anonymity and privacy protection of user identities, enhances the autonomy and flexibility of identity control, realizes the passive and two-way revocation of identity, and ensures the authenticity and credibility of identity.
Smart Images

Figure CN118487768B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of digital identity authentication, and particularly relates to a distributed trusted digital identity authentication method based on smart contracts. Background Art
[0002] Digital identity is the unique identifier of a person in the digital environment, usually including various information related to it. Digital identity can not only prove identity, but the massive personal information linked behind it is the real value of digital identity. Therefore, by constructing a reliable digital identity scheme, effective guarantee can be provided for data management. Only by ensuring the authenticity and validity of digital identity, the data of a series of activities, transactions, etc. associated with it are authentic and valid. In current network applications, a centralized digital identity authentication and management system architecture centered on application service providers or authoritative institutions, such as CA (Certificate Authority) digital certificates of public key infrastructure, is still widely used. This architecture has problems such as the central institution acting maliciously resulting in user privacy leakage, maintaining a large-scale revocation list affecting system performance, and poor user management authority over their own identities. For example, the OpenID system does not use any proof of legal ownership, which makes it vulnerable to the risk of credential theft. In addition, malicious service providers may also direct users to false identity providers, and there is also the risk of man-in-the-middle attacks, etc.
[0003] With the continuous development of blockchain technology, its characteristics of decentralization, immutability, and multi-party maintenance can well solve problems existing in the traditional digital identity system architecture, such as a large-scale certificate revocation list, difficult cross-domain authentication of heterogeneous CA certificates, fragmented identities, and single points of failure. Many scholars have successively proposed various decentralized digital identity system architectures based on technologies such as blockchain smart contracts. For example, the Ethereum blockchain smart contract digital identity authentication and management framework can provide users with a unique identity identifier and can implement functions such as fine-grained identity management and recoverability of lost identities; the smart contract public key infrastructure identity authentication system uses four smart contracts of entity, attribute, signature, and revocation to manage users' identities and can achieve fine-grained identity management and trusted authorization; the DDMIA scheme allows patients to be authenticated by multiple parties without registering with all parties, eliminating the need for multiple registration centers and digital certificates. Although the blockchain-based smart contract digital identity architecture has many advantages, there are still relatively large problems in the process of identity authorization and authentication in existing solutions:
[0004] 1) Security and privacy need to be improved: The current solutions are not anonymous enough in verifying the real identities of users. Almost all identity verifiers are public, which easily leads to the leakage of real identities. In addition, there is an over-disclosure of identity attributes in the process of using identity request services. Although solutions such as EverSSDI encrypt identities before submission, this problem still exists for the decrypted identities.
[0005] 2) The characteristics of autonomous and flexible control need to be enhanced: The current solutions completely bind identities and attributes. When the private key controlling the identity is lost, the associated attributes can no longer be used. In addition, the controllability of identities is not flexible enough to effectively implement functions such as active, passive, and two-way revocation of identities. Summary of the Invention
[0006] To solve the above technical problems, the present invention provides a distributed trusted digital identity authentication method based on smart contracts, including:
[0007] The identity verifier signs the user's digital identity using linkable ring signatures to verify the authenticity of the user's digital identity, the anonymity of the verifier, and the auditability;
[0008] The user uses the contract address as the identity identifier and uses non-interactive zero-knowledge proofs to hide the public key, and applies for digital identity authentication with minimal disclosure of identity attributes to the service provider through a commitment mechanism;
[0009] The identity verifier issues a revocable credential for the user's service using a cryptographic dynamic accumulator. When either the user or the service provider discovers malicious behavior from the other party during the service process, the user service credential can be revoked actively or passively;
[0010] Decouple the user's identity and attributes, and use a multi-signature mechanism to enable the recoverability of the lost user digital identity.
[0011] Preferably, before verifying the authenticity of the user's digital identity, the anonymity of the verifier, and the auditability, a system initialization operation is also included;
[0012] The process of the system initialization operation includes:
[0013] Generate a group public key L = {y l1 ,..., y ln} based on a group of n identity verifiers, and publish it to the IVs_PublicKey smart contract; preset the blockchain anonymous accounts Addr_X, X ∈ [1, n] of each identity verifier as legal accounts that can participate in multi-party voting to participate in multi-party voting transactions;
[0014] The identity verifier generates system parameters And publicly release it to the blockchain smart contract System_Parames. After verifying the validity of the physical certificate, the authenticator uses linkable ring signature to sign the user's identity attributes, hiding the authenticator on the premise of proving the authenticity and validity of the user's identity.
[0015] Preferably, the process that the authenticator uses linkable ring signature to sign the user's identity attributes after verifying the validity of the physical certificate includes:
[0016] All authenticator members i = 1,..., n in the group randomly select their own private keys and generate the group public key L = {y l1 ,..., y ln}, where
[0017] For the message m ∈ {0, 1} * , the anonymous signer i calculates h l = H l2 (L), randomly selects r l ∈ Z q , c lj ∈ Z q , j = 1,…, n, j ≠ i, and then searches for c li such that the formula (1) holds. Among them, the formula expression of the formula (1) is:
[0018]
[0019] After obtaining c li , calculate s l = r l - c li x li mod q li , and obtain the signature value Sig 1 = (y l0 , s l , c l1 ,..., c ln ), where y l0 is the link value;
[0020] The signature verifier calculates h l = H l2 (L), and determines whether the formula (1) holds. If it holds, output True; otherwise, output False.
[0021] Preferably, the process of hiding the authenticator includes:
[0022] Read the system parameters in System_Parames Generate a private digital identity pk using non-interactive zero-knowledge proof u ∥δ and generate an attribute commitment Commit(A, r) using Pederson commitment. Select a member from the verifiers and submit all physical credentials of the true identity, all attributes A of the user i and the corresponding random number r i as well as the identity contract address Addr_DIMC;
[0023] The verifier reads the commitment of the attribute from the contract. After verifying the validity of the attribute and the commitment, perform a linkable ring signature Sig l =(y l0 , s l , c l1 ,…, c ln ), where y l0 is the linkable value, and write Sig l into the IDP signature of DIMC, associate the linkable value with the commitment <y l0 , Commit> and write it into the contract LinkableValue_Commit.
[0024] Preferably, generate a private digital identity pk using non-interactive zero-knowledge proof u ∥δ and the process of generating an attribute commitment Commit(A, r) using Pederson commitment includes:
[0025] Define the secret v, calculate y = g v , and randomly select r ∈ Z q , calculate t = g r , c = H(t) and s = cv + r; then the user sends y = g v and proof=(t, s) to the verifier, where proof=(t, s) is the zero-knowledge proof of v;
[0026] The verifier calculates c = H(t), and verifies whether g s = y c t holds. If it holds, it indicates that the verifier is the holder of the secret v.
[0027] Preferably, the verifier uses a linkable ring signature to sign the user's digital identity. The process of verifying the authenticity of the user's digital identity, the anonymity of the verifier and the auditability includes:
[0028] The user submits the real physical credential, the attribute value and its random number, and the digital identity address Addr_DIMC to the authenticator. The authenticator reads the attribute commitment Commit through the smart contract, performs linkable ring signature after verifying the legality and validity, and issues a revocable credential (k i ,w i ) to the user. Meanwhile, the key key of the AES symmetric encryption algorithm is calculated AES . Then, the linkable ring signature is written into the IDP signature field of DIMC, and the linkable value and the attribute commitment <y l0 ,Commit> are written into the LinkableValue_Commit contract. After that, the user's revocable credential and key AES are sent to the user.
[0029] Preferably, the process of the digital identity authentication includes:
[0030] The user provides the required attribute A i , the corresponding random number r i , the remaining attributes and the random number and the identity address Addr_DIMD, the revocable credential (k i ,w i ) and AES_Encrypt(key AES ,(k i ,w i )) to the service provider;
[0031] The service provider reads the user's signature and commitment from the contracts DIMC and DIAC, calls the IDP_Verify contract to judge the correctness of the linkable ring signature, calls the Commit_Verify contract to judge the consistency of the attributes and the commitment, and calls the RC_Verify contract to judge the validity of the revocable credential. If all the judgments are correct, the service is provided to the user.
[0032] Preferably, the process of actively revoking the user's service credential includes:
[0033] When the user violates the regulations during the service period or the contract expires, the service provider broadcasts AES_Encrypt(key AES ,(k i ,w i )) through the contract to request the revocation of the user's credential. The correct authenticator decrypts through key AES to obtain the corresponding revocable credential (k i ,w i ), and then calls the contract RC_Verify to verify the revocable credential (k i ,w i) If it is valid, call the identity revocation contract ID_Rrvoke to revoke the service credential;
[0034] After revocation, obtain the linkable value y from the local; l0 And find <y in the LinkableValue_Commit contract l0 , Commit>, obtain the corresponding commitment value Commit, and broadcast to other verifiers that "there is a malicious user and his commitment value is Commit". The verifier increments the number of malicious user behaviors by 1 through the contract Malicious_Num, that is, N[y l0 = N[y l0 + 1, and the passive revocation is completed.
[0035] Preferably, the process of actively revoking the user service credential includes:
[0036] When the user discovers that the user information or behavior privacy is threatened by the service provider, actively request the verifier to revoke the revocable credential corresponding to the service;
[0037] The verifier calls the identity revocation contract ID_Revoke to actively revoke the revocable credential.
[0038] Preferably, decouple the user's identity and attributes, and the process of recoverability of the lost user digital identity using the multi-signature mechanism includes:
[0039] Create a digital identity recovery contract, and add the anonymous addresses Addr_X of all members in the linkable ring signature group as legal accounts;
[0040] When the user loses the private key, find the DICC address through his own DIMC address, and use the zero-knowledge proof pk of the new public key new ∥δ' as a parameter input, call the digital identity recovery contract (ID_Recover), and the verifier group performs multi-signature to decide whether to agree to the user to retrieve the identity, realizing the identity recovery of the autonomous request.
[0041] Compared with the prior art, the present invention has the following advantages and technical effects:
[0042] 1) To solve the problem of insufficient anonymization in authentication in security and privacy, the present invention introduces linkable ring signature. Using the anonymous feature of this signature, the specific verifiers are hidden, so as to protect the privacy of verifiers on the premise of ensuring the authenticity of identity and reduce the collusion attack;
[0043] 2) To address the problem of excessive disclosure of identity attributes in security and privacy, the present invention uses zero-knowledge proofs to hide the public key representing the user's true identity, and uses selective disclosure technology to hide and disclose identity attributes on demand, minimizing the privacy leakage of identities and attributes as much as possible;
[0044] 3) To address the issues of autonomous management and flexible recovery in autonomous and flexible control, the present invention decouples identities and attributes, and uses on-chain multi-signature to securely recover identities after identity loss, achieving the purpose of autonomous control and secure and flexible recovery;
[0045] 4) To address the controllability in autonomous and flexible control, the present invention introduces cryptographic accumulators and symmetric encryption algorithms to actively and passively revoke identities when necessary, realizing the flexible control characteristics of digital identities. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] The drawings forming a part of this application are used to provide a further understanding of this application. The schematic embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation of this application. In the drawings:
[0047] Figure 1 is a schematic diagram of the system framework of the embodiment of the present invention;
[0048] Figure 2 is a schematic diagram of the digital identity contract architecture of the embodiment of the present invention;
[0049] Figure 3 is a schematic diagram of the active and passive revocation model of the embodiment of the present invention;
[0050] Figure 4 is a schematic diagram of the digital identity recovery method flow of the embodiment of the present invention;
[0051] Figure 5 is a Gas fee consumption diagram of the core smart contract of the embodiment of the present invention;
[0052] Figure 6 is a running time diagram of the core steps of the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0053] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The following will refer to the drawings and combine the embodiments to detail this application.
[0054] It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.
[0055] Singh et al. proposed a digital identity system with identity and behavioral privacy based on the Hyperledger blockchain. First, users need to submit real physical credentials to the authenticator for identity verification, map the verified identity to a cryptographic commitment, and have it signed by the authenticator. Then, the user submits the signed commitment to the credential provider to obtain privacy credentials. These operations are to ensure that the privacy credentials are based on the user's actual physical identity, while avoiding disclosing the user's real physical credentials to the credential provider, which may lead to the leakage of the real identity. However, both the physical credential verification and the issuance of verifiable credentials in this scheme are carried out off-chain, and various potential security threats need to be guarded against, including identity fraud, data tampering, etc. On the other hand, the identity of the authenticator in this scheme is public, and malicious users may obtain the user's actual identity from the authenticator, resulting in a collusion attack, that is, the problem of insufficient anonymization of identity verification in the above security and privacy has not been solved.
[0056] Niu et al. implemented a cross-domain self-sovereign identity management system based on smart contracts. The system contains three types of smart contracts, each of which is used to perform specific functions: The service smart contract (SSC) is the basic contract in the system. It controls the release of user identity contracts, creates and publishes them when service providers join the system. The second is the identity smart contract (ISC). After users are identified and verified, they request this contract from the service provider, and their addresses are recorded in the SSC. The ISC is controlled by the user after it is released. At the same time, a recovery smart contract (RSC) is also created. However, this system stores the complete attribute information on the user device, and the availability of the attribute information will be reduced when the user is offline. Moreover, in this system, users need to hand over all their attributes to the service provider for authentication and verification, without giving users the right to selectively disclose their own attributes, which is likely to cause excessive disclosure of attributes and thus leakage of the real identity.
[0057] The privacy and security of user data are the two most important factors to consider. Existing technologies have achieved privacy protection for blockchain-based digital identity systems using succinct non-interactive zero-knowledge proof techniques. In addition, there is a verifiable anonymous identity management system, VAIM, which enhances the unlinkability of the system by using zero-knowledge proof algorithms. However, these systems still cannot fully achieve the authenticity and trustworthiness of identities, the privacy of identity information, and the privacy of identity behaviors simultaneously. For example, the system UPort
[11] proposed by Lundkvist et al. constructs digital identities using contracts, with the contract address serving as a globally unique identity identifier. However, the smart contract is only used to manage and control identities, and this system does not have contract-based identity trust verification; the system proposed by Wang et al. uses a distributed ledger to store certificate information and certificate revocation status and manages private keys distributively, but the user identity information is publicly available in the distributed ledger, and there is no guarantee of identity privacy; the system Certcoin uses a distributed ledger to store user identities, public keys, and their relationships, and the user identity information and behavior information are publicly available in the distributed ledger, and there is no guarantee of behavior privacy.
[0058] The cross-domain autonomous identity management system based on smart contracts proposed by Niu et al. mentioned above includes a recovery smart contract (RSC). However, its specific solution is to pre-store the addresses of friends (3 - 7) in the RSC. When a user's public key is lost, the user needs to send a recovery request to his friends and inform them of the new public key. The friend then sends a recovery request to the user's RSC through his own ISC and sends the user's new public key. When the RSC collects enough requests, it will perform the operation of updating the public key. This recovery solution cannot resist the collusion attack caused by friends' malicious behavior to a certain extent, and if friends are collectively offline, their identities cannot be restored in a timely and effective manner. Although the scheme mentions an active revocation function, it does not write out a detailed design scheme.
[0059] Bouras et al. proposed a new identity management method based on private blockchains. The main functions of the identity management system are divided into three stages: identity registration, identity authentication, and identity revocation, and smart contracts are used to interact with the blockchain. This scheme proposed a lightweight identity management architecture and related protocols based on consortium blockchains to address privacy, security, and scalability issues in IoT centralized systems. However, in terms of characteristics, this scheme is more like a centralized one, thus increasing the risks of single-point failures and central authority problems. Moreover, this scheme uses a separate ledger to store revoked identities, and before any identity authentication operation, it is necessary to check entity requests by parsing the revocation ledger. In this revocation scheme, writing revoked identity information into the ledger may expose users' privacy, and the revocation ledger may not be updated in real time, which means there is a certain delay, and as the scale of the revocation ledger grows, it may lead to challenges in storage and management, especially in large-scale identity management systems.
[0060] At present, most digital identity management systems have some deficiencies in the flexible and autonomous control of digital identities, especially in the active, passive, two-way revocation, and flexible recovery of digital identities. In existing systems, revoking a digital identity often requires a cumbersome process, including multiple verifications and manual reviews, which results in a long and inefficient revocation process, and users may need to wait a long time to successfully revoke their identities. Similarly, identity recovery in digital identity systems may also be limited by cumbersome processes and requirements, and users may need to provide a large amount of information and verifications to recover their accidentally lost identities, which increases the burden and operational complexity for users.
[0061] To solve the above problems, starting from the authenticity and security of users' identity attributes and behaviors, this embodiment provides a distributed trusted digital identity authentication method based on smart contracts to address issues such as the lack of guarantee for the authenticity of on-chain users' digital identities, verifiers leaking users' real identities, excessive disclosure of identity attributes, complex two-way revocation of digital identities, and the inability to recover lost private keys. Specifically, it includes the following steps:
[0062] The identity verifier uses linkable ring signatures to sign the user's digital identity to verify the authenticity of the user's digital identity, the anonymity of the verifier, and the audibility.
[0063] The user uses the contract address as the identity identifier and uses non-interactive zero-knowledge proofs to hide the public key, and applies for digital identity authentication with minimal disclosure of identity attributes to the service provider through a commitment mechanism.
[0064] The authenticator uses a cryptographic dynamic accumulator to issue revocable credentials for user services. When either the user or the service provider detects malicious behavior during the service process, the user service credentials can be revoked actively or passively.
[0065] Decouple the user's identity and attributes, and use a multi-signature mechanism for the recoverability of the user's digital identity loss.
[0066] Furthermore, linkable ring signature belongs to a variant of ring signature. Ring signature is a special digital signature scheme that allows a member to sign a message in an anonymous group without revealing the signer's identity. Linkable ring signature introduces the concept of linkability, allowing the same signer to be identified in different signatures, meeting the dual characteristics of anonymity and supervision. The present invention adopts the signature scheme of Liu and Wong, which has a low computational complexity, and the security of this scheme is based on the discrete logarithm problem and is secure and reliable under the random oracle model. The specific scheme is as follows:
[0067] 1) System initialization: All members i = 1,..., n in the group randomly select their own private keys and generate the group public key L = {y l1 ,..., y ln}, where
[0068] 2) Generate signature: For the message m ∈ {0, 1} * , the anonymous signer i calculates h l = H l2 (L), randomly selects r l ∈ Z q , c lj ∈ Z q , j = 1,…, n, j ≠ i, and then finds c li such that the formula (1) holds:
[0069]
[0070] After obtaining c li , calculate s l = r l - c li x li mod q li , and obtain the signature value Sig 1 = (y l0 , s l , c l1 ,..., c ln ), where y l0 is the link value;
[0071] 3) Signature verification: The signature verifier calculates h l = H l2 (L), and determines whether formula (1) holds. If it holds, output True; otherwise, output False.
[0072] Furthermore, Zero-Knowledge Proof (ZKP) is a cryptographic concept that allows a prover to prove the truth of a statement to a verifier without revealing any other information about the statement. This means that the verifier can confirm that the prover knows a certain fact, but does not know what that fact is. The goal of ZKP is to complete authentication while protecting privacy, so that the truth of the proof can be confirmed without revealing detailed information.
[0073] For further optimized solutions, ZKP includes interactive zero-knowledge proof and non-interactive zero-knowledge proof. The difference between non-interactive zero-knowledge proof and interactive zero-knowledge proof is that it completes the entire proof process within a single communication round, without the need for multiple rounds of interaction between the prover and the verifier, and has high execution efficiency. The technologies for implementing non-interactive zero-knowledge proof include zero-knowledge scalable non-interactive proof zk-SNARKs technology and non-interactive zero-knowledge proof FSZKP based on the Fiat–Shamir transform. This invention uses FSZKP to hide the user's public key, and the specific solution is as follows:
[0074] 1) Generation of ZKP: For the secret v, calculate y = g v , and randomly select r ∈ Z q , calculate t = g r , calculate c = H(t), and calculate s = cv + r. Finally, the user sends y = g v and proof = (t, s) to the verifier, where proof = (t, s) is the zero-knowledge proof of v;
[0075] 2) Verification of ZKP: The verifier calculates c = H(t), and verifies whether g s = y c t holds. If it holds, it indicates that the prover is the holder of v.
[0076] For further optimized solutions, Pederson commitment can prove the existence and correctness of certain values while maintaining concealment. This invention is used to hide user attributes and achieve selective disclosure of attributes. A commitment protocol involves two participants: the committer and the acceptor. It includes two stages, the "commitment stage" and the "reveal stage". The specific solution is as follows:
[0077] 1) Commitment stage: To submit a value a ∈ Z q , the user uniformly and randomly selects x ∈ RZ q , calculate the commitment Commit = (g a ·h r mod p), where h = (g x mod p);
[0078] 2) Revelation stage: The user reveals a and r, and the verifier verifies that Commit = (g a ·h r mod p).
[0079] Furthermore, for the optimized scheme, the cryptographic accumulator can efficiently prove whether an element exists in a set. Based on different cryptographic tools, cryptographic accumulators can be divided into accumulators based on the RSA system, accumulators based on bilinear maps, and accumulators based on Merkle hash trees. The present invention adopts a dynamic accumulator based on bilinear maps. The dynamic accumulator can be used to prove whether a certain variable is included in a variable set. If not, the variable can be dynamically added to the set. If included, the variable can be dynamically deleted from the set. The specific operation steps are as follows:
[0080] 1) Generation of the accumulator: First, the verifier randomly selects y ∈ Z q , and calculates Secondly, the verifier selects n numbers k j ∈ Z q , j = 1, …, i, … n, and generates the set (k 1 , …, k i , …, k n ), and at the same time the verifier selects g ∈ G 1 , and calculates Again, the verifier selects k i ∈ (k 1 , …, k i , …, k n ), and calculates Finally, obtain the accumulator parameters
[0081] 2) Verification of the accumulator: Take the system parameters, the accumulator parameters and the (k i , w i ) of this service as input parameters, and verify whether the equation holds. If it holds, it proves that the prover is included in the set (k 1 , …, k i , …, k n ), otherwise it is not included;
[0082] 3) Dynamic deletion of the accumulator: The verifier calculates and Δnew As a new accumulator parameter At this time, the prover uses the original (k i , w i ) will not be able to make the equation hold, that is, the deletion of the variable is completed. In addition, if other services k j≠i ∈(k 1 ,…, k i ,…, k n ) want to make the equation hold, they need to update their original w j to be:
[0083]
[0084] Furthermore, as Figure 1 shown, the system architecture model of this digital identity management and authentication scheme mainly has three system roles:
[0085] 1) User: The user is the holder of the private digital identity. The user needs to apply to the identity verifier to authenticate the authenticity of the digital identity and request services from the service provider without revealing their extra attributes and behaviors. In this system, the digital identity management contract (DIMC) address is used as the user's digital identity identifier, hiding the real public key, decoupling the attributes from the public key, and storing them in the digital identity attribute contract (DIAC). At the same time, DIMC can also point to the digital identity control contract (DICC) to implement the call of relevant functional contracts. The specific digital identity contract architecture is as Figure 2 shown.
[0086] 2) Identity Verifier (IV): The identity verifier is the key role to ensure the association between the user's private digital identity and the real identity in reality. While ensuring the authenticity of the identity information on the chain, it also ensures the anonymity of its own identity. It can also call relevant functional contracts such as the identity revocation contract (ID_Revoke), the identity recovery contract (ID_Recover), etc. to perform active and passive revocation and flexible recovery of the user's digital identity.
[0087] 3) Service Provider (SP): The service provider is the authorization agency for services. After receiving the privacy credentials submitted by the user, it uses relevant smart contracts such as the IDP signature verification contract (IDP_Verify), the attribute commitment verification contract (Commit_Verify), and the revocable credential verification contract (RC_Verify) to verify the user on the chain and authorize services for the verified users.
[0088] The basic implementation process of this system is as follows:
[0089] Ⅰ) Digital identity authentication: First, the User submits all real physical credentials, attribute values, their random numbers, and the digital identity address Addr_DIMC to the IV. The IV reads the attribute commitment Commit through the smart contract, and after verifying its legality and validity, performs a linkable ring signature Sig l ,
[0090] and issues a revocable credential (k i , w i ) to the user. At the same time, the key key of the AES symmetric encryption algorithm is calculated AES . Then, Sig l is written into the IDP signature field of the DIMC, associating the linkable value and the commitment <y l0 , Commit> and writing it into the LinkableValue_Commit contract. After that, the user's revocable credential and key AES are sent to the user;
[0091] Ⅱ) Request for service: The User provides the attributes required for applying for the service, their random numbers (selective disclosure), the remaining attributes, random numbers, the revocable credential before and after AES encryption, and Addr_DIMC to the SP. After the SP calls the smart contract to perform attribute commitment, signature, and credential verification, it provides the service to the User;
[0092] Ⅲ - Ⅴ) Active and passive revocation: When the user violates regulations during the use of the service or the contract expires, the SP broadcasts AES_Encrypt(key AES , (k i , w i )) to request the revocation of the user's credential. The correct IV decrypts to obtain the corresponding revocable credential and then calls the identity revocation contract (ID_Revoke) to revoke the service credential. After revocation, it is also necessary to obtain the linkable value y l0 from the local and find the corresponding commitment value Commit in the LinkableValue_Commit contract. Finally, it broadcasts to other identity verifiers that "there is a malicious user, and its commitment value is Commit". The user can request the restoration of the credential through education or renewal. Similarly, when the user's information or behavioral privacy is threatened by the SP, the user can also actively apply to the IV to revoke the service credential;
[0093] Ⅵ) Identity restoration: When the user loses the private key, the user can independently request identity restoration, call the digital identity restoration contract (ID_Recover), and the group of identity verifiers performs a multi-signature to decide whether to agree to the user's retrieval of the identity.
[0094] As shown in the above process, in the process of the system implementing interaction, both IV / SP use the contract address to obtain some user information through the smart contract, rather than directly submitting all information by the user. If the user directly submits all information, these information will be permanently recorded on the blockchain and may be accessed or used by unauthorized third parties. Through the contract address, only authorized entities can access user information, improving the security of digital identities. Moreover, decentralized identity management can be achieved by managing information through the contract, and cross-platform authentication is made more convenient by accessing information through the contract address.
[0095] The present invention uses the smart contract address Addr_DIMC as the identity identifier, hiding the public key pk of the real identity u , in addition, a privacy public key can also generate different anonymous identities by changing the corresponding random number δ (as Figure 2 shown, changing the random number δ to generate different anonymous identities pk u ∥δ 1 、pk u ∥δ 2 、pk u ∥δ 3 etc.), and thus create identities with multiple different contract addresses Addr_DIMC, which means that users can use different contract addresses in different scenarios, making it difficult for attackers to associate these behaviors with the same identity, thereby achieving a certain degree of anonymity. For users, they can create new contract addresses as needed for different purposes without having to generate a new key pair for each new identity.
[0096] For a further optimized solution, the specific digital identity chain-based smart contract architecture designed by the present invention is as Figure 2As shown, it mainly includes a Digital Identity Management Contract (DIMC), a Digital Identity Attribute Contract (DIAC), a Digital Identity Control Contract (DICC), etc. As a global contract, DIMC creates DIAC and DICC for each registered user, and also records the corresponding relationship between the user's privacy public key and the IDP signature; as a user attribute storage contract, DIAC does not publicly record all user attributes, but uses Pederson commitment for hiding; as the controller of user functions, DICC manages the function contracts it owns to implement the verification, revocation, and recovery of digital identities and their information, mainly including the IDP signature verification contract (IDP_Verify), the attribute commitment verification contract (Commit_Verify), the revocable credential verification contract (RC_Verify), as well as the identity revocation contract (ID_Revoke) and the identity recovery contract (ID_Recover), etc. In this structure, the decoupling of user attributes from the main public-private key pair aims to further achieve user privacy, make the system easier to maintain and expand, and be more conducive to the realization of user identity recovery. Contract 2-6 introduces the pseudocode of several main function contracts.
[0097] In addition to the above contracts, there are many key contracts in this system, which can make the system more flexible, secure, and easy to manage and maintain. For example, the LinkableValue_Commit contract stores the linkable value y of the user l0 and the commitment Commit. When a user violates the rules, the IV can link to the user's commitment through this contract and then broadcast it to other identity verifiers to play a warning role. The IVs_PublicKey contract is used to store the public key L of the identity verification group, the System_Parames contract stores system parameters, the Malicious_Num contract stores the number of times a user violates the rules, and the Broadcast_Event contract is used for on-chain broadcasting, etc.
[0098] Furthermore, for the optimization solution, the authentication system of the present invention includes the following four core aspects:
[0099] 1) Verification of digital identity: The IV uses linkable ring signature to sign the user's digital identity to further achieve the anonymity of the IV on the premise of ensuring the authenticity and validity of the user's identity;
[0100] 2) Authentication of digital identity: The user uses the commitment mechanism to hide attributes to achieve the minimum disclosure of identity attributes during the process of applying for services from the SP;
[0101] 3) Active and passive revocation of digital identity: IV uses a cryptographic dynamic accumulator to issue a revocable credential for a user's service, ensuring that during the service process, if either the user or the SP discovers malicious behavior in the other party, the service credential of the user can be revoked actively or passively;
[0102] 4) Restoration of digital identity: First, decouple the user's identity and attributes, and then use a multi-signature mechanism to restore the digital identity lost by the user for various reasons. The relevant parameters are defined as shown in Table 1.
[0103] Table 1
[0104]
[0105] For further optimized solutions, the system initialization operation needs to be performed before digital identity verification, as follows:
[0106] Ⅰ) Generation of ring signature public key: All IVs spontaneously form a group consisting of n members, and generate a group public key L = {y l1 ,..., y ln} L = {y l1 ,..., y ln}, and publish it to the IVs_PublicKey smart contract. In addition, each IV has a blockchain anonymous account Addr_X, X ∈ [1, n], and these accounts will first be pre-set as legal accounts that can participate in multi-party voting for participating in multi-party voting and other transactions.
[0107] Ⅱ) Generation of system parameters: IVs generate system parameters and publicly publish them to the blockchain smart contract System_Parames. The initialization process is shown in Table 2.
[0108] Table 2
[0109]
[0110] After IV verifies the validity of the physical credential, it uses a linkable ring signature to sign the user's identity attributes, hiding the identity verifier on the premise of proving the authenticity and validity of the user's identity, thus avoiding user identity leakage and collusion attacks at the same time.
[0111] Specifically as follows:
[0112] Ⅰ) User initialization, read the system parameters in System_Parames Generate a private digital identity pk using non-interactive zero-knowledge proof u∥ δ and Pederson promise to generate an attribute commitment Commit(A, r). Select a member from the IVs and submit to it all physical credentials of the true identity, all attributes A of the user i and the corresponding random number r i and the identity contract address Addr_DIMC.
[0113] Ⅱ) For each IVi ∈ (1,..., n), read the commitment of the attribute from the contract. After verifying the validity of the attribute and the commitment, perform a linkable ring signature Sig l = (y l0 , s l , c l1 , …, c ln ), where y l0 is the linkable value, and write Sig l into the IDP signature of DIMC, associate the linkable value with the commitment <y l0 , Commit> and write it into the contract LinkableValue_Commit. The detailed process of identity authentication is shown in Table 3.
[0114] Table 3
[0115]
[0116]
[0117] Furthermore, for the optimized solution, the authentication of digital identity:
[0118] Adopt the Pederson commitment mechanism to hide all attributes of the user. When the user needs to apply for services from the SP, there is no need to expose all attributes. Only selectively provide the specific attributes required by the SP to achieve the purpose of selective disclosure. After successful verification, services will be provided to the user. The specific authentication process is as follows:
[0119] Ⅰ) The user provides the attributes A i required by the SP, the corresponding random number r i , the remaining attributes and random numbers and the identity address Addr_DIMD, the revocable credentials (k i , w i ) and AES_Encrypt(key AES , (k i , w i )) (the latter two will be introduced in the next core content) to the SP.
[0120] II) The SP reads the user's signature and commitment from the contracts DIMC and DIAC, and calls IDP_Verify (Contract 1) to judge the correctness of the linkable ring signature, Commit_Verify (Contract 2) to judge the consistency of attributes and commitments, and RC_Verify (Contract 3) to judge the validity of the revocable credential.
[0121] If all the judgments are correct, the service will be provided to the user. The authentication process is relatively simple, and only the relevant contracts are introduced. As shown in Table 4-6.
[0122] Table 4
[0123]
[0124] Table 5
[0125]
[0126] Table 6
[0127]
[0128] Furthermore, the optimization scheme, such as Figure 3 shown, the active and passive revocation of digital identity:
[0129] The active and passive digital identity revocation mechanism based on dynamic cryptographic accumulators can ensure that the user and the SP can effectively remove the corresponding digital identity credentials when threatened, thus maintaining user privacy and system security. In order to better implement cross-domain services, in the present invention, before each service is applied by the user, the IV needs to issue the corresponding revocable credential (k i , w i ) for the use of this SP to achieve the purpose of "one service, one credential", and the revocation of a certain service credential will not affect the execution of other services. At the same time, the present invention also adopts the AES symmetric encryption algorithm to encrypt the revocable credential in the broadcast so that only the correct IV can perform relevant operations, that is, AES_Encrypt=(key AES , (k i , w i ). The following figure is the designed active and passive revocation model:
[0130] As shown in the model diagram, the active and passive revocation process of the present invention is as follows:
[0131] I) If the user violates the regulations during the use of the service, the SP requests to revoke the user's service credential through contract broadcast;
[0132] II) The correct IV uses the key AES to decrypt to obtain (k i , w i) After that, call the contract RC_Verify to verify the validity of the certificate. If it is valid, call the identity revocation contract ID_Rrvoke to revoke the certificate;
[0133] III) IV finds the local y l0 Then find it through the LinkableValue_Commit contract <y l0 ,Commit>, and broadcast to its group that "there is a malicious user whose commitment value is Commit";
[0134] IV)IV adds 1 to the number of malicious behaviors of the user through the contract Malicious_Num, that is, N[y l0 ]=N[y l0 ]+1, passive cancellation completed.
[0135] Ⅰ-2) If a user finds that a SP is doing evil, he can actively request IV to revoke the revocable certificate corresponding to the service;
[0136] Ⅱ-2) IV calls the identity revocation contract ID_Revoke to actively revoke the certificate.
[0137] The specific algorithm design for issuing revocable certificates and active and passive revocation is shown in Table 7:
[0138] Table 7
[0139]
[0140]
[0141] The identity revocation contract functions and designs involved are shown in Table 8:
[0142] Table 8
[0143]
[0144] Further optimization of the solution, active and passive revocation of digital identity:
[0145] First, the user identity and attributes are decoupled and stored in different contracts to simplify and accurately restore the process, and improve the efficiency and reliability of restoration. The multi-signature mechanism is further adopted to realize the digital identity restoration scheme with both security and privacy. Multi-signature is essentially a vote on transactions or proposals. When the number of signatures reaches the requirement, multi-signature can be completed. The restoration of digital identity is mainly realized by the digital identity restoration contract. The specific algorithm design of the contract is shown in Table 9.
[0146] Table 9
[0147]
[0148]
[0149] As Figure 4 shown, after creating the digital identity recovery contract, the anonymous addresses Addr_X of all members in the linkable ring signature group need to be added as legal accounts first. When the user's private key is lost, the DICC address is found through the user's own DIMC address, and the zero-knowledge proof pk new ∥δ' of the new public key is input as a parameter, and the ID_Recover contract is called to recover the digital identity.
[0150] Furthermore, the digital identity management framework designed by the present invention is different from the traditional digital identity system. Due to the characteristics of the blockchain, it provides a secure and reliable decentralized environment for the management of digital identities. The verification, revocation and recovery of digital identities, and the authorization and authentication of digital information are all realized by means of smart contracts. At the same time, the present invention adopts a variety of cryptographic fusion means to protect the privacy of users' identities, attributes and behaviors. For example, means such as zero-knowledge proof, linkable ring signature, cryptographic accumulator and multi-signature are used, so that the system can strictly speaking have characteristics such as identity privacy, attribute privacy, behavior privacy and flexible and controllable identity.
[0151] For the system, based on smart contracts, the trust cost can be reduced, fraud and errors can be reduced. At the same time, the cross-domain implementation can expand its application scope, improve interoperability, and make the system more flexible and scalable. Protecting attribute privacy and behavior privacy are important aspects of protecting personal information. Moreover, for attributes, fine-grained authorized attributes further improve the data security, and at the same time meet the user's need for data autonomy; it is crucial for users to have more autonomy and control, which can further improve the user experience, as well as the flexibility and scalability of the system, and at the same time promote the application and development of blockchain technology in real scenarios. Therefore, the following aspects are used to conduct a comparative analysis of several systems: (1) Based on smart contracts; (2) Cross-domain implementation; (3) Attribute privacy; (4) Behavior privacy; (5) Fine-grained authorization of attributes; (6) Identity controllability; (6-1) Active revocation; (6-2) Passive revocation; (7) Autonomous recovery of identity. Through the comparative analysis results, it can be seen that the present system designs a distributed trusted digital identity management and authentication system with selective disclosure, efficient revocation and dynamic recovery based on smart contracts. Through measures such as IV anonymity, selective disclosure of attributes and zero-knowledge public keys, the privacy and security of users' identities are realized. At the same time, the introduction of dynamic accumulators and multi-signature mechanisms realizes the high flexibility and controllability of digital identities. Generally speaking, the present solution is superior to the above other solutions in terms of functions and performance.
[0152] For a further optimized solution, an ideal DIMS in the blockchain should ensure that all transactions are correctly executed and the privacy of users in all aspects cannot be leaked. Therefore, the following security constraints are analyzed, as shown in Table 10, which lists the purposes of implementing these security constraints.
[0153] Table 10
[0154]
[0155] 1) Zero-knowledge: The present invention uses the non-interactive zero-knowledge proof FSZKP
[22] based on the Fiat–Shamir transform to hide the user's public key and the Pederson commitment to hide the user's attributes to achieve zero-knowledge (the implementation algorithm can be seen in the user initialization process), and the security of both has been verified in the original literature, effectively preventing the leakage of user identity and attribute information.
[0156] 2) Minimal disclosure: The present invention uses the Pederson commitment to achieve selective disclosure of attributes. When a user requests a service, only the relevant attributes for accessing the service need to be provided, rather than all attributes. The SP can judge by calling the Commit_Verify contract (see Contract 3 for details). In addition, the SP cannot deduce all the attributes held by the user based on the user's blockchain address, realizing the principle of minimal disclosure.
[0157] 3) Unlinkability: The present invention uses a smart contract as the user's identity identifier and hides the user's public key. Moreover, multiple different contracts can be created for each public key. When the user applies for different or the same service, different contract addresses can be used, so that attackers cannot associate multiple user behaviors and thus cannot associate with the user's real identity.
[0158] 4) Identity controllability: If a user violates the rules and acts maliciously, the SP needs to control the user's continued use of the service in some way to prevent malicious users from causing losses to the system; if a user perceives that the system poses a threat to the privacy of their identity and behavior, they need to actively terminate the service in some way. The cryptographic dynamic accumulator used in the present invention can easily solve this security problem. According to the characteristics of the dynamic accumulator, by updating the accumulator value the revocation function of the digital identity can be realized (for the specific implementation, see the algorithm design of the active and passive revocation module of the digital identity and the contract ID_Revoke). When the user actively requests the IV to revoke a service credential, the SP broadcasts the request to the correct IV to passively revoke the service credential. After the credential is revoked, the user can restore the service credential through learning and renewal, that is, the flexible controllability of the digital identity is realized.
[0159] 5) Collusion attack: The present invention utilizes the linkable ring signature scheme of Liu and Wong
[16] (for the specific implementation details, refer to the algorithm design of digital identity authentication). This scheme has a relatively low computational complexity, and its security is based on the discrete logarithm problem, and it has been proven to be secure in the random oracle model. This scheme hides the real authenticator within a group, and members may not be aware at all that they are recruited into this group. It allows group members to sign messages on behalf of the group, such that the signature does not reveal the identity of the group members, thereby achieving anonymity and resisting collusion attacks.
[0160] 6) Replay attack: If an attacker intercepts the attribute A submitted by the user in the previous service i , AES_Encrypt, the revocable credential of this service, and the identity address, and sends them to the SP to request service again. When the SP conducts identity verification, it will be found that the equation does not hold, that is, the revocable credential has been revoked. This process is implemented by the contract RC_Verify. Therefore, the present invention can resist replay attacks.
[0161] Furthermore, in the optimization scheme, the system was implemented using the Python language in the environment of virtual machine Ubuntu22.04.2, Intel(R) Core(TM) i5-1035G1 CPU (1.19 GHz), 20 GB RAM, and NVIDIA GeForce MX250. During the implementation process, a decentralized distributed application Dapp was constructed using Python 3.0+ based on the Python-based alt_bn128 elliptic curve library + Web3.Py, and a smart contract was constructed using Remix+Solidity+the precompiled and extended Ethereum alt_bn128 elliptic curve operation library. The smart contract was deployed to the local private blockchain using Ganache, and the transactions and state changes on the blockchain were simulated.
[0162] Furthermore, in the optimization scheme, Gas is a unit for measuring the execution cost of smart contracts in the Ethereum network. The design purpose of Gas is to ensure the stability and security of the network and prevent malicious users from abusing resources. Therefore, the Gas value can be used to reflect the resource consumption when deploying and executing smart contracts. The smart contracts designed in the present invention have all been implemented using Solidity. The availability of the present invention was evaluated by compiling and deploying the smart contracts in the Remix-IDE environment.
[0163] The evaluation time was April 5, 2024, and the Gas price was 15*10^9 Wei / Gas. According to Figure 5As shown in the diagrams, among the several core contracts involved in this system, the resource consumption of the digital identity recovery smart contract is relatively large, reaching the million level. Although its consumption is large, the possibility of users losing their identities is small. Therefore, the identity recovery contract is rarely called in real scenarios and will not cause much trouble to the implementation of the solution. Except for the operations of the identity recovery contract, the gas costs of the remaining key function contracts are low, indicating that the present invention has a certain feasibility in implementation.
[0164] Furthermore, for the optimized solution, the execution time was evaluated: The execution times of the above-mentioned core functions and the sub-steps included therein on the Dapp were respectively tested, and the test results are as Figure 6 shown in Table 11.
[0165] Table 11
[0166]
[0167] From Figure 5 it can be seen that the authentication and revocation steps are more time-consuming compared to other steps. As can be seen from Table 11, the time consumption of Authentication-II and Revocation-II / III / II-2 accounts for the main part. Through the previous introduction, it can be known that smart contracts are called during these operation processes. For example, Authentication-II calls multiple smart contracts such as the IDP signature verification contract, the attribute commitment verification contract, and the revocable credential contract, and Revocation-II / III / II-2 calls contracts such as digital identity revocation. And some parameters are not directly submitted by the user but are read by the SP from relevant smart contracts after submitting the address. The above processes involve operations such as alt_bn128 elliptic curve pairing and addition on the chain, but have the advantages of decentralization, openness, transparency, and resistance to single-point failures. Therefore, it can be regarded as an exchange of security and efficiency of the system assisted by the blockchain.
[0168] Since the present invention introduces linkable ring signatures, that is, the identity verifier consists of multiple group members, different numbers of group members will affect the execution time of related steps. For example, the verification contract of linkable ring signatures and the multi-signature contract for digital identity recovery. In this regard, when the number of group members changes from 10 to 80, the changes in the execution times of the above two contracts were tested. From Figure 6 it can be seen that the execution time of the signature verification contract increases with the increase of the number of group members, but is still less than 1.5 seconds, while the execution time of the identity verification contract decreases slightly with the increase of members. In real scenarios, the number of group members will not exceed the maximum experimental data. Therefore, even if the number of group members in the system increases, it does not affect the system efficiency.
[0169] In the present invention, a cross - domain digital identity based on smart contracts is studied, and a digital identity scheme with selective disclosure, efficient revocation, and dynamic recovery is realized. Smart contracts are used as identity identifiers, non - interactive zero - knowledge proofs are used to hide digital public keys, and multiple different contract - address identities can be created from one public key to achieve unlinkability of behaviors. Smart contracts are used to store user identities and attributes and decouple them. To achieve minimum disclosure, Pederson commitments are used to hide attributes, initially giving users control over their digital identities. Then, the verifier signs the attribute commitments using linkable ring signatures to anonymize the verifier on the premise of verifying the authenticity and credibility of the digital identity. At the same time, whenever a user applies for a service, the verifier issues a revocable credential, and a dynamic accumulator is used to achieve two - way revocation of the digital identity. The AES encryption algorithm is introduced to further promote the implementation of passive revocation. To further achieve flexible control of their digital identities by users, a digital identity recovery scheme - multi - signature is realized. In addition, detailed comparisons are made with well - known schemes in many aspects. It is analyzed that the system implemented in this paper realizes more and more effective functions and has done sufficient work in terms of security and privacy. Moreover, security proofs are added to formally demonstrate that the system has certain capabilities in zero - knowledge, minimum disclosure, unlinkability of behaviors, identity controllability, collusion - resistant attacks, and replay - resistant attacks. Finally, the solution implemented based on the Dapp, Ganache test environment, and Remix - IDE compilation environment shows the feasibility of the scheme through tests on the Gas consumed by several core smart contracts, the running time of core steps and sub - steps.
[0170] In future work, it will be studied to transfer time - consuming and Gas - consuming computational operations off - chain through an oracle network in order to further save costs and improve computational speed.
[0171] The above is only the preferred specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed in this application should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.
Claims
1. A distributed trusted digital identity authentication method based on smart contracts, characterized in that: include: The identity verifier uses a linkable ring signature to sign the user's digital identity, verifying the authenticity of the user's digital identity, the anonymity and auditability of the verifier; The user uses the contract address as the identity identifier and uses non-interactive zero-knowledge proof to hide the public key. The user applies to the service provider for digital identity authentication with minimal disclosure of identity attributes through a commitment mechanism to hide the attributes. The identity verification provider uses a cryptographic dynamic accumulator to issue revocable credentials for user services. When either the user or the service provider finds that the other party has malicious behavior during the service process, the user service credentials will be actively or passively revoked; Decouple the user's identity and attributes, and use a multi-signature mechanism to recover the loss of the user's digital identity; The verification of the authenticity of the user's digital identity, the anonymity and auditability of the verifier also includes performing a system initialization operation; The process of the system initialization operation includes: Based on the group consisting of n identity verifiers, a group public key L = {y l1 ,...,y ln }, and publish it to the IVs_PublicKey smart contract; preset each identity verifier's blockchain anonymous account Addr_X,X∈[1,n] as a legal account that can participate in multi-party voting to participate in multi-party voting affairs; The authenticator generates system parameters It is publicly published to the blockchain smart contract System_Parames. After verifying the validity of the physical credential, the identity verifier uses a linkable ring signature to sign the user's identity attributes. On the premise of proving that the user's identity is authentic and valid, the identity verifier is hidden; The process by which the authenticator uses a linkable ring signature to sign the user's identity attributes after verifying the validity of the physical credential includes: All identity verification members i=1,...,n in the group randomly select their own private key x li ∈Z ql , and generate the group public key L = {y l1 ,...,y ln },in For a message m∈{0,1} * , anonymous signer i calculates Randomly select r l ∈Z q ,c lj ∈Z q ,j=1,…,n,j≠i, then find c li , so that formula (1) holds true, wherein the formula expression of formula (1) is: Get c li Then, calculate s l =r l -c li x li modq li , and obtain the signature value Sig1 = (y l0 ,s l ,c l1 ,...,c ln ), where y l0 is the link value; The signature verifier calculates h l =H l2 (L), and judge whether formula (1) is true, if true, output True, otherwise output False; The process of hiding the identity of the authenticator includes: Read system parameters in System_Parames Using non-interactive zero-knowledge proof to generate private digital identity pk u ∥δ and Pederson commitment generate attribute commitment Commit(A,r), select a member from the authenticator and submit all physical credentials of the real identity and all attributes A of the user to it i and the corresponding random number r i And the identity contract address Addr_DIMC; The authenticator reads the commitment of the attribute from the contract, verifies the validity of the attribute and the commitment, and then performs a linkable ring signature Sig l =(y l0 ,s l ,c l1 ,…,c ln ), where y l0 For linkable values, Sig l Written in the IDP signature of DIMC, associate the linkable value with the commitment <y l0 ,Commit> and write it into the contract LinkableValue_Commit; Using non-interactive zero-knowledge proof to generate private digital identity pk u The process of generating attribute commitment Commit(A,r) from ∥δ and Pederson commitment includes: Define secret v, calculate y=g v , and randomly select r∈Z q , calculate t = g r , c = H(t) and s = cv + r; then the user sets y = g v and proof = (t, s) are sent to the authenticator, where proof = (t, s) is a zero-knowledge proof of v; The authenticator calculates c = H(t) and verifies g s =y c Whether t holds true, if it holds true, it means that the authenticator is the holder of the secret v; The identity verifier uses a linkable ring signature to sign the user's digital identity. The process of verifying the authenticity of the user's digital identity, the anonymity and auditability of the verifier includes: The user submits the real physical credential, attribute value and its random number, and digital identity address Addr_DIMC to the identity verifier, who reads the attribute commitment Commit through the smart contract, verifies the legitimacy and validity, and then performs a linkable ring signature and issues a revocable credential (k i ,w i ), and calculate the key of the AES symmetric encryption algorithm AES , then write the linkable ring signature into the IDP signature field of the DIMC, associating the linkable value and attribute commitment <y l0 ,Commit> and write the LinkableValue_Commit contract, then the user can revoke the certificate, key AES Send to user; The digital identity authentication process includes: The user provides the required attribute A to the service provider i , corresponding to the random number r i , other attributes and Random numbers and Identity address Addr_DIMD, revocable credentials (k i ,w i ) and AES_E ncrypt(key AES ,(k i ,w i )); The service provider reads the user signature and commitment from the contracts DIMC and DIAC, calls the IDP_Verify contract to determine the correctness of the linkable ring signature, calls the Commit_Verify contract to determine the consistency of the attributes and commitments, and calls the RC_Verify contract to determine the validity of the revocable certificate. If all judgments are correct, the service is provided to the user.
2. A distributed trusted digital identity authentication method based on smart contracts according to claim 1, characterized in that: The process of proactively revoking a user's service credentials includes: When a user violates the rules during the use of the service or the contract expires, the service provider broadcasts AES_E ncrypt (key AES ,(k i ,w i ))Request to revoke user credentials, the correct authenticator passes key AES Decrypted to obtain the corresponding revocable certificate (k i ,w i ) and then call the contract RC_Verify to verify the revocable certificate (k i ,w i ) is valid, if it is valid, the identity revocation contract ID_Rrvoke is called to revoke the service certificate; Get the linkable value y from the local after revocation l0 And find from the LinkableValue_Commit contract <y l0 ,Commit>, obtain the corresponding commitment value Commit, and broadcast to other identity verifiers "there is a malicious user, and its commitment value is Commit", the identity verifier adds 1 to the number of malicious behaviors of the user through the contract Malicious_Num, that is, N[y l0 ]=N[y l0 ]+1, passive cancellation completed.
3. A distributed trusted digital identity authentication method based on smart contracts according to claim 1, characterized in that: The process of proactively revoking a user's service credentials includes: When a user finds that the privacy of user information or behavior is threatened by the service provider, the user actively requests the identity verification provider to revoke the revocable credentials corresponding to the service; The identity authenticater calls the identity revocation contract ID_Revoke to actively revoke the revocable credential.
4. A distributed trusted digital identity authentication method based on smart contracts according to claim 1, characterized in that: The process of decoupling the user's identity and attributes and using a multi-signature mechanism to recover the loss of the user's digital identity includes: Create a digital identity recovery contract and add the anonymous address Addr_X of all members in the linkable ring signature group as a legitimate account; When a user loses his private key, he can find the DICC address through his own DIMC address and use the zero-knowledge proof pk new ∥δ' is used as a parameter input to call the digital identity recovery contract ID_Recover. The identity verification group performs multiple signatures to decide whether to agree to the user's identity retrieval, thus realizing the identity recovery requested autonomously.