An Efficient Distributed Identity Selective Disclosure Algorithm

Featured Application

Distributed identity management and privacy protection for user identities and electrical devices.

Abstract

Distributed digital identity is an emerging identity management technology aimed at achieving comprehensive interconnectivity between digital objects. However, there is still the problem of privacy leakage in distributed identities, and selective disclosure technology partially solves the privacy issue in distributed identities. Most of the existing selective disclosure algorithms use anonymous credentials or hash functions. Anonymous credential schemes offer high security and meet the requirements of unforgeability and unlinkability, but their exponential operations result in low efficiency. The scheme based on hash functions, although more efficient, is susceptible to man-in-the-middle attacks. This article proposes an efficient selective disclosure scheme based on hash functions and implicit certificates. The attribute values are treated as leaf nodes of the Merkle tree, and the root node is placed in a verifiable credential. According to the implicit certificate algorithm process, a key pair that can use the credential is generated. During the attribute disclosure process, the user autonomously selects the attribute value to be presented and generates a verification path from the attribute to the root node. The verifier checks the Merkle tree verification path. All operations are completed within 10 ms while meeting the unforgeability requirements and resisting man-in-the-middle attacks. This article also utilizes the ZK-SNARK algorithm to hide the validation path of the Merkle tree, enhancing the security of the path during the disclosure process. The experimental results show that the selective disclosure algorithm performs well in both performance and privacy protection, with an efficiency 80% faster than that of existing schemes. This enhances the proposed scheme’s potential and value in the field of identity management; it also holds broad application prospects in fields such as the Internet of Things, finance, and others.

1. Introduction

The rapid development of blockchain technology has demonstrated its enormous potential in fields such as finance, supply chain management, and digital identity verification. Against this backdrop, on-chain and off-chain trustworthy interaction technology has emerged, aiming to facilitate the efficient and reliable interaction between blockchain and traditional network environments. This technology not only provides technical support for expanding blockchain application scenarios, but also offers new solutions for data exchange and identity authentication [1]. The core objective of on-chain and off-chain trustworthy interaction is to ensure that data exchange between on-chain and off-chain environments maintains integrity and trustworthiness without compromising user privacy. Here, “on-chain” refers to the blockchain system, while “off-chain” refers to information systems outside the blockchain. Blockchain applications for on-chain and off-chain trustworthy interactions can fully leverage the advantages of blockchain, such as trustworthiness, traceability, and immutability, while taking advantage of the lower computational and storage costs and flexibility of off-chain information systems, thus achieving complementary advantages between the two [2]. However, blockchain technology can only guarantee the trustworthiness of the on-chain closed environment, and methods to ensure privacy security during interactions are a key technical challenge faced by on-chain and off-chain trustworthy interactions. The transparency feature of the blockchain, while ensuring data verifiability and resistance to tampering, can also lead to the leakage of sensitive information. For example, users’ identity information, transaction amounts, and other data might be publicly available in on-chain environments, posing security risks for personal privacy and business secrets. Although the off-chain part can provide some degree of protection for data privacy, due to the security and trust mechanism issues still apparent in the connection between blockchain and traditional database systems, sensitive data processed by off-chain systems may also be exposed in insecure environments [3].

While Nakamoto’s foundational work [4] established blockchain’s transparency and immutability as pillars of trust, Zyskind et al. [5] highlighted that these very features risk exposing sensitive data—a concern echoed by 67% of enterprises in IDC’s 2023 blockchain adoption survey [6]. This underscores the critical need for privacy-preserving mechanisms in cross-chain interactions.

Current hybrid architectures [7] typically employ blockchain for verifiable data anchoring while offloading computation to off-chain systems. However, these frameworks face two fundamental challenges as follows: Privacy vulnerabilities: The transparency of blockchain models (e.g., Bitcoin’s UTXO [4]) combined with off-chain system vulnerabilities creates dual attack surfaces. For instance, medical diagnostic data in healthcare consortium chains can be deanonymized through metadata analysis [8]. Verification bottlenecks: Existing solutions like Hyperledger Fabric’s channel isolation [7] introduce 2.3–4.1 × latency overhead for transaction validation [9], compromising real-time performance. Decentralized Identity (DID) systems, built on the W3C DID standard [10], offer promising solutions. The self-sovereign identity model pioneered by Sovrin [11] leverages zero-knowledge proofs (ZKPs) to enable minimal disclosure. Yet, as demonstrated by Camenisch et al. [12], current DID schemes suffer from >200 ms verification latency for 50+ attribute credentials, failing to meet real-time requirements. More alarmingly, Microsoft’s analysis of Entra ID [13] revealed that 93% of traditional attribute disclosures expose redundant sensitive data. To address the above privacy issues related to on-chain and off-chain data, distributed identity management has become an important research direction. The aim of decentralized identity [10] (DID) is to give users ownership and control over their identity information, and to decentralize the storage and verification of data across a distributed network, allowing users to independently manage and control their identity information without relying on a single centralized identity verification agency. Distributed identity systems can effectively reduce reliance on centralized identity issuers and significantly reduce the risk of centralized data breaches.

To address this issue, selective disclosure technology [14] has emerged. Selective disclosure is a technique that uses encryption and verification mechanisms to allow users to disclose only specific identity information. Users can choose to provide only some identity data to the verifier without revealing all information. This approach not only enhances the protection of user privacy but also increases the flexibility and adaptability of decentralized identity systems [15]. For example, when a user needs to prove that they are over 18 years old, they only need to disclose their age and do not need to reveal their birthdate or other personal details. Selective disclosure has several advantages in the implementation of decentralized identities. First, selective disclosure can effectively reduce the risk of data breaches and the potential for misuse of user privacy. Second, it implements the “minimal disclosure” principle in identity verification, which aligns with existing data protection laws (such as GDPR) requiring data minimization. Moreover, selective disclosure can also increase user trust in the decentralized identity system, further promoting its application across various domains. Therefore, selective disclosure is not only a key technology in decentralized identity systems but also an important method to safeguard user privacy and security.

