Decentralized identity authentication method combining Merkel tree and zero-knowledge proof and related equipment

Abstract

The invention discloses a decentralized identity authentication method and related equipment in combination with a Merkel tree and zero-knowledge proof. The method comprises the following steps: generating an initial Merkel proof through an identity provider; zero-knowledge proof is generated through a zero-knowledge proof module; requesting to obtain an initial Merkel proof corresponding to a user from an identity provider through an authenticator; the authenticator performs first identity authentication on the user according to the initial Merkel proof, and if the first identity authentication of the user is successful, the authenticator performs second identity authentication on the user according to the zero-knowledge proof; and if the second identity authentication of the user is successful, generating an identity authentication success result, and returning the identity authentication success result to the user. According to the method, the integrity and verifiability of data can be improved, the risks of fraud and identity embezzlement are reduced, a novel attack mode is effectively resisted, higher-level data security characteristics are realized, user privacy protection is greatly enhanced, and the method can be widely applied to the technical field of network security.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to a decentralized identity authentication method combining a Merkle tree and zero-knowledge proof and related equipment. BACKGROUND

[0002] In the digital era, identity authentication and data security are of great importance. With the rapid development of information technology, network security problems are increasingly prominent, especially in the field of identity authentication, which faces constantly evolving attack methods. However, most traditional identity authentication systems rely on centralized databases to store user identity data, and only use simple hash verification or signature mechanisms to ensure data validity. This approach not only makes it difficult to quickly verify whether the data has been tampered with, but also, once the centralized storage node is attacked, the data integrity will be directly compromised, thereby significantly increasing the risk of fraud and identity theft. Moreover, traditional identity authentication systems usually require users to provide real sensitive information (such as ID number, mobile phone number, and raw biometric data) to complete identity verification. This verification mode may result in sensitive information being stolen during transmission or storage, further increasing the risk of identity theft.

[0003] In summary, the technical problems in the related art need to be improved. SUMMARY

[0004] Embodiments of the present application aim to at least partially address one of the technical problems in the related art. To this end, the main purpose of the embodiments of the present application is to propose a decentralized identity authentication method combining a Merkle tree and zero-knowledge proof and related equipment, which can improve the integrity and verifiability of data, reduce the risk of fraud and identity theft, effectively resist new attack methods, achieve higher data security features, and greatly enhance user privacy protection.

[0005] To achieve the above-mentioned purpose, one aspect of the embodiments of the present application proposes a decentralized identity authentication method combining a Merkle tree and zero-knowledge proof, applied to a decentralized identity authentication system, the decentralized identity authentication system comprising an identity provider, a zero-knowledge proof module, and an authenticator, the method comprising the following steps: receiving a user's identity registration request, generating an initial Merkle proof through the identity provider according to the identity registration request, and storing the initial Merkle proof in a blockchain; receiving a zero-knowledge proof generation request of the user, generating a zero-knowledge proof through the zero-knowledge proof module according to the zero-knowledge proof generation request, and encapsulating the zero-knowledge proof in an identity verification request of the user; receiving the identity authentication request of the user, requesting the initial Merkle proof corresponding to the user from the identity provider according to the identity authentication request by the authenticator, so that the identity provider sends the initial Merkle proof corresponding to the user to the authenticator; performing first identity authentication on the user according to the initial Merkle proof by the authenticator, and performing second identity authentication on the user according to the zero-knowledge proof by the authenticator if the first identity authentication of the user is successful; generating an identity authentication success result if the second identity authentication of the user is successful, and returning the identity authentication success result to the user; wherein the identity authentication success result represents that the user is allowed to access target resources.

[0006] In some embodiments, the receiving of the identity registration request of the user, the generation of the initial Merkle proof by the identity provider according to the identity registration request, and the storage of the initial Merkle proof in the blockchain, comprises: receiving the identity registration request of the user by the data collection module in the decentralized identity authentication system, and sending the identity registration request to the identity provider; wherein the identity registration request includes user identity information of the user; hashing the user identity information in the identity registration request by the identity provider to obtain an identity hash value; generating an initial Merkle tree according to the identity hash value by the identity provider, and calculating an initial Merkle root of the initial Merkle tree; generating the initial Merkle proof according to the initial Merkle root by the identity provider, and storing the initial Merkle proof in the blockchain.

[0007] In some embodiments, the receiving of the zero-knowledge proof generation request of the user, the generation of the zero-knowledge proof by the zero-knowledge proof module according to the zero-knowledge proof generation request, comprises: receiving the zero-knowledge proof generation request of the user by the data collection module in the decentralized identity authentication system, and sending the zero-knowledge proof generation request to the zero-knowledge proof module; wherein the zero-knowledge proof generation request includes an identity hash value of the user; generating the zero-knowledge proof according to the identity hash value of the user by calling a zero-knowledge proof generation function by the zero-knowledge proof module.

[0008] In some embodiments, the initial Merkel proof includes the user's identity hash, initial Merkel root, and initial Merkel path, and the first authentication of the user by the authenticator based on the initial Merkel proof includes: The current Merkel tree is obtained by reconstructing the Merkel tree using the identity hash value and the initial Merkel path by the authenticator. The current Merkle root of the current Merkle tree is calculated by the certifier; The certifier compares and verifies the current Merkle root with the initial Merkle root. If the information of the current Merkle root is consistent with that of the initial Merkle root, then it is determined that the user has passed the first authentication. If the information of the current Merkle root is inconsistent with that of the initial Merkle root, then it is determined that the user has not passed the first authentication.

[0009] In some embodiments, the authentication request includes the user's public key information, and if the user's first authentication is successful, the second authentication is performed on the user by the authenticator based on the zero-knowledge proof, including: If the user's first authentication is successful, the authenticator verifies the zero-knowledge proof using the zero-knowledge proof verification function and the public key information to complete the user's second authentication.

[0010] In some embodiments, the method further includes: Dynamically monitor the user's operational behavior and network environment changes; Based on the operational behavior and the network environment change information, combined with the user's identity authentication history and the validity of zero-knowledge proof, a trust assessment result is generated; The user's resource access permissions are dynamically adjusted based on the trust assessment results.

[0011] To achieve the above objectives, another aspect of this application proposes a decentralized identity authentication device combining Merkle trees and zero-knowledge proofs, applied to a decentralized identity authentication system. The decentralized identity authentication system includes an identity provider, a zero-knowledge proof module, and an authenticator. The device includes the following modules: The Merkel proof generation module is used to receive a user's identity registration request, generate an initial Merkel proof based on the identity registration request through the identity provider, and store the initial Merkel proof in the blockchain; A zero-knowledge proof generation module is used to receive the user's zero-knowledge proof generation request, generate a zero-knowledge proof according to the zero-knowledge proof generation request, and encapsulate the zero-knowledge proof in the user's authentication request. The Merkel proof acquisition module is used to receive the user's authentication request, and through the authenticator, request the identity provider to obtain the initial Merkel proof corresponding to the user based on the authentication request; so that the identity provider sends the initial Merkel proof corresponding to the user to the authenticator; The dual-proof verification module is used to perform a first authentication of the user by the authenticator based on the initial Merkel proof. If the first authentication of the user is successful, the authenticator performs a second authentication of the user based on the zero-knowledge proof. An identity authentication result generation module is used to generate an identity authentication success result if the user's second identity authentication is successful, and return the identity authentication success result to the user; wherein, the identity authentication success result indicates that the user is allowed to access the target resource.