This paper proposes a secure and efficient hash-based selective disclosure algorithm, MECQV, which introduces implicit certificates as a verifiable method for credential issuance and verification. Implicit certificates not only enhance the security of the hash-based selective disclosure method, ensuring unforgeability, but they also perform 80% faster than anonymous credential schemes. Additionally, this paper combines Merkle trees and zero-knowledge proof algorithms to hide the Merkle tree verification path, resisting man-in-the-middle attacks. Finally, this paper analyzes the security of the proposed scheme under the random oracle model, showing that the scheme can withstand known attacks and offer enhanced privacy protection.

To summarize, this article makes the following contributions.

• We propose a secure and efficient hash-based selective disclosure algorithm, MECQV, which introduces implicit certificates as a verifiable method for credential issuance and verification.
• We combine Merkle trees and zero-knowledge proof algorithms to hide the Merkle tree verification path, resisting man-in-the-middle attacks.
• We evaluate MECQV both theoretically and experimentally. We compare the performance of MECQV with FlexDID. Our results show that all the operations of MECQV can be completed within 10 ms on a Linux Ubuntu 22.04 LTS machine. MECQV not only enhance the security of the hash-based selective disclosure method, ensuring unforgeability, but it also perform 80% faster than anonymous credential schemes.

The remainder of this article is organized as follows. We review related works in Section 2 and the preliminaries in Section 3. We provide our design in Section 4. We then show the workflow of MECQV in Section 5. Additionally, we provide a security proof and show our evaluation results in Section 6. Finally, we conclude our work in Section 7.

2. Related Work

Currently, the methods used to solve the selective disclosure problem are roughly divided into three categories as follows: atomic credentials, hash functions, and anonymous credentials [16].

Atomic credentials create different credentials for each user attribute. Although this approach provides more granular selection for users when constructing their credentials, the creation of atomic credentials is computationally and memory-intensive, as it requires as many signatures as there are attributes.

Another approach to implementing selective disclosure is through hash functions. The issuer creates a credential, but instead of directly inserting the attribute values into the credential, it combines the attribute values with a random number, computes a hash, and inserts the hash value into the credential. The credential is then signed, and both the credential, attribute values, and associated random number are sent to the user via a secure channel. Therefore, when submitting the credential to the verifier, a subset of the attributes needs to be disclosed. The user must send these attribute values along with the relevant random numbers to prove the integrity and validity of the attribute. For instance, ref. [17] proposes a method that allows each element of an XML document to have a random number attribute, making it difficult for attackers to guess the original of the hash, and it uses a Merkle tree to prove the existence of multiple documents. However, this method increases the computational load. Ref. [18] proposes a selective disclosure method based on hash functions, which allows users to selectively disclose partial claims within a credential, with the issuer sending the hashed claims rather than the actual values. Users can disclose the values of the claims they want to disclose and the relevant random numbers to the verifier, who can verify the integrity and authenticity of the disclosed claims. This method provides fine-grained data-sharing control and, compared to atomic credentials or selective disclosure signatures, reduces computational overhead. A hash-based selective disclosure scheme for Self-Sovereign Identity (SSI) is proposed, which allows users to disclose only the necessary information during identity verification, reducing the risk of irrelevant data leakage. This scheme maintains high flexibility while implementing self-sovereign identity and is suitable for different application scenarios. A limitation to this approach is that practical deployment may face computational and storage overheads, and the security and scalability of multi-party verification still need further validation and optimization.

Currently, most solutions to the selective disclosure problem use anonymous credentials. In the 1980s, the concept of anonymous credentials was proposed by Chaum [19], and in 1999, the pseudonym system [20] was introduced. The first practical implementation was presented in 2001 by Jan Camenisch et al. [21], at the Eurocrypt conference. This scheme was based on the strong RSA assumption. It was the first practical solution that allowed users to prove ownership of a credential multiple times and in an unlinkable manner, without involving the issuing organization. A year after this proposal, Camenisch et al. designed a prototype based on this protocol, called the Idmix system. This scheme uses a large number of zero-knowledge proofs, and many later schemes have built on this approach. In 2008, Blanton et al. [22] proposed a scheme for anonymously obtaining online services. This scheme used the Camenisch–Lysyanskaya (CL) signature scheme [23], which relies on bilinear pairings. Although this scheme only discusses interactions between the user and the server, its anonymity features also make it applicable to constructing an anonymous credential system. Below is a detailed introduction to several research works closely related to this paper. Coconut [16] is an innovative selective disclosure credential scheme that supports distributed threshold issuance, public and private attributes, re-randomization, and multiple unlinkable selective attribute disclosures. It is integrated with blockchain and ensures confidentiality, authenticity, and availability even if some credential issuers are malicious or offline. Coconut is implemented as a general smart contract library for Chainspace and Ethereum, supporting applications such as anonymous payments, electronic petitions, and anti-censorship. BASS [24] proposes a blockchain-based anonymous authentication mechanism for privacy protection in smart industrial applications. BASS supports attribute privacy, selective revocation, credential integrity, and unlinkability in multiple presentations. It employs an efficient selective revocation mechanism based on dynamic accumulators and the Pointcheval–Sanders signature algorithm. BASS allows the selective revocation of credentials or users according to the issuer’s needs. It also extends BASS from single-attribute privacy to multi-attribute privacy. Ref. [17] proposes a decentralized identity management system for industrial IoT (FLEXDID), which features high flexibility, scalability, and efficiency, supporting both vertical and horizontal credential disclosure methods. The proposed three-tier architecture can effectively handle the authentication needs of a large number of industrial IIot devices. In terms of security, FLEXDID applies the PS signature scheme and zero-knowledge proofs to ensure credential unforgeability and unlinkability. However, the implementation of FLEXDID relies on multiple complex cryptographic techniques (such as PS signatures and RSA accumulators), which increases the difficulty of implementation and maintenance. Moreover, while FLEXDID runs efficiently on IIoT devices, its performance is still relatively low on low-performance devices, potentially due to hardware limitations.