[0012] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0014] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a decentralized identity authentication method and related equipment combining Merkle trees and zero-knowledge proofs. This solution is applied to a decentralized identity authentication system, which includes an identity provider, a zero-knowledge proof module, and an authenticator. The method involves receiving a user's identity registration request, generating an initial Merkle proof based on the registration request, and storing the initial Merkle proof in the blockchain; receiving a user's zero-knowledge proof generation request, generating a zero-knowledge proof based on the request, and encapsulating the zero-knowledge proof in the user's identity verification request; receiving a user's identity verification request, and requesting the identity provider to obtain the user's corresponding initial Merkle proof based on the verification request; enabling the identity provider to send the user's corresponding initial Merkle proof to the authenticator; the authenticator performing a first identity verification on the user based on the initial Merkle proof; if the first identity verification is successful, performing a second identity verification on the user based on the zero-knowledge proof; if the second identity verification is successful, generating an identity authentication success result and returning it to the user; wherein, the identity authentication success result indicates that the user is allowed to access the target resource. This application's embodiments, by generating Merkle proofs using Merkle trees, can improve data integrity and verifiability, reducing the risk of fraud and identity theft. Simultaneously, Merkle trees support a rapid data verification process, thereby improving verification efficiency. Furthermore, by utilizing zero-knowledge proof technology to generate zero-knowledge proofs, users can prove their identity without disclosing sensitive information, effectively resisting new attack methods, including advanced persistent threats. By combining Merkle proofs and zero-knowledge proofs to verify user identities, more advanced data security features can be achieved, greatly enhancing user privacy protection. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the steps of a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs, as provided in an embodiment of this application. Figure 2 This is a flowchart illustrating a decentralized identity information storage method based on Merkle trees provided in an embodiment of this application. Figure 3 This is a flowchart illustrating a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in an embodiment of this application. Figure 4 This is a schematic diagram of the structure of a decentralized identity authentication device combining Merkle trees and zero-knowledge proofs provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] (1) Zero-knowledge proof: Zero-knowledge proof is a cryptographic protocol that allows one party to prove to another that a statement is true without providing any information other than the truth of the statement.

[0023] (2) Merkle tree: A Merkle tree, also known as a hash tree, is a binary tree in which each leaf node contains the hash value of a data block, and each non-leaf node contains the hash value of its child nodes.

[0024] (3) Combination of Zero-Knowledge Proofs and Merkle Trees: Zero-knowledge proofs and Merkle trees can be used in combination to achieve more advanced security features. In the embodiments of this application, in the identity authentication system, Merkle trees can be used to store user identity information, and then zero-knowledge proofs can be used to verify the user's identity without exposing the user's specific information. This ensures both data integrity and user privacy.

[0025] In the digital age, identity authentication and data security have become paramount. With the rapid development of information technology, cybersecurity issues are becoming increasingly prominent, especially in the field of identity authentication, which faces constantly evolving attack methods. However, traditional identity authentication systems mostly rely on centralized databases to store user identity data, ensuring data validity only through simple hash verification or signature mechanisms. This approach not only makes it difficult to quickly verify whether data has been tampered with, but also directly compromises data integrity if the centralized storage node is attacked, leading to a significant increase in the risk of fraud and identity theft. Furthermore, traditional identity authentication systems typically require users to provide genuine sensitive information (such as ID card numbers, mobile phone numbers, and raw biometric data) to complete identity verification. This verification model may result in the theft of sensitive information during transmission or storage, further exacerbating the risk of identity theft.

[0026] In view of this, this application provides a decentralized identity authentication method and related device combining Merkle trees and zero-knowledge proofs. This solution is applied to a decentralized identity authentication system, which includes an identity provider, a zero-knowledge proof module, and an authenticator. The system receives a user's identity registration request, and the identity provider generates an initial Merkle proof based on the registration request and stores it in the blockchain. It then receives a user's zero-knowledge proof generation request, and the zero-knowledge proof module generates a zero-knowledge proof based on the request and encapsulates it within the user's identity verification request. Finally, the authenticator receives a user's identity verification request and requests the identity provider to obtain the user's corresponding initial Merkle proof. The identity provider then sends the user's corresponding initial Merkle proof to the authenticator. The authenticator performs a first identity verification on the user based on the initial Merkle proof. If the first identity verification is successful, the authenticator performs a second identity verification on the user based on the zero-knowledge proof. If the second identity verification is successful, an identity authentication success result is generated and returned to the user. The identity authentication success result indicates that the user is allowed to access the target resource. This application's embodiments, by generating Merkle proofs using Merkle trees, can improve data integrity and verifiability, reducing the risk of fraud and identity theft. Simultaneously, Merkle trees support a rapid data verification process, thereby improving verification efficiency. Furthermore, by utilizing zero-knowledge proof technology to generate zero-knowledge proofs, users can prove their identity without disclosing sensitive information, effectively resisting new attack methods, including advanced persistent threats. By combining Merkle proofs and zero-knowledge proofs to verify user identities, more advanced data security features can be achieved, greatly enhancing user privacy protection.

[0027] This application provides a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs, relating to the field of network security technology. This decentralized identity authentication method can be applied to terminals, servers, or software running on either terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs, but is not limited to the above forms.

[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0029] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0030] Please seeFigure 1 , Figure 1 This is an optional flowchart of a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in an embodiment of this application. Figure 1 The method described above is applied to a decentralized identity authentication system, which includes an identity provider, a zero-knowledge proof module, and an authenticator. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0031] Step S101: Receive the user's identity registration request, generate an initial Merkel proof based on the identity registration request through the identity provider, and store the initial Merkel proof in the blockchain; In some embodiments, step S101 may include: receiving a user's identity registration request through a data collection module in a decentralized identity authentication system, and sending the identity registration request to an identity provider; wherein the identity registration request includes the user's identity information; hashing the user's identity information in the identity registration request through the identity provider to obtain an identity hash value; generating an initial Merkle tree through the identity provider based on the identity hash value, and calculating the initial Merkle root of the initial Merkle tree; generating an initial Merkle proof through the identity provider based on the initial Merkle root, and storing the initial Merkle proof in the blockchain.

[0032] The data collection module is used to collect data in a decentralized identity authentication system.

[0033] The identity registration request may include, but is not limited to, the user's identity information ID {user}. The identity information ID {user} may include, but is not limited to, personal data, authentication records, attribute proofs, etc.

[0034] In step S101, the specific implementation process of generating the initial Merkel proof and storing it in the blockchain is as follows: First, users submit an identity registration request to the decentralized identity authentication system. The system receives the registration request through its data collection module and forwards it to the identity provider (IdP) to submit their identity information ID{user}. Specifically, users prepare their personal identity information ID{user} and submit it to the IdP via online forms, mobile applications, or physical documents. During the submission process, information security is paramount; therefore, transmission is conducted through encrypted channels such as HTTPS to prevent data interception or tampering. After receiving a user's identity information ID{user}, the identity provider IdP will first perform a preliminary verification of the ID{user} to ensure the integrity and correct format of the information. The verified ID{user} will then be stored in the database. Sensitive information within the ID{user} will be encrypted to protect user privacy. This preliminary verification refers to the system validating the data format of the user-uploaded information (the data format is system-defined and will not be elaborated here). Following the preliminary verification, the identity provider IdP will send a confirmation message to the user to complete the registration process or conduct further identity verification. This step not only ensures the authenticity of the user's identity but also protects the user's privacy and information security.

[0035] Then, the identity provider IdP hashes the initially verified identity information ID{user} to obtain the hash calculation result, i.e., the identity hash value H{IDuser} = H(ID{user}). Specifically, in this process, the identity provider IdP first receives the identity information ID{user} submitted by the user securely; then, it encrypts the identity information ID{user} using a secure hash algorithm (such as SHA-256) to generate a unique identity hash value H{IDuser} = H(ID{user}). This identity hash value H{IDuser} is one-way, ensuring the security of the original identity information and preventing the data from being reverse-engineered. Next, the identity provider IdP stores the generated identity hash value H{IDuser} in a secure environment and ensures that it is associated with the user's account or other authentication data, while protecting the user's privacy. This identity hash value H{IDuser} will be used in subsequent authentication processes, such as in conjunction with zero-knowledge proofs or as part of a Merkle tree, to ensure the security and effectiveness of authentication. After hashing is complete, the identity provider (IdP) sends a confirmation message to the user, informing them that their identity information has been securely processed and can be used for further authentication steps. This step not only ensures the authenticity of the user's identity but also protects the user's privacy and information security.

[0036] Next, the identity provider IdP uses the identity hash value H{IDuser} to generate a Merkle tree and calculates the Merkle root M{root}. Specifically, the identity provider IdP first uses the user's identity information hash value H{IDuser} as the leaf node of the Merkle tree, and generates the root hash of the entire tree, namely the Merkle root M{root}, through a series of hash calculations. This Merkle root M{root} is the digital fingerprint of the Merkle tree, representing the aggregate hash of all data in the tree, ensuring data integrity and security. Then, the identity provider IdP stores the Merkle root M{root} in a secure environment and can generate a Merkle proof Proof{Merkle}, allowing users to prove the location of their data in the Merkle tree without revealing their identity information. In essence, assuming a new target node is added to the tree, there will be a path from the root node to this target node; this proof is the proof of the path, proving the existence of this node and its presence in the tree. This step not only improves the security and efficiency of authentication, but also provides users with a privacy-protecting authentication method through Merkle proof, thus completing the preparatory work for the authentication process.

[0037] Subsequently, the identity provider IdP generates a Merkle proof, Proof{Merkle}, proving the position of the identity hash value H{IDuser} in the Merkle tree. Specifically, the identity provider IdP uses the hash values ​​of all sibling nodes on the path from the identity hash value H{IDuser} to the Merkle root M{root} to create a Merkle proof, Proof{Merkle}. This proof allows users to demonstrate the legitimacy and integrity of their identity information to the verifier without revealing their specific identity information. The generation and use of Merkle proofs not only protect user privacy but also improve the efficiency and security of identity verification by providing a secure and unforgeable verification method.

[0038] Finally, the Identity Provider (IdP) sends the identity hash value H{IDuser} and the Merkle proof Proof{Merkle} to the blockchain, ensuring the immutability, traceability, and anonymity of the identity information, thus improving the system's security and trustworthiness. During transmission, the Identity Provider (IdP) uses an encrypted channel to protect the data, preventing interception or tampering. This step not only ensures the authenticity and integrity of the user's identity information but also provides users with a secure and reliable authentication and data storage solution, greatly enhancing the security and trustworthiness of the entire authentication system.

[0039] Step S102: Receive the user's zero-knowledge proof generation request, generate a zero-knowledge proof according to the zero-knowledge proof generation request through the zero-knowledge proof module, and encapsulate the zero-knowledge proof in the user's authentication request; In some embodiments, the step of receiving a user's zero-knowledge proof generation request and generating a zero-knowledge proof based on the zero-knowledge proof generation request through a zero-knowledge proof module may include: receiving the user's zero-knowledge proof generation request through a data collection module in a decentralized identity authentication system, and sending the zero-knowledge proof generation request to the zero-knowledge proof module; wherein the zero-knowledge proof generation request includes the user's identity hash value; and calling a zero-knowledge proof generation function through the zero-knowledge proof module to generate a zero-knowledge proof based on the user's identity hash value.

[0040] Optionally, the zero-knowledge proof generation request includes the user's identity hash value.

[0041] The zero-knowledge proof generation function uses the GenerateZKP function.

[0042] In step S102, the process of generating a zero-knowledge proof by the user is as follows: The user first uses their identity information hash value H{IDuser} as the function input and calls the GenerateZKP function to generate a zero-knowledge proof pi{ZKP}. This process utilizes advanced cryptographic techniques, allowing the user to prove the authenticity of their identity without disclosing any actual identity information. In other words, the generated zero-knowledge proof considers security and uses a secure random number generation method to prevent potential security vulnerabilities. After the zero-knowledge proof is generated, the user sends it to the authenticator as part of the authentication request. This step not only demonstrates the application of technology in protecting user privacy but also reflects respect for and protection of user privacy rights. In this way, users can enjoy services while ensuring that their personal information security and privacy are effectively protected.

[0043] Step S103: Receive the user's authentication request, and have the authenticator request the identity provider to obtain the initial Merkel certificate corresponding to the user based on the authentication request; so that the identity provider sends the initial Merkel certificate corresponding to the user to the authenticator; The authentication request includes the user's public key pk{user}, zero-knowledge proof pi{ZKP}, and the user's identity hash value H{IDuser}.

[0044] The initial Merkle proof Proof{Merkle} includes the user's identity hash value H{IDuser}, the initial Merkle root M{root}, and the initial Merkle path, which is the data generated when the user registers their identity.

[0045] In this embodiment, the user first initiates an authentication request (RequestAuth) to the authenticator Auth, submitting their public key pk{user} and zero-knowledge proof pi{ZKP} to clearly state their access request for a specific service. This request is sent via a secure communication channel, such as HTTPS, to ensure the security and privacy of information transmission. After receiving the authentication request, the authenticator Auth performs a preliminary check to confirm its integrity and compliance. After verifying the integrity and compliance of the authentication request, the authenticator initiates a request to the identity provider IdP via a secure communication channel, explicitly requesting a Merkle proof associated with the user's identity information hash value H{IDuser}. After receiving the request, the identity provider IdP securely sends the user's corresponding Merkle proof Proof{Merkle} to the authenticator Auth. The authenticator Auth then verifies the received Merkle proof, ensuring that the user's submitted identity information has not been tampered with and is consistent with the information stored by IdP. This process not only ensures the authenticity of the user's identity and the security of the information but also effectively protects the user's privacy by using a Merkle proof instead of the original data. In this way, this application demonstrates the importance of combining security, privacy protection, and technological innovation in identity verification.

[0046] Step S104: The authenticator performs first authentication on the user based on the initial Merkel proof. If the first authentication of the user is successful, the authenticator performs second authentication on the user based on the zero-knowledge proof. Optionally, the initial Merkle proof Proof{Merkle} includes the user's identity hash H{IDuser}, the initial Merkle root M{root}, and the initial Merkle path, which is the data generated when the user registers their identity.

[0047] The authentication request includes the user's public key pk{user}, zero-knowledge proof pi{ZKP}, and the user's identity hash value H{IDuser}.