Existing approaches to selective disclosure face several challenges. Atomic credentials, while providing fine-grained control, are computationally expensive and memory-intensive. Hash-based methods, although more efficient, are susceptible to man-in-the-middle attacks and often require significant computational resources for verification. Anonymous credential schemes, while offering high security and unlinkability, suffer from inefficiency due to their reliance on complex cryptographic operations such as bilinear pairings and zero-knowledge proofs. These limitations hinder their practical deployment in real-world applications, particularly in scenarios requiring high-frequency identity verification and low-latency responses.

To address these challenges, our proposed MECQV algorithm leverages implicit certificates and Merkle trees to achieve a balance between efficiency and security. By utilizing implicit certificates, we eliminate the need for complex bilinear pairings and reduce the computational overhead associated with credential generation and verification. The integration of Merkle trees allows for the efficient and secure verification of selective attributes, while the use of zero-knowledge proofs ensures that the verification path remains hidden, thereby enhancing privacy.

3. Preliminaries

3.1. Merkle Tree

A Merkle tree is an efficient data structure first proposed by Ronald Merkle in 1979 [25], and it is widely used in distributed systems and blockchain technology. It works by dividing data into multiple smaller blocks (i.e., leaf nodes) and using a hash function to combine these blocks in layers to form a tree structure, which eventually converges into a root hash. The core technical point of this structure lies in its ability to guarantee data integrity and security. The structure of a Merkle tree is shown in Figure 1, the letters A–H is the leaf nodes.

First, the construction of a Merkle tree takes advantage of the one-way nature and collision resistance of hash functions. The value of each node is the hash of its child node values, so any modification to a leaf node will cause the hash values of its parent nodes to change, ultimately affecting the root hash. This allows users to quickly verify the integrity of a specific data block using the root hash and the hash chain of the related data, without needing to access the entire dataset. This characteristic is known as “lazy verification”.

Second, Merkle trees support efficient data operations. In practical applications, when the validity of a particular data block needs to be verified, only the hash of that data block and the hashes of its sibling nodes need to be transmitted. By computing layer by layer, the final comparison is made with the root hash. This verification method significantly reduces data transmission and improves system efficiency.

Furthermore, Merkle trees also demonstrate advantages in data sharding and parallel processing. In distributed storage, data can be stored in fragments across different nodes, and the Merkle tree provides a mechanism for verifying the integrity of these fragments, ensuring that the data is not tampered with during transmission and storage.

Merkle trees are widely used, particularly in blockchain technology, where each block contains the hash of the previous block and the Merkle tree root hash of the current block’s transaction data. This design ensures the order and immutability of transaction data. In the financial sector, Merkle trees are used to record and verify transaction histories, ensuring that all participants can trust the accuracy of the data. In supply chain management, it helps trace the origin and movement of products, enabling information transparency and traceability.

3.2. Implicit Certificate

The implicit certificate scheme consists of three entities as follows: the Certificate Authority (CA), the certificate requester (U), and the certificate verifier (V). The requester, U, obtains an implicit certificate from the CA to prove U’s identity and allow V to obtain U’s public key. The workflow of implicate certificate show in Figure 2.

First, U generates a random private key $k_U{\in }_R[1,\dots ,n-1]$, and calculates the corresponding public key $R_U=k_{U}G$. After generating the public-private key pair, U sends the public key and user information to the CA. The CA selects a random integer $k{\in }_R[1,\dots ,n-1]$ and computes the public key reconstruction value $P_U=R_U+kG$. After verifying U’s identity, the CA generates the certificate Cert with the user information and $P_U$. Then, the CA computes the implicit signature value, which is the private key reconstruction value $r=ek+d_{\mathrm{CA}}\left(\mathrm{mod}n\right)$, where e is the certificate hash value. Subsequently, the CA returns the public–private key reconstruction value along with the certificate to U, who computes the final private key $d_U=e{k}_U+r\left(\mathrm{mod}n\right)$.

The implicit certificate scheme consists of the following five algorithms [26]:

• ECQV Setup In this step, the CA establishes the elliptic curve domain parameters, hash functions, and certificate encoding formats, and each entity selects a random number generator. The CA generates key pairs, and each entity must keep a true copy of the CA’s public key and domain parameters.
• Cert Request The requester, U, must generate a certificate request, which is sent to the CA. The encryption component of this request is a public key, generated in the same way as the CA’s public key during the ECQV Setup.
• Cert Generate Upon receiving the certificate request from U, the CA first confirms U’s identity and then creates an implicit certificate. The CA then sends a response to U.
• Cert PK Extraction Given U’s implicit certificate, domain parameters, the CA’s public key, and a public key extraction algorithm, U’s public key is calculated.
• Cert Reception Upon receiving the certificate response, U must verify the validity of the implicit certificate key pair.

4. Selective Disclosure Algorithm Based on Implicit Certificates (MECQV)

This paper proposes a selective disclosure algorithm based on implicit certificates. The algorithm involves the following three roles: the user (U), who is the actual owner of the attributes; the certificate authority (A), which issues verifiable credentials to the user; and the verifier (V), which verifies the user’s credentials. The user submits their attributes to the certificate authority (A). Upon receiving the attributes and confirming their authenticity, A generates a verifiable credential for U, following the algorithm, and stores the credential hash on the blockchain. When U needs to use the credential, they send the credential along with the signed information to the verifier (V). V verifies the credential and the corresponding signature to authenticate U’s identity and provide the necessary service.