[0048] In some embodiments, the step of performing first authentication on a user by an authenticator based on an initial Merkle proof may include: reconstructing a Merkle tree by the authenticator based on the identity hash value and the initial Merkle path to obtain the current Merkle tree; calculating the current Merkle root of the current Merkle tree by the authenticator; comparing and verifying the current Merkle root with the initial Merkle root by the authenticator; if the information of the current Merkle root and the initial Merkle root are consistent, then the user is determined to have passed the first authentication; if the information of the current Merkle root and the initial Merkle root are inconsistent, then the user is determined to have failed the first authentication.

[0049] The first authentication refers to the process of verifying the Merkel proof.

[0050] Optionally, the current Merkle tree refers to the new Merkle tree reconstructed by the authenticator based on the identity hash value provided by the identity provider and the initial Merkle path. Similarly, the current Merkle root also refers to the newly calculated Merkle root.

[0051] During the verification process, the authenticator (Auth) uses a specific verification function (Verify {Merkle Proof) to verify the user's identity information based on the hash value H{IDuser}, Merkle root M{root}, and Merkle path (Path(H{IDuser})). Specifically, by reconstructing the Merkle tree using the initial Merkle path (Path(H{IDuser})) and the user's identity hash value H{IDuser}, and recalculating the current Merkle root M{root} of the new Merkle tree, the authenticator can verify the consistency of the information by comparing the recalculated current Merkle root with the initial Merkle root provided by the identity provider (IdP). If the recalculated current Merkle root matches the initial Merkle root provided by the identity provider (IdP), the legitimacy of the user's identity information is proven; otherwise, they do not match. Throughout the verification process, the user's original identity information is protected and does not participate in direct verification, thus ensuring privacy and security. After successful verification, the user is authenticated and can then access the corresponding service or resource; otherwise, access to the corresponding service or resource is denied. This step demonstrates the importance of combining security, privacy protection, and technological innovation in identity verification.

[0052] In some embodiments, if the user's first authentication is successful, the step of performing a second authentication on the user by an authenticator based on a zero-knowledge proof may include: if the user's first authentication is successful, the authenticator verifies the zero-knowledge proof based on the zero-knowledge proof verification function and public key information to complete the second authentication of the user.

[0053] The second authentication refers to the process of verifying zero-knowledge proofs.

[0054] In this embodiment, verification is performed using the verification function Verify{ZKP} and inputting the user's public key pk{user}. Specifically, inputting the user's public key pk{user} and a zero-knowledge proof into the Verify{ZKP} function yields the verification result. This step aims to allow users to prove the authenticity of their identity without revealing their private key or any sensitive information. Through this process, the authenticator can protect user privacy while ensuring security. If the zero-knowledge proof verification is successful, it confirms the validity of the user's identity and allows the user to access the corresponding services or resources. This step not only improves the security of identity verification but also strengthens the protection of user privacy, demonstrating a commitment to both security and privacy in the field of identity verification.

[0055] It should be noted that in this embodiment, smart contracts are used to automate the execution of authentication rules, enabling secure updates and revocations of identity information, as well as an efficient authentication process. Formal verification technology for smart contracts ensures that the business logic of the contract conforms to predefined specifications, improving system security and trustworthiness. Automated execution of smart contracts is suitable for various application scenarios requiring high security and privacy protection. The automation aspect lies in using Chainlink Automation to provide a decentralized transaction automation solution, helping smart contracts automatically execute key functions and DevOps tasks, ensuring reliability and minimizing trust, while improving cost-effectiveness.

[0056] Step S105: If the user's second authentication is successful, an authentication success result is generated and returned to the user; wherein, the authentication success result indicates that the user is allowed to access the target resource.

[0057] In this embodiment, the authenticator `Auth` makes a final authentication decision on whether to accept the user's identity based on the verification results of Merkel proofs and zero-knowledge proofs through the authentication decision function `Auth{Decision}`. The authenticator comprehensively evaluates the verification results of the two proofs to ensure the authenticity and integrity of the user's identity, while protecting the user's privacy in the process. If both proofs are successfully verified, the authenticator will output a positive authentication decision, allowing the user to access the corresponding service or resource; otherwise, it will deny the user access to the corresponding service or resource. This step is the final stage of the identity verification process, marking its end and ensuring the security, accuracy, and privacy protection of the entire identity verification process.

[0058] In some embodiments, the method may further include: dynamically monitoring user operation behavior and network environment changes; generating a trust assessment result based on the operation behavior and network environment changes, combined with the user's authentication history and the validity of zero-knowledge proofs; and dynamically adjusting the user's resource access permissions based on the trust assessment result.

[0059] Information regarding changes in the network environment may include, but is not limited to, login location, time, and network status.

[0060] In practice, data monitoring can be achieved through general-purpose open-source tools for detecting on-chain behavior of smart contracts (such as Keeper), which records on-chain information.

[0061] The system dynamically monitors user behavior and network environment changes. Based on these changes, along with the user's authentication history and the validity of zero-knowledge proofs, a trust assessment result is generated. Finally, the system dynamically adjusts the user's resource access permissions based on the trust assessment result to facilitate rapid response to authentication requests and security incidents.

[0062] In this embodiment of the application, the system also includes a dynamic identity authentication mechanism. The dynamic identity authentication mechanism refers to dynamically adjusting the identity authentication strategy and requirements according to the current network environment and user behavior patterns, and adopting multi-factor authentication methods (such as combining biometrics, device fingerprints, etc.) to enhance the security and adaptability of identity authentication.

[0063] Steps S101 to S105 as illustrated in this embodiment involve: receiving a user's identity registration request; generating an initial Merkel proof based on the identity registration request through an identity provider and storing the initial Merkel proof in the blockchain; receiving a user's zero-knowledge proof generation request; generating a zero-knowledge proof based on the zero-knowledge proof generation request through a zero-knowledge proof module and encapsulating the zero-knowledge proof in the user's identity verification request; receiving a user's identity verification request; requesting the user's corresponding initial Merkel proof from the identity provider based on the identity verification request through an authenticator; enabling the identity provider to send the user's corresponding initial Merkel proof to the authenticator; performing a first identity verification on the user based on the initial Merkel proof through the authenticator; if the user's first identity verification is successful, performing a second identity verification on the user based on the zero-knowledge proof through the authenticator; if the user's second identity verification is successful, generating an identity verification success result and returning the identity verification success result to the user; wherein, the identity verification success result indicates that the user is allowed to access the target resource. This application's embodiments, by generating Merkle proofs using Merkle trees, can improve data integrity and verifiability, reducing the risk of fraud and identity theft. Simultaneously, Merkle trees support a rapid data verification process, thereby improving verification efficiency. Furthermore, by utilizing zero-knowledge proof technology to generate zero-knowledge proofs, users can prove their identity without disclosing sensitive information, effectively resisting new attack methods, including advanced persistent threats. By combining Merkle proofs and zero-knowledge proofs to verify user identities, more advanced data security features can be achieved, greatly enhancing user privacy protection.

[0064] It is understood that in this embodiment, Merkle trees are used to construct a hierarchical structure of identity data, ensuring that the identity information of each user is linked together through hash values ​​to form a traceable and tamper-proof data chain, thereby guaranteeing the integrity and verifiability of the identity data. Zero-knowledge proof technology is adopted, allowing users to verify the authenticity of their identity by constructing a complex mathematical proof without directly disclosing personal information, thus ensuring the protection of user privacy. The decentralized identity authentication system does not rely on any centralized institution, but performs identity verification through distributed network nodes, improving the system's security and anti-attack capabilities. The decentralized identity authentication system provides users with services such as identity verification, authorization, and identity auditing, ensuring that users can perform identity authentication and access control securely and conveniently while protecting their privacy.

[0065] To explain in detail the principle of the technical solution of the present invention, the overall process of the present invention will be described below with reference to some specific embodiments. It is easy to understand that the following is an explanation of the technical principle of the present invention and should not be regarded as a limitation of the present invention.

[0066] This application provides a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs, aiming to enhance the security and privacy protection of identity verification while ensuring the efficiency of the authentication process. The decentralized identity authentication system mainly includes four underlying processing modules: a data collection module, a zero-knowledge proof module, a Merkle tree construction module, and an authentication algorithm module. The data collection module collects user identity information and related attributes, such as user identity information and behavior logs, enabling data visualization and in-depth analysis, ensuring the transparency and traceability of identity information. The zero-knowledge proof module generates and verifies zero-knowledge proofs, ensuring that users can prove their identity without disclosing specific information. The Merkle tree construction module constructs a Merkle tree containing user attributes to achieve rapid verification and data integrity protection. The authentication algorithm module executes the authentication algorithm, combining zero-knowledge proofs and Merkle trees for identity verification.

[0067] Based on these four underlying processing steps, the overall implementation process of a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in this application embodiment is as follows: Steps 11 to 16: Step 11, User Registration: Users submit their identity information and related attributes to the system, and the system uses the data collection module to record user information; Step 12, Merkle Tree Construction: Using the Merkle Tree Construction Module, the hash values ​​of user information are organized into a Merkle tree structure; where the hash value of each node is a combination of the hash values ​​of its child nodes.

[0068] Step 13, Zero-knowledge proof generation: The user uses the zero-knowledge proof module to generate a zero-knowledge proof that can verify that the user possesses certain attributes without revealing specific information.

[0069] Step 14, Identity Authentication Request: The user initiates an authentication request and provides their zero-knowledge proof; Step 15, Authentication Verification: The authentication algorithm module receives the zero-knowledge proof and compares it with the Merkle tree. The user's identity is confirmed by verifying the Merkle tree root hash value and the zero-knowledge proof. Step 16, Authentication Result Feedback: The system will provide feedback to the user on whether the authentication was successful or failed based on the authentication result.

[0070] This application's embodiments utilize zero-knowledge proofs to ensure users complete identity verification without disclosing personal information. The use of Merkle trees improves data integrity and verifiability, while also supporting a rapid data verification process.

[0071] Please see Figure 2 , Figure 2This is a flowchart illustrating a decentralized identity information storage method based on Merkle trees provided in an embodiment of this application. Figure 2 As shown, the specific implementation process of the decentralized identity information storage method based on Merkle trees is as follows: Steps 21 to 25: Step 21: The user submits their identity information ID{user} to the identity provider IdP.

[0072] In this embodiment, step 21 involves the process of a user submitting their identity information ID{user} to an identity provider IdP. The identity information ID{user} may include, but is not limited to, personal data, authentication records, attribute proofs, etc. Specifically, firstly, the user prepares their personal identity information ID{user} and submits it to the identity provider IdP via an online form, mobile application, or physical document. During the submission process, information security is paramount; therefore, transmission should be conducted through an encrypted channel such as HTTPS to prevent data interception or tampering. After receiving the user's identity information ID{user}, the identity provider IdP performs a preliminary verification to ensure the integrity and correct format of the information. The verified identity information ID{user} is then stored in the database. Sensitive information within the identity information ID{user} is encrypted to protect user privacy. The preliminary verification of the identity information ID{user} refers to the system validating the data format of the information uploaded by the user (the data format is system-defined and will not be elaborated here). After verification, the identity provider IdP sends a confirmation message to the user to complete the registration process or conduct further identity verification. This step 21 not only ensures the authenticity of the user's identity, but also protects the user's privacy and information security.

[0073] Step 22: The identity provider IdP hashes the identity information ID{user} to obtain the hash calculation result, i.e., the hash value H{IDuser}=H(ID{user}).

[0074] In this embodiment, step 22 refers to the process by which the identity provider IdP hashes the user-submitted identity information ID{user}. Specifically, in this process, the identity provider IdP first receives the user-submitted identity information ID{user} securely; then, it encrypts the identity information ID{user} using a secure hash algorithm (such as SHA-256) to generate a unique hash value H{IDuser} = H(ID{user}). This hash value H{IDuser} is one-way, ensuring the security of the original identity information and preventing data from being reverse-engineered. Next, the identity provider IdP stores the generated hash value H{IDuser} in a secure environment and ensures that it is associated with the user's account or other authentication data, while protecting the user's privacy. This hash value H{IDuser} will be used in subsequent authentication processes, such as in conjunction with zero-knowledge proofs or as part of a Merkle tree, to ensure the security and effectiveness of authentication. After completing the hashing process, the identity provider IdP sends a confirmation message to the user, informing the user that their identity information has been securely processed and can be used for further authentication steps. This step 22 not only ensures the authenticity of the user's identity, but also protects the user's privacy and information security.

[0075] Step 23: The identity provider IdP generates a Merkle tree using the hash value H{IDuser} and calculates the Merkle root M{root} of the Merkle tree.

[0076] In this embodiment, step 23 illustrates the process by which the identity provider IdP generates a Merkle tree using the user's identity information hash value H{IDuser}, and calculates the Merkle root M{root} based on the Merkle tree. Specifically, the identity provider IdP first uses the user's identity information hash value H{IDuser} as the leaf node of the Merkle tree, and generates the root hash of the entire tree, namely the Merkle root M{root}, through a series of hash calculations. This Merkle root M{root} is the digital fingerprint of the Merkle tree, representing the aggregate hash of all data in the tree, ensuring data integrity and security. Then, the identity provider IdP stores the Merkle root M{root} in a secure environment and can generate a Merkle proof Proof {Merkle}, allowing users to prove the location of their data in the Merkle tree without disclosing their identity information. It can be understood that, assuming a new target node is added to the tree, there will be a path from the root node to this target node; this proof is the proof of the path, proving the existence of this node and its presence in the tree. This step 23 not only improves the security and efficiency of authentication, but also provides users with a privacy-protecting authentication method through the Merkle proof Proof, thus completing the preparation work for the authentication process.

[0077] Step 24: Identity provider IdP generates a Merkle proof Proof{Merkle}, proving the position of hash value H{IDuser} in the Merkle tree.

[0078] In this embodiment, step 24 illustrates the process by which the identity provider IdP generates a Merkle proof, Proof{Merkle}, to demonstrate the position of the user's identity information hash value H{IDuser} in the Merkle tree. The identity provider IdP creates a Merkle proof, Proof{Merkle}, using the hash values ​​of all sibling nodes along the path from hash value H{IDuser} to the Merkle root M{root}. This proof allows the user to demonstrate the legitimacy and integrity of their identity information to the verifier without disclosing specific identity information. The generation and use of Merkle proofs not only protect user privacy but also improve the efficiency and security of identity verification by providing a secure and unforgeable verification method.

[0079] In its implementation, the identity provider (IdP) securely stores the Merkle proof (Proof{Merkle}) and transmits it to the user or other verifier when needed, thus completing a crucial step in the identity verification process while ensuring the security and privacy of user information throughout the entire process.

[0080] Step 25: The identity provider IdP sends (hash value H{IDuser}, Merkel proof Proof{Merkle}) to the blockchain to ensure the immutability and traceability of the identity information.

[0081] In this embodiment, step 25 illustrates the process by which the identity provider (IdP) sends the user's identity information hash value H{IDuser} and Merkel proof Proof{Merkle} to the blockchain. Specifically, the identity provider (IdP) first prepares this critical data (the user's identity information hash value H{IDuser} and Merkel proof Proof{Merkle}), ensuring that this critical data can be securely transmitted and stored on the blockchain. Through blockchain technology, the immutability and traceability of this data are guaranteed, enhancing the security and transparency of identity verification. Once the data is successfully written to the blockchain, it will be permanently recorded, and any authorized party can access and verify this information through the blockchain network. During transmission, the identity provider (IdP) uses an encrypted channel to protect the data, preventing interception or tampering during transmission. This step 25 not only ensures the authenticity and integrity of the user's identity information but also provides the user with a secure and reliable identity verification and data storage solution, greatly enhancing the security and trustworthiness of the entire identity verification system.