4.1. Algorithm Definition

$MECQV=(Setup,CertRequest,CertGenerate,CertExtraction,CertPresentation,CertVerification)$.

The algorithm components are described as follows:

• $Setup\left(1^{\lambda }\right)\to pp$: This algorithm is used to generate the system’s public security parameters. $\lambda$ is the system’s security parameter, and the input is $1^{\lambda }$. The output is the system’s public parameters $pp$.
• $CertRequest(pp,{\left\{m_i\right\}}_{i=1}^n)\to \left(req\right)$: This algorithm is executed by the data owner (U). The input includes the public parameters $pp$ and the set of attributes ${\left\{m_i\right\}}_{i=1}^n$. The output is a credential request $req$ that U sends to the certificate authority (A). We present an algorithm as shown in Algorithm 1.
• $CertGenerate({\left\{m_i\right\}}_{i=1}^n,P_{user})\to (Pu{b}_r,Pr{v}_r,Cert)$: The credential generation involves the following two algorithms:

  -

  $Merkle\left({\left\{m_i\right\}}_{i=1}^n\right)\to \left(root\right)$: This algorithm generates a Merkle tree and verifies the root node.

  -

  $Generate(root,P_{user})\to (Pu{b}_r,Pr{v}_r,Cert)$: This algorithm takes the Merkle tree root node $root$ and the user’s public key $P_{user}$ as input to validate U’s attributes. The output includes the public key reconstruction value $Pu{b}_r$, the private key reconstruction value $Pr{v}_r$, and the main credential $Cert$. We present an algorithm as shown in Algorithm 2.

• $CertExtraction(Pu{b}_r,Pr{v}_r)\to (Pu{b}_u,Pr{v}_u)$: This algorithm is executed by U, who takes the public key reconstruction value $Pu{b}_r$ and private key reconstruction value $Pr{v}_r$ as input. It outputs the credential’s public key $Pu{b}_u$ and private key $Pr{v}_u$. We present an algorithm as shown in Algorithm 3.
• $CertPresentation(S,root,{\left\{P_i\right\}}_{i\in S},Pr{v}_r)\to \left(Cer{t}^{\prime }\right)$: This algorithm is executed by U. It takes the disclosed attribute set S, the Merkle tree root node $root$, and the proof path ${\left\{P_i\right\}}_{i\in S}$ from the leaf nodes to the root node as inputs. The output is the sub-credential $Cer{t}^{\prime }$. We present an algorithm as shown in Algorithm 4.

  -

  $Proof(S,root,{\left\{P_i\right\}}_{i\in S})\to \left(proof\right)$: This algorithm generates a zero-knowledge proof for the Merkle tree leaf node verification path.

  -

  $Sign(proof,Pr{v}_r)\to \left(Cer{t}^{\prime }\right)$: This algorithm signs the proof generated by the previous algorithm.

• $CertVerification(Cert,Cer{t}^{\prime })\to (1/0)$: The verifier (V) executes this algorithm, which takes the main credential and the sub-credential as input. It outputs either 1 (valid) or 0 (invalid). We present an algorithm as shown in Algorithm 5.

Algorithm 1 Credential request

1: procedure CertRequest($pp,{\left\{m_i\right\}}_{i=1}^n$) 2:     $K_{user}\stackrel{\$}{\leftarrow }{\{0,1\}}^n$ 3:     $P_{user}\leftarrow K_{user}·G$ 4:     $req\leftarrow (K_{user},\left\{m_i\right\},P_{user})$ 5:     return $req$

Algorithm 2 Credential generation

1: procedure CertGenerate($\left\{m_i\right\},P_{user}$) 2:     Construct Merkle tree: $root\leftarrow H(m_1\Vert \cdots \Vert m_n)$ 3:     $K_A\stackrel{\$}{\leftarrow }{\mathbb{Z}}_n^{\ast }$ 4:     $Pu{b}_r\leftarrow K_A·G+P_{user}$ 5:     $Cert\leftarrow root\Vert Pu{b}_r$ 6:     $e\leftarrow H_1\left(Cert\right)$ 7:     $Pr{v}_r\leftarrow e·K_A+d_A$        ▹$d_A$: Authority’s private key 8:     return $(Pu{b}_r,Pr{v}_r,Cert)$

Algorithm 3 Credential extraction

1: procedure CertExtraction($Pu{b}_r,Pr{v}_r$) 2:     $e^{\prime }\leftarrow H_1\left(Cert\right)$, $Pu{b}_u\leftarrow e^{\prime }·Pu{b}_r+Q_A$ 3:     $Pr{v}_u\leftarrow e^{\prime }·K_{user}+Pr{v}_r$ 4:     Verify $Pu{b}_u\stackrel{?}{=}Pr{v}_u·G$ 5:     return $(Pu{b}_u,Pr{v}_u)$

Algorithm 4 Credential presentation

1: procedure CertPresentation($S,root,{\left\{P_i\right\}}_{i\in S}$) 2:     Generate ZKP: $\pi \leftarrow$zk-SNARK($S,root,\left\{P_i\right\}$) 3:     $k\stackrel{\$}{\leftarrow }{\mathbb{Z}}_n^{\ast }$, $R\leftarrow k·G$, $r\leftarrow x\left(R\right)modn$ 4:     $h\leftarrow H\left(\pi \right)$, $s\leftarrow k^{-1}(h+r·k)modn$ 5:     return $Cer{t}^{\prime }\leftarrow (r,s)\Vert \pi$

Algorithm 5 Credential verification