[0082] In this embodiment, the off-chain identity information storage method is implemented in Rust, using a Merkle tree structure to ensure data security and integrity. The method first hashes each identity information item, with the generated hash value serving as a leaf node of the Merkle tree. Then, through layer-by-layer hashing, a root hash representing the entire set is generated. Utilizing Rust's memory safety and high efficiency, secure data storage and management are achieved. Identity information is stored off-chain, while the root hash can interact with the blockchain when necessary, ensuring data immutability. This method not only supports rapid data retrieval and verification but also implements version control of identity information, recording the Merkle tree root hash for each version, facilitating data tracking and historical backtracking. The entire process ensures data security while providing high-performance data manipulation, making it suitable for applications with high security and retrieval speed requirements.

[0083] In summary, the identity information storage method provided in this application utilizes a cloud server to construct an efficient and secure data storage and management solution based on a Merkle tree on-chain. This method not only achieves the hashing of identity information and the construction of the Merkle tree, ensuring data integrity and verifiability, but also provides stable storage and fast access to data through the high availability and scalability of the cloud server. Furthermore, the system can store and analyze alarm logs in real time, enabling dynamic monitoring of the network environment and managing various versions of the Merkle tree, recording detailed information for each version. The system also includes a honeycomb controller, which is responsible for calling the honeycomb diagram and device linkage, as well as retrieving and calling the required honeycomb diagram version at any time, thus providing users with a flexible and reliable data access and management function. This storage method is suitable for scenarios requiring high security and fast data retrieval, greatly enhancing the security of identity information and the system's responsiveness.