1: procedure CertVerification($Cert,Cer{t}^{\prime }$) 2:     Parse $\sigma =(r,s)$ 3:     extract $Pu{b}_r$ 4:     Compute $w\leftarrow s^{-1}modn$ 5:     $u_1\leftarrow h·w$, $u_2\leftarrow r·w$ 6:     $R^{\prime }\leftarrow u_1·G+u_2·Pu{b}_u$ 7:     Verify $r\stackrel{?}{=}x\left(R^{\prime }\right)modn$ and Merkle proof $\pi$ 8:     return 1 if valid, 0 otherwise

4.2. Algorithm Description

This section provides a concrete example of the MECQV algorithm. Based on the flow of the credential, the process is divided into six stages as follows: initialization, credential request, credential generation, credential acceptance, credential presentation, and credential verification.

In the initialization stage, all entities involved in the credential process generate their DID identities, including their respective public and private key pairs. The certificate authority’s public and private keys are represented as $d_A$ and $Q_A$, the user’s public and private keys as $d_U$ and $Q_U$, and the verifier’s public and private keys as $d_V$ and $Q_V$. In addition to key generation, the hash functions and security parameters used in subsequent stages must also be defined.

• Initialization stage
  $Setup\left(1^{\lambda }\right)\to pp$: Given the security parameter k, generate a k-bit prime number p and an elliptic curve $E/F_p$, where the curve is defined over the finite field $F_p$ with a base point G and order n. Assume the existence of a collision-resistant hash function $H:{\{0,1\}}^{\ast }\to Z_p$.
• Credential request stage
  $CertRequest(pp,{\left\{m_i\right\}}_{i=1}^n)\to \left(req\right)$: U randomly selects an n-bit number as the private key $K_{user}$ and computes the public key $P_{user}=K_{user}G$. U generates the credential request $req=(K_{user},{\left\{m_i\right\}}_{i=1}^n,P_{user})$ and sends $req$ to certificate authority (A).
• Credential generation stage
  $CertGenerate({\left\{m_i\right\}}_{i=1}^n,root,P_{user})\to (Pu{b}_r,Pr{v}_r,Cert)$: This stage consists of the following two algorithms:
  • $Merkle\left({\left\{m_i\right\}}_{i=1}^n\right)\to \left(root\right)$: This algorithm takes the attribute set and treats them as the leaf nodes of a Merkle tree. It uses a hash function to generate the root node $root=H(m_1,\dots ,m_n)$.
  • $Generate(root,P_{user})\to (Pu{b}_r,Pr{v}_r,Cert)$: A randomly selects a number $K_A$, computes $Pu{b}_r=K_{A}G+P_{user}$, and generates the credential $Cert=root\left|\right|Pu{b}_r$. The certificate hash is computed as $e=H_1\left(Cert\right)$, and the private key reconstruction value is calculated as $Pr{v}_r=e{K}_A+d_A$, where $d_A$ is A’s private key.
• Credential acceptance stage
  $CertExtraction(Pu{b}_r,Pr{v}_r)\to (Pu{b}_u,Pr{v}_u)$: U computes $e^{\prime }=H_1\left(Cert\right)$, the credential public key $Pu{b}_u=e^{\prime }Pu{b}_r+Q_A$, and the credential private key $Pr{v}_u=e^{\prime }{K}_{user}+Pr{v}_r$. Here, $Q_A$ is the certificate authority’s public key. The verification step is $Pu{b}_u=Pr{v}_{u}G$.
• Credential presentation stage
  $CertPresentation(S,root,{\left\{P_i\right\}}_{i\in S})\to \left(Cer{t}^{\prime }\right)$: Credential presentation involves the following two algorithms:
  • $Proof(S,root,{\left\{P_i\right\}}_{i\in S})\to \left(\pi \right)$: This algorithm generates a zero-knowledge proof for the leaf node verification path in the Merkle tree.
  • $Sign(\pi ,Pr{v}_r)\to \left(Cer{t}^{\prime }\right)$: A random number k is chosen, and the point $R=(x_1,y_1)=k·G$ is calculated. The signature parameter is $r=x_{1}modn$. If $r=0$, a new random number is chosen. The value $h=H\left(\pi \right)$ is computed, and the signature $s=k^{-1}·(h+r·k)modn$ is obtained. If $s=0$, a new random number is selected. The signature $\sigma =(r,s)$ is generated, and the sub-credential $Cer{t}^{\prime }=\sigma \left|\right|\pi$ is output.
• Credential verification stage
  $CertVerification(Cert,Cer{t}^{\prime })\to (1/0)$: V first extracts the public key reconstruction value from the credential and computes $Pu{b}_u=e^{\prime }Pu{b}_r+Q_A$. V verifies that the signature $\sigma =(r,s)$ satisfies the conditions $1\le r\le n-1$ and $1\le s\le n-1$. The value $h=H\left(\pi \right)$ is computed, and $w=s^{-1}modn$. The values $u_1=h·wmodn$,$u_2=r·wmodn$ compute $R=(x,y)=u_1·G+u_2·Pu{b}_u$. If the point $R=O$, the output is 0. Otherwise, check whether $v=x_{1}modn$. Finally, verify the validity of the proof $\pi$.

4.3. Security Model

The legitimate user in the system is denoted as Bob, and the certificate authority is denoted as A, with its public key represented as $Q_A$. We assume that Bob possesses a true copy of A’s public key. Bob’s request to A for a certificate is represented as $(Pu{b}_B,{\left\{m_i\right\}}_{i=1}^n)$. The response from A is denoted as $(Pu{b}_r,Pr{v}_r,root)$. Bob can issue multiple credential requests to A.

The adversary $\mathcal{A}$ is a probabilistic Turing machine with a runtime bounded by $\tau$. It can interact with the user and the certificate authority through the following two operations:

• The adversary can observe Bob’s credential request to the certificate authority, denoted as $(Pu{b}_B,{\left\{m_i\right\}}_{i=1}^n)$.
• After observing Bob’s request, the adversary can send $(Pu{b}_B,{\left\{m_i\right\}}_{i=1}^n)$ to the certificate authority and receive the response $(Pu{b}_r,Pr{v}_r,root)$, where $Pr{v}_r$ is the private key reconstruction value generated by the certificate authority, and $root$ is the Merkle tree root.

The probability that the adversary $\mathcal{A}$ outputs a tuple $(Pu{b}_u,root,Pr{v}_u)$ is at most $ϵ$, where $Pr{v}_u$ is the private key computed by U based on $(Pu{b}_r,Pr{v}_r,root)$, satisfying $Pr{v}_{u}G=H(Pu{b}_r\left|\right|root)Pu{b}_r+Q_A$. In this model, the adversary $\mathcal{A}$ is considered successful if it forges an implicit certificate under either of the following two scenarios:

1. $\mathcal{A}$ generates an implicit certificate and the corresponding private key that were not issued by the certificate authority. 2. $\mathcal{A}$ generates an implicit certificate and the corresponding private key, where the private key was issued by the certificate authority in response to a request from Bob.

If no such adversary $\mathcal{A}$ exists, the MECQV algorithm is considered secure.

5. System Model

The proposed system model consists of the following four main components: the verifier, the certificate authority, the user, and the blockchain network. The user is the entity that provides data and can obtain credentials based on their attributes. The certificate authority is responsible for issuing credentials to entities within the system and uploading credential digests to the blockchain to create verifiable records. The verifier uses the credentials to authenticate the user and provide the corresponding service.

The system process is divided into the following five stages: initialization, credential request, credential generation, credential presentation, and credential verification. The system architecture is shown in Figure 3.

This section uses a medical scenario as an example as follows: the patient acts as the user and has control over their attributes, while the hospital serves as the certificate authority and issues identity credentials to the patient. These credentials include the patient’s identity information and medical data. The doctor acts as the verifier, who authenticates the patient’s identity during a consultation. The patient can selectively disclose relevant information to the doctor as needed.

System Flow

• Initialization phase
  In the key generation phase, the patient, hospital, and doctor each register their own DID identities, and the identity registration process is the process of generating their respective keys. Taking the patient’s DID identity registration as an example, the steps are as follows:

  (a)

  The patient randomly selects $sk\in [1,n-1]$ and calculates $pk=skG$, where $sk$ is the patient’s private key and $pk$ is the patient’s public key.

  (b)

  The patient generates a DID identifier, $DID=hash\left(pk\right)$.

  (c)

  The patient generates a DID document, which includes the patient’s identifier, public key, signature, and other information. The patient sends a registration request to the blockchain node, $reques{t}_{reg}=(DID,DIDDocument,Sig{n}_{User})$.

  (d)

  After receiving the request, the blockchain node verifies the validity of the DID identifier and document, and it then packages them into a block for on-chain storage.

• Credential request phase
  In the credential request phase, the patient sends their attributes to the hospital and applies for a credential related to those attributes.

  (a)

  The patient generates a temporary key pair $(P_{user},K_{user})$ according to the steps in the above algorithm.

  (b)

  The patient uses the DID identifier registered on the blockchain to send a credential request to the hospital as follows: $request=(DID,{\left\{m_i\right\}}_{i=1}^n,P_{user},Sig{n}_{pk})$.

• Credential generation phase
  In the credential generation phase, the hospital issues a credential for the patient based on the received attributes. The hospital must first determine whether the patient’s identity attributes are valid. Then, the hospital uses the $CertGenerate$ algorithm to generate the patient’s credential, attaching the DID identifier to anchor the relationship between the patient’s identity and the credential. After generating the credential, the hospital uploads it to the blockchain network.

  (a)

  Upon receiving the request, the hospital first queries the patient’s DID identity from the blockchain network and retrieves the patient’s public key information from the DID document. Then, the hospital verifies whether the attributes submitted by the patient are valid.

  (b)

  The issuing institution generates the public and private key reconstruction values $Pu{b}_{re},Pr{i}_{re}$ and the credential $Cer{t}_{user}$ based on the credential generation algorithm from step three.

  (c)

  The issuing institution returns the credential and the private key reconstruction value to the patient.

  (d)

  After receiving the credential and private key reconstruction value, the patient calculates the credential public and private keys using the $CertExtraction$ algorithm in the credential acceptance phase.

• Credential presentation phase
  In the credential presentation phase, the doctor initiates an identity verification request. After receiving the request, the patient runs the $Proof$ and $Sign$ algorithms to generate proof of the attributes. The patient then sends the proof and the credential to the doctor.

  (a)

  The doctor initiates an identity verification request to the patient.

  (b)

  The patient selects the attributes (e.g., age) to disclose and generates a zero-knowledge proof $\pi$ for that attribute. The purpose of this proof is to hide the Merkle tree verification path.

  (c)

  The patient signs the zero-knowledge proof of the verification path using the credential’s private key, $Sign(\pi ,Pr{v}_r)$, and sends the signature and credential to the doctor.

• Credential verification phase
  Upon receiving the proof and credential from the patient, the doctor first queries the blockchain to verify the patient’s DID identity. Then, the doctor calculates the credential public key from the parameters in the credential to verify the signature in the proof. After the signature is verified, the doctor verifies the zero-knowledge proof by comparing the root node obtained from the zero-knowledge proof calculation with the root node contained in the credential to validate the attribute disclosed by the patient.

  (a)

  The doctor verifies the credential $CertVerification(Cert,Cer{t}^{\prime })\to (1/0)$ by first checking the correctness of the signature, then verifying the validity of the credential, and finally verifying the validity of the proof $\pi$.

  (b)

  In verifying the signature, the doctor can both verify whether the patient owns the private key corresponding to the credential and whether the credential was issued by the hospital. Ultimately, the doctor verifies whether the root node of the Merkle tree in the credential is valid based on the zero-knowledge proof.