[0084] Please see Figure 3 , Figure 3 This is a flowchart illustrating a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs, as provided in an embodiment of this application. Figure 3 As shown, the specific implementation process of the decentralized identity authentication method combining Merkle trees and zero-knowledge proofs is as follows: Steps 31 to 38: Step 31: User requests verification.

[0085] In this embodiment, step 31 describes the user request verification process as the initial stage of the identity authentication process. The user initiates a verification request (RequestAuth) to the authentication service (Auth), clearly stating their access requirement for a specific service. This request is sent through a secure communication channel, such as HTTPS, to ensure the security and privacy of information transmission. An identity provider (IdP) may participate in the verification as a third party to enhance trust. After receiving the verification request, the authentication service (Auth) performs a preliminary check to confirm its completeness and compliance, subsequently triggering a series of identity verification steps, such as two-factor authentication or multi-factor authentication. The user waits for a response after submitting the request. Throughout this process, the user's privacy and information security are protected to ensure the security and effectiveness of identity authentication. This process not only establishes a clear path for the user to access the service but also demonstrates respect for and protection of user rights by safeguarding user privacy and information security.

[0086] Step 32: The user generates a zero-knowledge proof.

[0087] In this embodiment, step 32 describes the process of a user generating a zero-knowledge proof, a crucial step in ensuring both secure and privacy-preserving identity verification. Specifically, the user first uses their identity information hash value H{IDuser} as input and calls the GenerateZKP function to generate a zero-knowledge proof pi{ZKP}=GenerateZKP(H{IDuser}). This process utilizes advanced cryptographic techniques, allowing the user to prove the authenticity of their identity without disclosing any actual identity information. In other words, the generated zero-knowledge proof considers security and uses a secure random number generation method to prevent potential security vulnerabilities. After generating the zero-knowledge proof, the user sends it to the authentication service as part of the identity verification request. This step not only demonstrates the application of technology in protecting user privacy but also reflects respect for and protection of user privacy rights. In this way, users can enjoy services while ensuring the effective protection of their personal information and privacy.

[0088] Step 33: The user submits proof.

[0089] In this embodiment, step 33 describes the process by which the user submits their public key pk{user} and zero-knowledge proof pi{ZKP} to the authenticator Auth. Specifically, after generating the zero-knowledge proof, the user securely sends it along with their public key to the authentication service via a secure communication channel such as HTTPS. Upon receiving this information, the authentication service uses the zero-knowledge proof to verify the user's identity without compromising their privacy. This process not only ensures the authenticity of the user's identity but also enhances the security of authentication by not exposing the user's private key. User privacy is protected, while the authentication service can accurately complete the authentication process, allowing the user to access the corresponding services or resources. This method demonstrates the possibility of achieving secure and effective online authentication while protecting user privacy.

[0090] Step 34: The certifier requests Merkel's certification.

[0091] In this embodiment, step 34 describes the process by which the authenticator (Auth) requests a Merkel proof from the identity provider (IdP) to verify the integrity and authenticity of the user's identity information. The authenticator initiates the request through a secure communication channel, explicitly requiring a Merkel proof associated with the hash value H{IDuser} of the user's identity information. After receiving the request, the identity provider (IdP) securely sends the corresponding Merkel proof to the authenticator; the authenticator then verifies the received Merkel proof, ensuring that the user's submitted identity information has not been tampered with and is consistent with the information stored by the IdP. This process not only ensures the authenticity of the user's identity and the security of the information, but also effectively protects the user's privacy by using a Merkel proof instead of the original data. In this way, this application demonstrates the importance of combining security, privacy protection, and technological innovation in identity verification.

[0092] Step 35: Identity Provider (IdP) provides Merkel proof.

[0093] In this embodiment, step 35 describes the process by which the identity provider IdP provides a Merkle proof to the authenticator Auth, including the Merkle root M_{root} and the Merkle path Path(H_{IDuser}) of the user identity information hash value H_{IDuser}. Specifically, after generating and ensuring that the hash value of the user identity information is securely stored, the identity provider IdP securely sends the Merkle proof to the authenticator via an encrypted channel such as HTTPS. After receiving the proof, the authenticator verifies the integrity and authenticity of the user identity information by comparing the recalculated Merkle root with the Merkle root provided by the identity provider IdP. This process not only protects user privacy and avoids the direct exposure of the original identity information, but also enhances the security and authenticity of authentication through the Merkle proof. In this way, the identity provider IdP effectively proves the credibility of the user's identity while maintaining the highest standards of user privacy and information security.

[0094] Step 36: The certifier verifies Merkel's certificate.

[0095] In this embodiment, step 36 describes the process by which the authenticator verifies the Merkle proof provided by the identity provider IdP. This process ensures the integrity and authenticity of the user's identity information. During the verification process, the authenticator uses a specific verification function (Verify {Merkle Proof)) to verify the user's identity information based on the hash value H{IDuser}, the Merkle root M{root}, and the Merkle path Path(H{IDuser}). Specifically, by reconstructing the Merkle tree using the Merkle path Path(H{IDuser}) and recalculating the Merkle root M{root}, the authenticator can verify the consistency of the information by comparing the recalculated Merkle root with the Merkle root provided by the identity provider IdP. If the recalculated Merkle root matches the Merkle root provided by the identity provider IdP, this proves the legitimacy of the user's identity information; otherwise, they do not match. Throughout the verification process, the user's original identity information is protected and does not participate in direct verification, thereby ensuring privacy and security. Upon successful verification, the user is authenticated and granted access to the corresponding service or resource; otherwise, access is denied. This step demonstrates the importance of combining security, privacy protection, and technological innovation in identity verification.

[0096] Step 37: The certifier verifies the zero-knowledge proof.

[0097] In this embodiment, step 37 describes the process by which the authenticator, Auth, verifies the zero-knowledge proof pi{ZKP} generated by the user, using the verification function Verify{ZKP} and inputting the user's public key pk{user}. The purpose of this step is to allow the user to prove the authenticity of their identity without revealing their private key or any sensitive information. Through this process, the authenticator can protect the user's privacy while ensuring security. If the zero-knowledge proof verification is successful, it confirms the validity of the user's identity and allows the user to access the corresponding services or resources. This step not only improves the security of identity verification but also strengthens the protection of user privacy, demonstrating a commitment to both security and privacy in the field of identity verification.

[0098] Step 38: The certifier makes a certification decision.

[0099] In this embodiment, step 38 describes how the authenticator, Auth, makes a final authentication decision—whether to accept the user's identity—based on the verification results of Merkle proofs and zero-knowledge proofs, through the authentication decision function Auth{Decision}. The authenticator comprehensively evaluates the verification results of the two proofs to ensure the authenticity and integrity of the user's identity, while protecting the user's privacy in the process. If both proofs are successfully verified, the authenticator will output a positive authentication decision, allowing the user to access the corresponding service or resource; otherwise, it will deny the user access to the corresponding service or resource. This step is the final stage of the identity verification process, marking its end, and ensuring the security, accuracy, and privacy protection of the entire identity verification process.

[0100] In summary, the decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in this application protects user privacy while ensuring the authenticity and integrity of user identities and information. Users submit their identity information to an identity provider (IdP) through a secure channel. The IdP performs initial verification and encrypts and stores the information. Users then generate zero-knowledge proofs to demonstrate the authenticity of their identity information. The IdP provides Merkle proofs to further verify the integrity of the information. The authenticator (Auth) performs a comprehensive verification of both the zero-knowledge proofs and the Merkle proofs, and ultimately makes a decision on whether to accept the user's identity. This application effectively defends against potential attackers while ensuring the accurate verification of legitimate user identities, providing an innovative solution for network security identity authentication.

[0101] It should be noted that this embodiment is only a brief illustrative description of the overall process of a decentralized identity authentication method combining Merkle trees and zero-knowledge proofs. Detailed descriptions of each step can be found in the relevant content of the foregoing embodiments, and will not be repeated here. It is understood that the present invention does not limit this.

[0102] This application embodiment receives a user's identity registration request, generates an initial Merkle proof based on the identity registration request through an identity provider, and stores the initial Merkle proof in the blockchain; receives a user's zero-knowledge proof generation request, generates a zero-knowledge proof based on the zero-knowledge proof generation request through a zero-knowledge proof module, and encapsulates the zero-knowledge proof in the user's identity verification request; receives a user's identity verification request, and requests the initial Merkle proof corresponding to the user from the identity provider based on the identity verification request; the identity provider then sends the initial Merkle proof corresponding to the user to the authenticator; the authenticator performs a first identity verification on the user based on the initial Merkle proof; if the first identity verification is successful, the authenticator performs a second identity verification on the user based on the zero-knowledge proof; if the second identity verification is successful, an identity verification success result is generated and returned to the user; wherein, the identity verification success result indicates that the user is allowed to access the target resource. This application's embodiments, by generating Merkle proofs using Merkle trees, can improve data integrity and verifiability, reducing the risk of fraud and identity theft. Simultaneously, Merkle trees support a rapid data verification process, thereby improving verification efficiency. Furthermore, by utilizing zero-knowledge proof technology to generate zero-knowledge proofs, users can prove their identity without disclosing sensitive information, effectively resisting new attack methods, including advanced persistent threats. By combining Merkle proofs and zero-knowledge proofs to verify user identities, more advanced data security features can be achieved, greatly enhancing user privacy protection.

[0103] In summary, the decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in this application utilizes cryptographic tools and Merkle tree structures, combined with zero-knowledge proof technology, to achieve secure storage and verification of user identity information. Compared with traditional methods, it has the following advantages: First, it greatly enhances user privacy protection and identity authentication security, enabling users to prove their identity without disclosing personal information; second, the Merkle tree ensures data integrity and security, reducing the risk of fraud and identity theft. Furthermore, the use of Merkle trees improves verification efficiency, optimizes system performance, and reduces storage requirements by storing only necessary hash values; it also utilizes zero-knowledge proof technology to allow users to prove their identity without disclosing sensitive information, thereby effectively resisting new attack methods, including advanced persistent threats; simultaneously, this application strengthens trust, as the authenticator can be certain of the user's identity authenticity, is highly adaptable to various application scenarios, and improves auditing capabilities, facilitating the review and verification of the identity verification process; finally, it provides a new direction for the development of identity authentication technology, offering users a more secure, private, and efficient authentication method. Furthermore, the use of blockchain technology can ensure the immutability and verifiability of data.

[0104] Therefore, compared with traditional static authentication methods, the decentralized identity authentication method combining Merkle trees and zero-knowledge proofs provided in this application has dynamic adjustment capabilities, can respond to security threats in real time, and adapt to changes in the network security environment. This identity authentication scheme meets the current high standards of network security and provides users with a secure, reliable, and flexible identity verification mechanism.

[0105] Please see Figure 4 This application also provides a decentralized identity authentication device 400 combining Merkle trees and zero-knowledge proofs, applied to a decentralized identity authentication system. The decentralized identity authentication system includes an identity provider, a zero-knowledge proof module, and an authenticator, and can implement the above-described method. The device includes the following modules: Merkel proof generation module 401 is used to receive a user's identity registration request, generate an initial Merkel proof through the identity provider based on the identity registration request, and store the initial Merkel proof in the blockchain; The zero-knowledge proof generation module 402 is used to receive the user's zero-knowledge proof generation request, generate a zero-knowledge proof according to the zero-knowledge proof generation request through the zero-knowledge proof module, and encapsulate the zero-knowledge proof in the user's authentication request; Merkel proof acquisition module 403 is used to receive the user's authentication request, and through the authenticator, request the identity provider to obtain the initial Merkel proof corresponding to the user based on the authentication request; so that the identity provider sends the initial Merkel proof corresponding to the user to the authenticator; The dual-proof verification module 404 is used to perform a first authentication of the user by the authenticator based on the initial Merkel proof, and if the first authentication of the user is successful, then the authenticator performs a second authentication of the user based on the zero-knowledge proof. The identity authentication result generation module 405 is used to generate an identity authentication success result if the user's second identity authentication is successful, and return the identity authentication success result to the user; wherein, the identity authentication success result indicates that the user is allowed to access the target resource.