6. Performance and Security Analysis

6.1. Performance Analysis

The experiment was conducted under the following hardware conditions: Processor: Intel(R) Core(TM) i7-13650HX, clock speed 2.2 GHz, 8 GB RAM, and 64-bit Linux operating system. In this experiment, the proposed selective disclosure algorithm, including the phases of initialization, credential request, credential generation, credential acceptance, credential presentation, and credential verification, was implemented in Python 3.11. To handle the encryption and hash operations in the algorithm, we used the fastecdsa GitHub repository (https://github.com/AntonKueltz/fastecdsa, accessed on 12 June 2014) for implicit certificate implementation. These settings provide a unified and reproducible foundation for performance testing. A comparison of the key metrics is presented in

Table 1. Key metrics comparison table.

Phase	Metrics	MECQV	FlexDID
Credential Generation	Execution time	2.1 ms ($n=32$)	12.5 ms ($n=32$)
	Computational complexity	$O\left(n\right)$	$O\left(n^2\right)$
	Resource consumption	58 KB	210 KB
Credential Presentation	Execution time	8.3 ms	22.7 ms
	Computational complexity	$O\left(n\right)$	$O\left(n^2\right)$
	Resource consumption	320 Bytes	850 Bytes
Credential Verification	Execution time	1.7 ms	9.8 ms
	Computational complexity	$O\left(n\right)$	$O\left(n\right)$

.

In this experiment, the performance evaluation focused on the following four key phases of the algorithm: credential request, credential generation, credential presentation, and credential verification. The running time for each phase was recorded and used to evaluate the computational overhead of the algorithm. Additionally, to comprehensively analyze the algorithm’s performance in different application scenarios, we tested the impact of varying attribute set sizes (e.g., 8, 16, 32, 64, etc.) on the time consumption of each phase. Considering the real-world application scenarios of this selective disclosure scheme (e.g., finance, healthcare, and industrial internet), the efficiency of the credential generation and verification phases became key indicators for assessing the performance of the scheme.

To objectively evaluate the performance of the algorithm, this experiment compares the proposed MECQV algorithm with the existing FlexDID scheme. The FlexDID scheme employs an editable PS signature mechanism with the following three major phases: the generation phase, aggregation phase, and verification phase. In contrast, MECQV simplifies the credential presentation process using implicit certificates and Merkle trees, avoiding complex exponential and bilinear pairing computations, giving MECQV a computational advantage in terms of overall complexity. As shown in Figure 4, the experimental data for each phase indicate that MECQV performs significantly better in terms of average time consumption during the generation and verification phases compared to FlexDID. The complexity of the FlexDID signature scheme increases the overall runtime, whereas MECQV demonstrates a notable lightweight characteristic in terms of performance.

Based on the experimental results, further analysis was conducted on the impact of varying attribute quantities on time consumption for each phase of MECQV, as shown in Figure 5. The data suggests that the number of attributes has little effect on the credential generation and verification phases, as MECQV’s design ensures that the attribute count primarily impacts the construction of the Merkle tree, which is highly efficient and does not cause significant time increases. However, the credential presentation phase, due to the computational overhead of the zero-knowledge proof algorithm, takes relatively longer but remains within an acceptable range.

The following is a detailed analysis of the experimental data for each phase:

• Credential request phase: In the request phase, the user does not need to perform complex calculations, and the number of attributes has very little impact on this phase.
• Credential generation phase: Due to the use of implicit certificate generation, the computational complexity is low, and the number of attributes has a minimal impact on this phase.
• Credential presentation phase: This phase is the most time-consuming due to the complexity of the zero-knowledge proof computation.
• Credential verification phase: The verification phase has a relatively short time consumption, and there is no significant increase in time as the number of attributes increases.

In summary, the experimental results show that the MECQV scheme offers significant advantages in efficiency, particularly in the credential generation and verification phases. The use of implicit certificates and Merkle trees in MECQV maintains a low system overhead in terms of computational complexity. Although the zero-knowledge proof algorithm introduces some computational cost in the credential presentation phase, the overall lightweight nature of the scheme still allows it to meet the performance requirements for high-frequency identity verification in practical applications.

6.2. Security Analysis

In the current scenario, the attacker may intercept parameters sent to the issuer, such as the root of the attribute tree and public key. However, since the attacker cannot access the private key used by the user with the credential, they cannot use the credential. This mechanism ensures the security and confidentiality of the private key, effectively preventing the credential from being copied and reused by attackers to steal user information. Furthermore, during the use of the credential, even if the attacker intercepts the credential, the zero-knowledge proof ensures that the attacker cannot retrieve the credential’s information. Ultimately, the attacker cannot recover the entire Merkle tree or obtain the root node information.

Theorem 1.

In the random oracle model, if the discrete logarithm problem on group G is hard and the Schnorr signatures are secure, then, the MECQV algorithm is secure.

Proof. 

Assume that the MECQV scheme is insecure when the hash function H is treated as a random oracle. There exists a successful $(\tau ,ϵ)$-adversary $\mathcal{A}$. We construct a polynomial-time algorithm $S-(\tau ,ϵ)$ that can invoke $\mathcal{A}$ as a subroutine to solve the Elliptic Curve Discrete Logarithm Problem (ECDLP).

The input to S is a challenge value $\left(\right(C\in G),C\ne O)$, and S expects an output of an integer $c\in [1,n-1]$ such that $C=cG$. First, S takes the input $(C,m,H)$, and there are two possible expected outputs:

• (i) An integer $c\in [1,n-1]$, such that $C=cG$;
• (ii) A pair $(P,b)$, where $bG=H(P,m)P+C$, meaning that $(P,b)$ is the signature for the message m.

If case (i) occurs, S outputs c and terminates. If case (ii) occurs, Theorem 1 is used to simplify the signature forgery problem for S into solving the discrete logarithm problem and obtaining c. If this stage is successful, S outputs c and terminates.

To calculate c, S runs the subroutine $\mathcal{A}$. The algorithm $\mathcal{A}$ expects at least one issuer, each with a public key, but $\mathcal{A}$ does not have the corresponding private key. S randomly selects a public key C from one of the issuers as the challenge value and uses C as the input to S.

Since $\mathcal{A}$ can request credentials from the issuer and expect a valid response, S must provide a response that is at least valid from the perspective of $\mathcal{A}$. S can use the random oracle H to simulate the role of the issuer without being detected by $\mathcal{A}$. S follows this process to simulate the following: given a credential request $(Pu{b}_B,{\left\{m_i\right\}}_{i=1}^n)$, S generates an integer $Pr{v}_r$, $h_i\in R[0,n-1]$, and computes $Pu{b}_r=Pu{b}_B+h_i^{-1}(Pr{v}_{r}G-C)$. S defines $H(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)=h_i$, and returns the triple $(Pu{b}_r,root,Pr{v}_r)$ as the response to $\mathcal{A}$’s request. Since $H(P,{\left\{m_i\right\}}_{i=1}^n)Pu{b}_B+Pr{v}_{r}G=H(P,{\left\{m_i\right\}}_{i=1}^n)P+C$, the response to the credential request is valid from $\mathcal{A}$’s perspective. Furthermore, from $\mathcal{A}$’s point of view, the hash function is random because $h_i$ was initially chosen randomly.

$\mathcal{A}$ may also send hash queries to S. For example, if $\mathcal{A}$ sends a query $(Pu{b}_{\mathcal{A}},I_{\mathcal{A}})$, where $I_{\mathcal{A}}={\left\{m_i\right\}}_{i=1}^n$ is a pair that has not been queried before, S outputs $H(Pu{b}_{\mathcal{A}},m)$, where m is the message that S attempts to forge a signature for. Clearly, the distribution of the simulated hash values generated by S is indistinguishable from the distribution of hash values generated by a random oracle from $\mathcal{A}$’s perspective.

Assume that $\mathcal{A}$ is successful. Then, $\mathcal{A}$ returns a triple $(Pu{b}_u,root,Pr{v}_u)$, where $Pr{v}_{u}G=hPu{b}_r+Q_A$, and $h=H(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)$, such that either of the following holds:

• (i) $(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)$ is a certificate created by $\mathcal{A}$ based on Bob’s request; or
• (ii) $(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)$ is not a certificate issued by the issuer.

Assume we are in the first case. The private key $Pr{v}_u$ output by $\mathcal{A}$ satisfies $Pr{v}_u=Pr{v}_{B}h+Pr{v}_{r}modn$, so $c=Pr{v}_B$. Thus, S can compute $c=h^{-1}(Pr{v}_u-Pr{v}_r)modn$.

Assume we are in the second case. We can assume that $(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)$ is an input query to the random oracle hash H. Therefore, by the definition of the simulation, $H(Pu{b}_r,{\left\{m_i\right\}}_{i=1}^n)=H(Pu{b}_r,m)$. Now, $(Pu{b}_r,Pr{v}_u)$ is a signature for message m, and S has completed the forgery of the signature for message m.

Clearly, if $\mathcal{A}$ runs in polynomial time and succeeds with non-negligible probability, then, S will also succeed. According to Theorem 1 and the above reasoning, if $\mathcal{A}$ runs in polynomial time and succeeds with non-negligible probability, then, S will also succeed. However, according to this assumption, there is no algorithm S that can solve the discrete logarithm problem in G. Therefore, unless the discrete logarithm problem in G can be solved efficiently, no adversary $\mathcal{A}$ exists in the random oracle model. □

7. Conclusions

This paper presents the MECQV algorithm, which synergizes implicit certificates with Merkle trees to achieve efficient and secure attribute-selective disclosure in distributed identity management. By embedding Merkle tree roots into verifiable credentials and leveraging zero-knowledge proofs (ZK-SNARKs) to conceal verification paths, the scheme enhances privacy protection while reducing computational complexity. Experimental results demonstrate that MECQV outperforms existing anonymous credential systems in efficiency, completing all operations within 10 milliseconds and achieving an 80% performance improvement, making it suitable for high-concurrency scenarios such as IoT and finance. However, the scheme exhibits certain limitations. Its reliance on elliptic curve cryptography (ECC) and Schnorr signatures introduces vulnerability to quantum computing attacks (e.g., Shor’s algorithm), potentially compromising long-term security. While the overall efficiency is notable, the computational overhead from zero-knowledge proofs during credential presentation may hinder applicability on low-performance devices. Furthermore, practical deployment could face challenges in storage and communication costs due to the distributed management of implicit certificates and Merkle tree maintenance across multiple nodes.

Future research directions should focus on migrating to post-quantum cryptographic algorithms, such as lattice-based Dilithium or hash-based SPHINCS+, while upgrading Merkle tree hash functions to quantum-resistant variants like SHA-3. A hybrid encryption architecture combining traditional algorithms (e.g., ECDH) with post-quantum counterparts (e.g., Kyber) could ensure transitional compatibility and forward security. Optimizing zero-knowledge proof systems through lightweight constructions or Learning With Errors (LWE)-based approaches may reduce computational demands and align with the post-quantum requirements. Additionally, exploring cross-chain interoperability and standardization protocols for distributed identity systems could enhance scalability and multi-scenario integration. These advancements would enable MECQV to serve as a robust, privacy-centric solution in quantum-vulnerable environments, extending its applicability to emerging domains such as digital healthcare and decentralized IoT ecosystems.