[0106] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0107] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0108] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0109] Please see Figure 5 , Figure 5 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 501 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 502 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 502 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 502 and is called and executed by the processor 501 using the methods described in the embodiments of this application. The input / output interface 503 is used to implement information input and output; The communication interface 504 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 505 transmits information between various components of the device (e.g., processor 501, memory 502, input / output interface 503, and communication interface 504); The processor 501, memory 502, input / output interface 503, and communication interface 504 are connected to each other within the device via bus 505.

[0110] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0111] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0112] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0113] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0114] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0115] This application provides a decentralized identity authentication method, apparatus, electronic device, storage medium, and program product combining Merkle trees and zero-knowledge proofs. It receives a user's identity registration request, generates an initial Merkle proof based on the registration request through an identity provider, and stores the initial Merkle proof in a blockchain; receives a user's zero-knowledge proof generation request, generates a zero-knowledge proof based on the request through a zero-knowledge proof module, and encapsulates the zero-knowledge proof in the user's identity verification request; receives a user's identity verification request, and requests the initial Merkle proof corresponding to the user from the identity provider based on the verification request through an authenticator; the identity provider then sends the initial Merkle proof corresponding to the user to the authenticator; the authenticator performs a first identity verification on the user based on the initial Merkle proof; if the first identity verification is successful, the authenticator performs a second identity verification on the user based on the zero-knowledge proof; if the second identity verification is successful, an identity verification success result is generated and returned to the user; wherein, the identity verification success result indicates that the user is allowed to access the target resource. This application's embodiments, by generating Merkle proofs using Merkle trees, can improve data integrity and verifiability, reducing the risk of fraud and identity theft. Simultaneously, Merkle trees support a rapid data verification process, thereby improving verification efficiency. Furthermore, by utilizing zero-knowledge proof technology to generate zero-knowledge proofs, users can prove their identity without disclosing sensitive information, effectively resisting new attack methods, including advanced persistent threats. By combining Merkle proofs and zero-knowledge proofs to verify user identities, more advanced data security features can be achieved, greatly enhancing user privacy protection.

[0116] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0117] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0118] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0120] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0121] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0126] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A decentralized identity authentication method combining a Merkle tree and a zero-knowledge proof, characterized in that, The application is applied to a decentralized identity authentication system, the system comprising an identity provider, a zero-knowledge proof module and an authenticator, and the method comprises the following steps: receiving a user's identity registration request, generating an initial Merkle proof by the identity provider according to the identity registration request, and storing the initial Merkle proof in a blockchain; receiving a user's zero-knowledge proof generation request, generating a zero-knowledge proof by the zero-knowledge proof module according to the zero-knowledge proof generation request, and encapsulating the zero-knowledge proof in the user's identity authentication request; receiving the user's identity authentication request, requesting the identity provider to obtain the initial Merkle proof corresponding to the user according to the identity authentication request by the authenticator; so that the identity provider sends the initial Merkle proof corresponding to the user to the authenticator; performing a first identity authentication on the user according to the initial Merkle proof by the authenticator, and if the first identity authentication of the user is successful, performing a second identity authentication on the user according to the zero-knowledge proof by the authenticator; if the second identity authentication of the user is successful, generating an identity authentication success result, and returning the identity authentication success result to the user; wherein the identity authentication success result represents that the user is allowed to access a target resource.

2. The method of claim 1, wherein, The receiving of the user's identity registration request, the generation of the initial Merkle proof by the identity provider according to the identity registration request, and the storage of the initial Merkle proof in the blockchain comprise: receiving the identity registration request of the user by a data collection module in the decentralized identity authentication system, and sending the identity registration request to the identity provider; wherein the identity registration request comprises user identity information of the user; hashing the user identity information in the identity registration request by the identity provider to obtain an identity hash value; generating an initial Merkle tree according to the identity hash value by the identity provider, and calculating an initial Merkle root of the initial Merkle tree; generating the initial Merkle proof according to the initial Merkle root by the identity provider, and storing the initial Merkle proof in the blockchain.

3. The method of claim 1, wherein, The receiving of the user's zero-knowledge proof generation request, the generation of the zero-knowledge proof by the zero-knowledge proof module according to the zero-knowledge proof generation request comprises: receiving the zero-knowledge proof generation request of the user by a data collection module in the decentralized identity authentication system, and sending the zero-knowledge proof generation request to the zero-knowledge proof module; wherein the zero-knowledge proof generation request comprises an identity hash value of the user; generating the zero-knowledge proof according to the identity hash value of the user by calling a zero-knowledge proof generation function by the zero-knowledge proof module.

4. The method of claim 1, wherein, The initial Merkle proof includes an identity hash value of the user, an initial Merkle root, and an initial Merkle path, the first identity verification of the user by the authenticator according to the initial Merkle proof includes: The authenticator reconstructs a Merkle tree according to the identity hash value and the initial Merkle path to obtain a current Merkle tree; The authenticator calculates a current Merkle root of the current Merkle tree; The authenticator compares and verifies the current Merkle root with the initial Merkle root; If the information of the current Merkle root is consistent with that of the initial Merkle root, it is determined that the user passes the first identity verification; If the information of the current Merkle root is inconsistent with that of the initial Merkle root, it is determined that the user fails the first identity verification.

5. The method of claim 1, wherein, The identity verification request includes public key information of the user, and the second identity verification of the user by the authenticator according to the zero-knowledge proof includes: If the first identity verification of the user is successful, the authenticator verifies the zero-knowledge proof according to a zero-knowledge proof verification function and the public key information to complete the second identity verification of the user.

6. The method of claim 1, wherein, The method further includes: Dynamically monitoring operation behavior and network environment change information of the user; According to the operation behavior and the network environment change information, combining the identity authentication history of the user and the validity of the zero-knowledge proof, a trust evaluation result is generated; According to the trust evaluation result, the resource access permission of the user is dynamically adjusted.

7. A decentralized identity authentication device combining a Merkle tree and a zero-knowledge proof, characterized in that, Applied to a decentralized identity authentication system including an identity provider, a zero-knowledge proof module, and an authenticator, the device includes the following modules: A Merkle proof generation module is configured to receive an identity registration request of a user, generate an initial Merkle proof by the identity provider according to the identity registration request, and store the initial Merkle proof in a block chain; A zero-knowledge proof generation module is configured to receive a zero-knowledge proof generation request of the user, generate a zero-knowledge proof by the zero-knowledge proof module according to the zero-knowledge proof generation request, and encapsulate the zero-knowledge proof in an identity verification request of the user; A Merkle proof acquisition module is configured to receive the identity verification request of the user, request the initial Merkle proof corresponding to the user from the identity provider by the authenticator according to the identity verification request; so that the identity provider sends the initial Merkle proof corresponding to the user to the authenticator; A double proof verification module is configured to perform the first identity verification of the user by the authenticator according to the initial Merkle proof, and perform the second identity verification of the user by the authenticator according to the zero-knowledge proof if the first identity verification of the user is successful. The identity authentication result generation module is configured to generate an identity authentication success result if the second identity authentication of the user is successful, and return the identity authentication success result to the user; wherein the identity authentication success result indicates that the user is allowed to access a target resource.

8. An electronic device, comprising: The electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method in any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program is executed by the processor to implement the method in any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method in any one of claims 1 to 6. The computer program is executed by the processor to implement the method in any one of claims 1 to 6.

Images