© The Author(s) 2024. Published by EDP Sciences and China Science Publishing & Media Ltd.

1. Introduction

In the contemporary era of pervasive digitalization and intricate networking, digital identity has become a fundamental component for individuals and organizations to interact and access services in cyberspace. One important application scenario is regional equity markets, which facilitate the issuance, trading, and management of equity shares within specific geographic regions. These markets, as an integral part of China’s multi-tiered capital market system, are characterized by decentralization, relatively low transaction volumes, and stringent requirements for compliance and security. Currently, China has 35 regional equity markets, primarily serving small and medium-sized enterprises and offering financing solutions for “specialized, refined, differentiated, and innovative” enterprises. In this environment, regulatory authorities play a key role in supervising identity verification and transaction processes to ensure market integrity and legal compliance. To balance privacy protection with regulatory oversight, robust identity and credential management systems are essential.

In recent years, the distributed digital identity framework proposed by the World Wide Web Consortium (W3C) has attracted wide attention. Based on the blockchain infrastructure, this framework provides a distributed, transparent, and secure method for identity management. It is designed to enhance users’ control over their personal data and significantly mitigate the risk of single points of failure and the potential for data tampering [1]. However, distributed digital identity systems also face several issues and challenges in practical applications, particularly concerning regulatory adaptability, privacy protection, and technical implementation.

Distributed digital identity systems utilize decentralized identifiers (DIDs) to enhance user privacy and anonymity. However, this approach introduces significant regulatory challenges. In the absence of explicit identity information, regulators encounter difficulties in tracking and auditing transactions, thereby compromising the legitimacy and security of financial operations [2]. Furthermore, verifiable credentials (VCs) in these systems often contain multiple attributes. During the verification process, it is often sufficient to ascertain a subset of attributes in VCs. However, there exists a non-negligible risk that the system may inadvertently disclose additional sensitive information, which can lead to privacy-compromising and an increased risk of identity theft. While some systems offer selective disclosure of attributes, the continued use of the same DIDs or the lack of support for randomized signatures can result in linkability issues, where multiple interactions are tied to the same user. This undermines privacy protection [3]. Additionally, the reliable revocation of credentials is crucial to prevent unauthorized access or misuse. However, existing solutions are characterized by an absence of robust and efficient mechanisms designed to manage the revocation process in a manner that ensures both security and scalability.

This paper introduces an innovative solution to address the regulatory and privacy challenges in decentralized identity management through two tightly integrated schemes: SR-DIDs (Supervised and Revocable Decentralized Identifiers) and SR-PP-VC (Supervised and Revocable Privacy-Preserving Verifiable Credentials). The SR-DIDs scheme facilitates the derivation of master DIDs based on Pedersen’s commitment, which enables users to autonomously create anonymous proxy DIDs while maintaining their privacy. A key innovation lies in the integration of BBS signatures, DLIN encryption, and zero-knowledge proofs, which not only empowers regulatory authorities to discern user identities when necessary but also ensures a secure and reliable revocation of DIDs through smart contracts. The proposed scheme ensures anonymity, unforgeability, and regulatory compliance.

The SR-PP-VC scheme builds on SR-DIDs by extending its regulatory and privacy-preserving features to verifiable credentials. By leveraging BBS signatures and dynamic accumulators, it facilitates real-time revocation of credentials and empowers users to present their credentials in a manner that ensures unlinkability. The tight integration between SR-DIDs and SR-PP-VC ensures coherence in both identity and credential management, thereby providing a unified framework where DIDs and VCs are both regulated and revocable in a harmonious manner. Selective disclosure of credential attributes via zero-knowledge proofs further strengthens privacy, addressing issues of over-disclosure prevalent in current systems.

We implemented the system on Hyperledger Fabric and conducted comprehensive simulations to validate the proposed approach. The results demonstrate that our solution not only enhances security and privacy but also significantly improves scalability and efficiency compared to existing systems. The presented framework meets the performance and security demands of blockchain-based identity management, providing a novel and effective solution to the challenges of privacy protection, regulatory oversight, and credential revocation.

2. Related work

At present, the mainstream blockchain uses identity identifiers or digital certificates to define the ownership of assets, data, and rights [4]. For example, the public chain relies on anonymous addresses to identify the identity, and the alliance chain confirms the identity of members through real-name digital certificates.

To prevent identifier association from causing user identity disclosure [5], researchers proposed to derive one-time identifiers from public and private keys through encryption algorithms to reduce the correlation between identifiers and enhance identity privacy, such as Monero [6], literature [7], literature [8] and other schemes. In order to further implement the supervision of one-time identifiers, literature [9] designed a link ring signature algorithm, which realized the privacy protection scheme of transaction sender and receiver identifiers that could be regulated by the autonomous confusion mechanism. However, the ring signature size was very large, resulting in large performance consumption. Literature [10] designed a supervised one-time identifier generation scheme to hide the real identity of the transaction receiver but did not support identifier revocation.

To solve the problem that the public and transparent feature of blockchain leads to the leakage of users’ real identity information when digital certificates are presented, Hyperledger Fabric uses Idemix solution [11], which can realize the anonymity and unlinkability of users’ identities and the selective disclosure of certificate attributes. Document [12] uses a state secret SM2 signature to create anonymous credentials to ensure user anonymity. In order to solve the certificate supervision problem, literature [13] designed a blockchain-oriented regulatory anonymous certificate authentication scheme based on the BBS04 group signature [14] and Idemix scheme but did not support certificate revocation. Literature [15] constructs a traceable and randomizable anonymous certificate based on the PS signature, but the certificate size increases linearly with attributes. As for the revocation of digital certificates, literature [16] builds an anonymous certificate that can be revoked, unlinked, and selectively disclosed based on a dynamic accumulator and PS signature algorithm. However, due to the fixed number of certificates issued, it is difficult to apply in practice and does not support identity supervision. Document [17] revocation certificates based on time fragments, but it is not a real-time operation and requires frequent updating of certificates, which consumes large storage resources.

To effectively manage a large amount of identity information, distributed digital identity technology integrates identity identifiers and credentials, builds the identity management layer of the blockchain system, and gives subjects control over their own identity data [4]. However, the research in this field is still in the initial stage, mainly focusing on its application practice. For example, the Internet of Things [18], medical health [19], finance [20], 6G communication [21], and other fields have effectively solved the problems faced by centralized digital identity systems, such as the lack of identity sovereignty, the disadvantages of centralized authentication, and large-scale identity identifiers and certificate management problems, and promoted the circulation and authentication of user identities among different organizations. Regarding the privacy protection of distributed digital identities, literature [22] proposes a VC privacy protection scheme with optional disclosure based on an editable signature algorithm. Literature [23] builds a new distributed digital identity system by combining a prophecy machine and trusted execution environment, which can obtain and issue identity credentials from Web service providers securely and conveniently, and protect user identity privacy. Literature [24] puts the VC generation process into a trusted execution environment to protect user attribute privacy. However, the above schemes do not consider identity supervision and VC revocation in the distributed digital identity system.

3. Propaedeutics

3.1. Blockchain

Blockchain is a decentralized and distributed ledger technology, first introduced in 2008 by an anonymous individual or group known as Satoshi Nakamoto, with the invention of Bitcoin [25]. The key feature of blockchain is its ability to securely record transactions across multiple computers, ensuring data integrity and transparency. The technical architecture of blockchain consists of several layers, including peer-to-peer networks, consensus mechanisms, cryptographic hash functions, and distributed ledgers. Each block contains a list of transactions that are cryptographically linked, ensuring immutability. Consensus mechanisms, such as Proof of Work (PoW) or Proof of Stake (PoS), ensure that all participants in the network agree on the validity of transactions, providing security and trust in a decentralized system.

One of the most important innovations in blockchain technology is the introduction of smart contracts, first implemented on the Ethereum blockchain. Smart contracts allow the automatic execution of contract terms on the blockchain without the need for intermediaries, enabling the automation of complex processes. This provides a flexible and powerful environment for developing and deploying decentralized applications. Smart contracts have expanded blockchain applications into areas such as finance (DeFi), supply chain management, and healthcare, making blockchain a versatile tool for ensuring transparency, efficiency, and trust in decentralized environments.

In the legal field, Sharifi introduced a formal contract specification language called Symboleo, which encodes obligations and rights into smart contracts [26]. Domestically, Wang Di proposed SPESC, which translates legal contracts into smart contract languages to enhance their legal validity [27]. Zhu Yan further designed rules for converting SPESC into Solidity, a high-level smart contract language [28]. To address the issue of smart contract performance, Zhang Fuli developed a microservice framework for smart contracts by decoupling consensus nodes from smart contracts [29]. Liu proposed parallel execution of transactions by execution nodes and asynchronous transaction ordering by consensus nodes, enabling parallel execution of smart contracts [30]. Wang Zikai introduced the SBFT consensus algorithm and a task-parallel smart contract model, optimizing the efficiency and scalability of smart contract execution [31].

3.2. Bilinear map

Given that 𝔾₁, 𝔾₂, and 𝔾_T are cyclic groups of prime order p, if there exists a mapping e such that e :  𝔾₁ × 𝔾₂ → 𝔾_T, satisfying the following properties, then this mapping is called a bilinear map:

(1) Bilinearity: For any α, β ∈ ℤ_p, g₁ ← 𝔾₁, g₂ ← 𝔾₂, it holds that $e(g_1^{\alpha },g_2^{\beta })={e(g_1,g_2)}^{\alpha \beta }$.

(2) Non-degeneracy: There exist g₁ ← 𝔾₁, g₂ ← 𝔾₂ such that e(g₁, g₂)≠1.

(3) Computability: For any g₁ ← 𝔾₁, g₁ ← 𝔾₁, there exists an efficient algorithm to compute e(g₁, g₂).

Reference [32] defines three types of bilinear maps: Type 1: 𝔾₁ = 𝔾₂, also known as symmetric pairing. Type 2: 𝔾₁ ≠ 𝔾₂, but there exists an efficient homomorphic mapping ⌀ : 𝔾₂ → 𝔾₁. Type 3: 𝔾₁ ≠ 𝔾₂, and there does not exist an efficient homomorphic mapping from 𝔾₂ to 𝔾₁. The scheme proposed in this paper is based on Type 3 bilinear maps.

3.3. Cryptographic assumptions

(1) q-DL Assumption

Given that 𝔾₁ and 𝔾₂ are two cyclic groups of order p, with g₁ and g₂ being generators of groups 𝔾₁ and 𝔾₂ respectively, it is computationally hard to solve for the integer x from the given (q+3)-tuple $(g_1,g_1^x,g_1^{x^2},\dots ,g_1^{x^q},g_2,g_2^x)$.

(2) q-SDH Assumption

Given 𝔾₁ and 𝔾₂ are two cyclic groups of order p, with g₁ and g₂ being generators of groups 𝔾₁ and 𝔾₂ respectively, it is computationally hard to output the pair $(g_1^{1/(x+c)},c)$ from the given (q+3)-tuple $(g_1,g_1^x,g_1^{x^2},\dots ,g_1^{x^q},g_2,g_2^x)$, where x, c ∈ ℤ_p.

(3) DLIN Assumption

Given 𝔾₁ is a cyclic group of order p it is computationally hard to determine if c = a + b holds from a set of elements U, V, W, U^a, V^b, W^c, where U, V, W are random elements in group 𝔾₁ and a, b, c ∈ ℤ_p are randomly chosen.

3.4. BBS signature

The BBS signature scheme was initially part of the BBS04 group signature scheme [14] and was explicitly defined as an independent signature scheme in literature [33]. The original BBS signature lacked security proof until 2023 when it was shown in the literature [34] that the BBS signature satisfies strong existential unforgeability under chosen message attack (SUF-CMA) under the q-SDH assumption. The BBS signature process is as follows:

(1) Setup(1^λ): Input the system parameter 1^λ to generate the Type 3 bilinear map (p, 𝔾₁, 𝔾₂, 𝔾_T, e). Let g₁ and g₂ be the generators of groups 𝔾₁ and 𝔾₂, respectively. Randomly select a group element h₁ ← 𝔾₁. Output the public parameters pp = (p, 𝔾₁, 𝔾₂, 𝔾_T, e, g₁, h₁, g₂).

(2) KeyGen(pp): Randomly choose x ∈ ℤ_p as the private key sk. Compute the public key $pk=g_2^x$.

(3) Sign(m, sk, pp): Input the message m ∈ ℤ_p and the private key sk. Randomly select an integer k ∈ ℤ_p and compute $A={(g_1·h_1^m)}^{1/(x+k)}$). Output the signature σ = (A, k).

(4) Verify(σ, m, pp): Verify if $e(A,g_2^k·pk)=e(g_1·h_1^m,g_2)$. If the equation holds, the signature is valid; otherwise, it is invalid.

3.5. Distributed digital identity

Distributed digital identity leverages blockchain technology to transform the traditional centralized identity control model into a distributed control model. It establishes an identity management layer for blockchain systems, enabling entities to own and manage their identity data. The distributed digital identity scheme designed in this paper follows the W3C standards, with its basic component structure illustrated in Figure 1.

Figure 1. Basic component relationships of decentralized identity

(1) Foundation Layer: DIDs serve as unique addresses for each entity, linked to detailed DID documents. These documents contain the entity’s public key information, authentication protocols, and service endpoints, facilitating multi-dimensional, flexible expression of identity and context-adaptive privacy protection.

(2) Application Layer: VCs are digitally issued certificates by authoritative entities, recording the attributes and qualifications of the entity in various contexts. Entities are allowed to independently hold and verify multiple identity attributes. VPs are composite proof structures built on VCs, enabling entities to provide comprehensive, cryptographically signed proofs of identity to third parties by selecting and combining multiple VCs.

4. Architecture design

In the regional equity market scenario, the participants–regulatory authorities, issuers, investors, and trading platforms–play distinct roles. The regulatory authority is assumed to be a trustworthy and secure entity, overseeing identity, transaction, and credential management to ensure compliance and market safety. Issuers and trading platforms are considered credible and legitimate institutions that closely collaborate with regulators and adhere to market rules. On the other hand, investors, whose identities and activities must be verified through credentials, are not regarded as fully trusted entities. Against this backdrop, the scheme is designed to protect identity and credential privacy while allowing regulatory oversight to ensure legal and transparent financial activities. Thus, the scheme does not pursue full decentralization but instead enhances system transparency and security through blockchain technology, striking a balance between regulatory oversight and privacy protection to ensure market transparency and safety.

This paper classifies DIDs into two categories, the overall architecture of digital identity management in this paper is illustrated in Figure 2.

Figure 2. Architecture of identity management

(1) Main Decentralized Identifiers (MDIDs): Users register with regulatory authorities using real-name information. Upon approval by the regulatory authority, users can possess and use an MDID, with each user limited to one MDID.

(2) Proxy Decentralized Identifiers (PDIDs): Users can independently generate multiple PDIDs. In this paper, only the regulatory authority can associate PDIDs with MDIDs.

The specific process is as follows:

(1) Real-name Registration: Users undergo real-name authentication with the regulatory authority. Upon successful authentication, the regulatory authority registers an MDID for the user via a smart contract and signs the MDID with their private key, serving as the user’s identity regulatory key.

(2) PDID Generation: Based on their MDIDs and identity regulatory key, users independently generate unique PDIDs and corresponding regulatory information, uploading them to the blockchain for automatic verification by the smart contract.

(3) Dispute or Violation Resolution: In case of disputes or violations, the regulatory authority uses the regulatory information of PDIDs to trace the user’s real identity and revoke the corresponding DIDs if necessary.

(4) VC Application: Users apply for VCs using any DIDs and their identity attributes. The issuer verifies the attributes and issues the VCs.

(5) VC Verification: Users randomize and combine their VCs into a VP as required by the verifier, hiding unnecessary attribute values. The verifier validates the VP’s signature to determine its validity.

(6) VC Revocation: The VC issuer can update the accumulator and the revocation list on the blockchain, thereby revoking a specific VC.

(7) Credential Updates: Users check the latest revocation list and update their credentials accordingly, ensuring that revoked credentials are no longer usable.

SR-DIDs and SR-PP-VC schemes are designed to work in tandem to achieve regulatory oversight and revocability of decentralized identities (DIDs) and verifiable credentials (VCs) within the system. The SR-DIDs scheme focuses on the management of decentralized identifiers, ensuring that user identities remain anonymous while providing regulatory authorities the ability to recover the true identity through regulatory information when necessary. It allows for the creation of proxy DIDs, which can be traced back to the main DIDs under certain regulatory conditions, ensuring both privacy and accountability.

On the other hand, the SR-PP-VC scheme extends the regulatory and revocation capabilities to the verifiable credentials associated with these DIDs. By utilizing BBS signatures and dynamic accumulators, the SR-PP-VC scheme enables selective disclosure of credential attributes while ensuring that VCs can be reliably revoked in real-time. The two schemes complement each other: SR-DIDs manage the identity layer by handling DIDs, and SR-PP-VC manages the credential layer by ensuring the privacy, regulatory compliance, and revocation of credentials. Together, they provide a cohesive framework for privacy protection and regulatory oversight in decentralized identity systems.

5. Regulated and revocable DIDs management scheme

5.1. Scheme definition

The SR-DIDs scheme comprises eight algorithms, described as follows:

(1) Public System Parameter GenerationSetUp(1^λ)→pp: Input the system security parameter 1^λ. Output the system public parameters pp, which include the DIDs generation base DR used for constructing entity DIDs.

(2) Regulator Key Pair GenerationRegulatorKeyGen(pp)→(RSK, RPK, DIDsRL): Executed by the regulator, input the public parameters pp. Output the regulator’s private key RSK, public key RPK, and DIDs revocation list DIDsRL.

(3) MDIDs Request GenerationMDIDsReqGen(pp)→(UMDIDsReq, umsk, d_m): Executed by the users, input the public parameters pp, output MDIDs-registration request UMDIDsReq, user’s master secret key umsk, and user’s MDID-associated key d_m. The UMDIDsReq includes the main identity identifier UMDIDs to be registered.

(4) MDIDs RegistrationMDIDsReg(pp, MDIDsReq, RSK)→(USK): Executed by the regulator, input the public parameters pp, the user’s MDID registration request MDIDsReq, and the regulator’s private key RSK. Output the user’s identity regulatory key USK.

(5) PDIDs GenerationUserPDIDsGen(pp, umsk, d_p, RPK, USK, UMDIDs)→(UPDIDs, UPProof): Executed by the users. Input the public parameters pp, the user’s master secret key umsk, the user’s PDID-associated key d_p, the regulator’s public key RPK, the user’s identity regulatory key USK, and the user’s main decentralized identity identifier UMDIDs. Output the user’s proxy decentralized identity identifier UPDIDs and its regulatory information UPProof.

(6) User PDIDs VerificationUserPDIDsVer(pp, RPK, UPDIDs, UPProof)→(0/1): Executed by the smart contract automatically, input the public parameters pp, the regulator’s public key RPK, the user’s proxy decentralized identity identifier UPDIDs, and its regulatory information UPProof. Output 1 if the verification passes; 0 otherwise.

(7) Identity SupervisionSupervise(UPDIDs, UPProof, RSK)→(USK): Executed by the regulator, input the user’s UPDIDs, its regulatory information UPProof, and the regulator’s private key RSK. Output the identity regulatory key USK corresponding to the PDIDs.

(8) Identity RevocationDIDsRevoke(RevDIDs)→(DIDsRL): Executed by the regulator, input the identifiers to be revoked RevDIDs. Update the DID revocation list DIDsRL to render RevDIDs invalid within the system.

5.2. Security model

The security properties of the SR-DIDs scheme include anonymity, unforgeability, regulatory reliability, and revocation reliability. This scheme uses the following lists and oracles to describe its security properties:

ℒ_{H_U}, ℒ_{C_U}: Lists of honest and corrupt users, respectively, recording the indices i of honest and corrupt users. ℒ_{H_U} ∩ ℒ_{C_U} = ⌀.

ℒ_PDIDs, ℒ_{d_p}: Lists of PDIDs and their corresponding PDID keys, recording the users’ PDIDs and the keys associated with those PDIDs. For example, ℒ_PDIDs[i] denotes the set of PDIDs owned by user i. ℒ_{d_p} corresponds one-to-one with each element in ℒ_PDIDs.

Oracle for Honest Users 𝒪_{H_U}(i): Adversary 𝒜 queries this oracle with user identifier i to add a new user i. If i ∈ ℒ_{H_U} ∪ ℒ_{C_U}, return ⊥. Otherwise, execute MDIDsReqGen(pp, umsk[i],d_m[i]) → (MDIDsReq[i]) and update ℒ_{H_U} = ℒ_{H_U} ∪ {i}, then return ⊤.

Oracle for Corrupt Users 𝒪_{C_U}(i): Adversary 𝒜 queries this oracle with user identifier i to obtain the user’s identity information. If i ∉ ℒ_{H_U} ∪ ℒ_{C_U}, return ⊥. If i ∈ ℒ_{H_U}, update ℒ_{H_U} = ℒ_{H_U} − {i} and ℒ_{C_U} = ℒ_{C_U} ∪ {i}. Then return USK[i],MDIDsReq[i], umsk[i],d_m[i],ℒ_PDIDs[i],ℒ_{d_p}[i].

Oracle for MDIDs 𝒪_MDIDs(i): Adversary 𝒜 queries this oracle with user identifier i to obtain the identity regulatory key signed by the regulator for the user’s MDIDs. If i ∉ ℒ_{H_U} ∪ ℒ_{C_U}, return ⊥. Otherwise, execute MDIDsReg(pp, MDIDsReq[i],RSK[i]) → (USK[i]). If i ∈ ℒ_{H_U}, return ⊤. If i ∈ ℒ_{C_U}, return USK[i].

Oracle for PDIDs 𝒪_PDIDs(i): Adversary 𝒜 queries this oracle with user identifier i to generate the PDIDs and their regulatory information for user i. If i ∉ ℒ_{H_U} ∪ ℒ_{C_U}, return ⊥. Otherwise, execute UserPDIDsGen(pp, d_p, RPK, USK[i],UMDIDs[i]) → (UPDIDs, UPProof) and update (ℒ_PDIDs[i], ℒ_{d_p}[i]) = (ℒ_PDIDs[i],ℒ_{d_p}[i]). If i ∈ ℒ_{C_U}, return ⊤. If i ∈ ℒ_{C_U}, return UPDIDs, UPProof.

Supervision Oracle 𝒪_Sup(UPDIDs, UPProof): Adversary 𝒜 queries this oracle with UPDIDs and their regulatory information UPProof to obtain the user’s identity regulatory key. If UPDIDs ∉ ℒ_PDIDs, return ⊥. Otherwise, execute Supervise(UPDIDs, UPProof, RSK)→(USK[i]) and return USK[i].

Oracle for Public Information 𝒪_W: Adversary 𝒜 can query this oracle to obtain all public MDIDs, PDIDs, and their regulatory information from the blockchain system.

(1) Anonymity

In the SR-DIDs scheme, anonymity is defined as: except for the regulator, no other entities in the system can infer a user’s identity information through DIDs or the regulatory information of PDIDs. Therefore, the anonymity of the SR-DIDs scheme also ensures the unlinkability of DIDs.

$$\begin{array}{c}\hfill \begin{array}{c}Pr[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ RegulatorKeyGen(pp)\to (RSK,RPK,DIDsRL);\\ {\mathcal{A}}^{\mathcal{O}}(pp,RPK,DIDsRL)\to \{i_0,i_1\};\\ \mathcal{C}(pp,i_b)\to (UMDIDs\left[i_b\right],{\mathit{UPDIDs}}_{i_b},{\mathit{UPProof}}_{i_b});\\ \mathcal{A}(pp,UMDIDs\left[i_b\right],{\mathit{UPDIDs}}_{i_b},{\mathit{UPProof}}_{i_b})\to b^{\ast }\\ \end{array}:b^{\ast }=b]-\frac{1}{2}\end{array}\end{array}$$(1)

(2) Unforgeability

In the SR-DIDs scheme, unforgeability is defined as: without the regulator’s private key, no attacker can generate verifiable PDIDs and their regulatory information.

$$\begin{array}{c}\hfill \begin{array}{c}Pr\left[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ RegulatorKeyGen(pp)\to (RSK,RPK,DIDsRL);\\ {\mathcal{A}}^{\mathcal{O}}(pp,RPK,DIDsRL)\to ({\mathit{UPDIDs}}^{\ast },{\mathit{UPProof}}^{\ast });\\ UserPDIDsVer(pp,RPK,{\mathit{UPDIDs}}^{\ast },{\mathit{UPProof}}^{\ast })\to b^{\ast }:\\ (b^{\ast }=1),(i\notin {\mathcal{L}}_{C\_U}),({\mathit{UPDIDs}}^{\ast }\notin {\mathcal{L}}_{\mathit{PDIDs}})\\ \end{array}\right]\end{array}\end{array}$$(2)

(3) Regulatory Reliability

In the SR-DIDs scheme, regulatory reliability is defined as: except for the regulator, even if users collude, no attacker can construct regulatory information that can pass system verification while preventing the regulator from tracing the real identity information. Therefore, the regulatory reliability of the SR-DIDs scheme also ensures traceability, for users operating honestly, the regulator can recover the user’s regulatory key from the PDIDs’ regulatory information.

$$\begin{array}{c}\hfill \begin{array}{c}Pr\left[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ RegulatorKeyGen(pp)\to (RSK,RPK,DIDsRL);\\ {\mathcal{A}}^{\mathcal{O}}(pp,RPK,DIDsRL)\to ({\mathit{UPDIDs}}^{\ast },{\mathit{UPProof}}^{\ast });\\ UserPDIDsVer(pp,RPK,{\mathit{UPDIDs}}^{\ast },{\mathit{UPProof}}^{\ast })\to b^{\ast }:\\ {(b}^{\ast }=1),(Supervise({\mathit{UPDIDs}}^{\ast },{\mathit{UPProof}}^{\ast },RSK)\ne URSK[i])\\ \end{array}\right]\end{array}\end{array}$$(3)

(4) Revocation Reliability

In the SR-DIDs scheme, revocation reliability is defined as: if the regulator chooses to revoke a particular DID, that DID can no longer be used, and attackers in the system cannot prevent the regulator from revoking DIDs or reactivating revoked DIDs.

5.3. Scheme design

(1) SetUp(1^λ)→pp: First, input the system parameter 1^λ to generate a Type 3 bilinear map (p, 𝔾₁, 𝔾₂, 𝔾_T, e) and the integer group ℤ_p. Choose the generators g₁ and g₂ for groups 𝔾₁ and 𝔾₂ respectively. Then, randomly select two different group elements DSK, DRand ← 𝔾₁, and set the DID generation base as DR = (DSK, DRand). Also, select a cryptographic hash function ℋ : {0,  1}^* → {0,  1}^* that is one-way and collision-resistant. Finally, output the public parameters pp = (p, 𝔾₁,  𝔾₂,  𝔾_T, ℤ_p, g₁, g₂, e, ℋ, DR).

(2) RegulatorKeyGen(pp)→(RSK, RPK, DIDsRL): The regulator first selects an integer y ∈ ℤ_p and computes $\overline{Y}=g_2^y$. Then, select integers u, v ∈ ℤ_p, and let $U=g_1^u$, $V=g_1^v$, and W =  U^v, which implies $W=U^v=V^u=g_1^{\mathit{uv}}$. Set the regulator’s private key as (y, u, v) and the public key as $(\overline{Y},U,V,W)$. The private key is stored locally, while the public key is made public on the blockchain. Finally, initialize the DID revocation list DIDsRL as an empty list and upload it to the blockchain.

(3) MDIDsReqGen(pp)→(MDIDsReq, umsk, d_m): The user first selects an integer umsk ∈ ℤ_p as their master private key. Then, select an MDID key d_m ∈ ℤ_p and generate the MDID based on the Pedersen commitment: UMDIDs =  DSK^umsk ⋅ DRand^d_m. Finally, integrate the user’s real-name identity information info into the registration request UMDIDsReq = (UMDIDs, info) and send it to the regulator.

(4) MDIDsReg(pp, MDIDsReq, RSK)→(USK): Upon receiving the user’s registration request UMDIDsReq, the regulator first verifies the info and checks whether the UMDIDs has already been registered in the system. If it is already registered, the application is invalid. If verified correctly, the regulator selects an integer k_u ∈ ℤ_p and signs the user’s MDIDs with a BBS signature: compute K = (g₁ ⋅ UMDIDs)^{1/(y + k_u)}. Finally, send USK = (k_u, K) to the user as their identity regulatory key, and store info, UMDIDs, and USK = (k_u, K)) in the regulator’s private table RSList. The UMDIDs are then activated on the blockchain.

(5) UserPDIDsGen(pp, d_p, RPK, USK, UMDIDs)→(UPDIDs, UPProof): Users independently generate PDIDs based on their identity regulatory key to prevent other entities from tracking and linking.

① The user randomly selects r₁, r₂ ∈ ℤ_p and encrypts the identity regulatory key using DLIN: R₁ = U^1/r₁, R₂ = V^r₂, R₃ = K ⋅ W^{1/r₁ + r₂}. Then, randomize the calculation $\overline{K}=K^{r_1}$, and $\overline{J}={\overline{K}}^{-k_u}·{(g_1·UMDIDs)}^{r_1}$.

② Select a PDID key d_p ∈ ℤ_p and compute the PDID based on the Pedersen commitment: UPDIDs =  DSK^umsk ⋅ DRand^d_p. Calculate t₁ = d_p − d_m and t₂ = k_u/r₁.

③ The user generates a zero-knowledge proof of knowledge for the correct generation of MDIDs, identity regulatory key, and PDIDs: ${{\pi }_1=NIZK-PoK}_1\{r_1,r_2,t_1,t_2|R_1=U^{1/r_1}\wedge R_2=V^{r_2}\wedge R_3={\overline{K}}^{1/r_1}·W^{1/r_1+r_2}\wedge \overline{J}={(\overline{K}}^{-t_2}·{g_1·UPDIDs·{\mathit{DRand}}^{{-t}_1})}^{r_1}\}$

a. Randomly select ${\overline{r}}_1,{\overline{r}}_2,{\overline{r}}_{t_1},{\overline{r}}_{t_2}\in {\mathbb{Z}}_p$ and compute auxiliary values for the zero-knowledge proof: $R_1\prime =U^{{\overline{r}}_1}$, $R_2\prime =V^{{\overline{r}}_2}$, $R_3\prime ={\overline{K}}^{{\overline{r}}_1}·W^{{\overline{r}}_1+{\overline{r}}_2}$, and $T_1\prime ={\overline{J}}^{{\overline{r}}_1}·{{\overline{K}}^{{\overline{r}}_{t_2}}·DRand}^{{\overline{r}}_{t_1}}$.

b. Compute the challenge value: $c_1=\mathcal{H}(\overline{K},\overline{J},UPDIDs,R_1,R_2,R_3,R_1\prime ,R_2\prime ,R_3\prime ,T_1\prime )$.

c. Compute the s-values: $s_{r_1}={\overline{r}}_1+c_1/r_1$, $s_{r_2}={\overline{r}}_2+c_1·r_2$, $s_{t_1}={\overline{r}}_{t_1}+c_1·t_1$, and $s_{t_2}={\overline{r}}_{t_2}+c_1·t_2$.

d. Generate the zero-knowledge proof π₁ = (s_r1, s_r2, s_t1, s_t2, c₁).

④ Set the regulatory information for the user’s PDIDs as $UPProof=(\overline{K},\overline{J},R_1,R_2,R_3,{\pi }_1)$, and the user uploads (UPDIDs, UPProof) to the blockchain system.

(6) UserPDIDsVer(pp, RPK, UPDIDs, UPProof)→(0/1): In the blockchain system, the user-generated PDIDs can be treated as a transaction, which is automatically verified by a smart contract.

① Check if UPDIDs already exist on the blockchain. If it does, the registration is rejected. Otherwise, verify if $e(\overline{K},\overline{Y})=e(\overline{J},g_2)$. If it does not hold, the application is invalid. If it holds, proceed to the next verification step.

② Compute auxiliary values for verification: $R_1″=U^{s_{r_1}}·R_1^{-c_1}$, $R_2″=V^{s_{r_2}}·R_2^{-c_1}$, $R_3″={\overline{K}}^{s_{r_1}}·W^{s_{r_1}+s_{r_2}}·{R_3}^{-c_1}$, and $T_1″={\overline{J}}^{s_{r_1}}·{\overline{K}}^{s_{t_2}}·{\mathit{DRand}}^{s_{t_1}}·{(g_1·UPDIDs)}^{-c_1}$.

③ Based on the public parameters and auxiliary values, compute the challenge value: $c_1\prime =\mathcal{H}(\overline{K},\overline{J},UPDIDs,R_1,R_2,R_3,R_1″,R_2″,R_3″,T_1″)$. Then verify if $c_1\prime =c_1$. If it holds, the application is approved and UPDIDs is activated, outputting 1; otherwise, it is rejected, outputting 0.

(7) Supervise(UPDIDs, UPProof, RSK)→(USK): The regulator can access the PDIDs information (UPDIDs, UPProof) from the blockchain at any time, then perform DLIN decryption: $K\prime =R_3/(R_1^v·R_2^u)$ to obtain one of the user’s identity regulatory keys K′. The regulator compares it with their database RSList to retrieve USK, info and UMDIDs, thereby obtaining the real identity of the user applying for the PDIDs. The UPDIDs is then associated with the user’s UMDIDs and added to the RSList. Subsequently, the regulator can directly query the user’s real identity through UPDIDs.

(8) DIDsRevoke(RevDIDs)→(DIDsRL): If a particular DID RevDIDs needs to be revoked, the regulator updates the DID revocation list DIDsRL = DIDsRL ∪ {RevDIDs} via a smart contract, rendering RevDIDs invalid.

5.4. Security analysis

(1) Anonymity

(2) Unforgeability

(3) Regulatory Reliability

6. Regulatorily accountable and revocable VC privacy protection scheme

6.1. Scheme definition

The SR-PP-VC scheme consists of eight main algorithms, described as follows:

(1) Public System Parameter GenerationSetUp(1^λ)→pp: Input the system security parameter 1^λ and output the system public parameters pp.

(2) VC Issuer Key GenerationVCIssuerKeyGen(pp)→(VCISK, VCIPK): Executed by the VC issuer, input the public parameters pp, and output the VC issuer’s private key VCISK and public key VCIPK.

(3) VC Request GenerationVCRequestGen(pp, m, VCIPK, VCDIDs)→(VCReq): Executed by the user, input the public parameters pp, attribute information m, the VC issuer’s public key VCIPK, and the identifier VCDIDs used when applying for the VC. Output the VC request VCReq.

(4) VC GenerationVCGen(pp, VCReq, VCISK, VCIPK)→(VC): Executed by the VC issuer, input the public parameters pp, the user’s VC request VCReq, the VC issuer’s private key VCISK, and the VC issuer’s public key VCIPK. Output VC signed by the VC issuer.

(5) VC RevocationVCRev(VCISK, VCIPK, VC)→(VCIPK′): Executed by the VC issuer, input the VC issuer’s private key VCISK, the VC issuer’s public key VCIPK, and the VC to be revoked. Output the updated VC issuer’s public key VCIPK′.

(6) VC UpdateVCUpdate(VCIPK′,VC)→(VC′): Executed by the user with a non-revoked VC, input the updated VC issuer’s public key VCIPK′ and their VC. Output the updated VC′, which the user needs to use for future presentations.

(7) VP GenerationVPGen(pp, VCIPKSet, VCSet, dSet, VPDIDs, d_vp)→(VP): Executed by the user, input the public parameters pp, the set of VCs to be combined into the VP VCSet, the set of public keys corresponding to the VCs VCIPKSet, the set of keys corresponding to the VCs’ DIDs dSet, the identifier VCDIDs used for the VP presentation, and the key d_vp corresponding to this identifier. Output the selectively disclosed verifiable presentation VP.

(8) VP VerificationVPVer(pp, VCIPKSet, VP, VPDIDs)→(0/1): Executed by the verifier, input the public parameters pp, the selectively disclosed presentation VP, the set of public keys of the VC issuers included in the presentation VCIPKSet, and the identifier VCDIDs used for the presentation. Output 0 or 1, where 1 indicates the verification is successful, and 0 indicates failure.

6.2. Security model

The security properties of the SR-PP-VC scheme include anonymity, unforgeability, regulatory reliability, and revocation reliability. This scheme constructs a formal definition of security properties using a single VC issuer and a VP composed of a single VC. If an extension to multiple VC issuers and VPs composed of multiple VCs is required, the corresponding public and private keys for the issuers need to be generated. The scheme uses the following lists and oracles to describe the security model:

ℒ_{H_U}, ℒ_{C_U}: Lists of honest and corrupt users, respectively, recording the indices i of honest and corrupt users, ℒ_{H_U} ∩ ℒ_{C_U} = ⌀.

ℒ_DIDs, ℒ_{DIDs_sk}: Lists of users’ DIDs (including MDIDs and PDIDs) and the corresponding keys.

ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs: Lists of VC owners, VCs, VC attribute sets, and DIDs used to apply for VCs, respectively. Elements in ℒ_Owner, ℒ_VC, ℒ_m and ℒ_VCDIDs correspond one-to-one.

ℒ_VP, ℒ_VPDIDs: Lists of VPs and the DIDs used to present the VPs, recording the VPs that users have presented and the DIDs used during the presentation.

ℒ_RevVC: List of revoked VCs.

Oracle for Honest Users 𝒪_{H_U}(i): Adversary 𝒜 queries this oracle with user identifier i to add new user i, if i ∉ ℒ_{H_U} ∪ ℒ_{C_U}, executing ℒ_{H_U} = ℒ_{H_U} ∪ {i}.

Oracle for Corrupt Users 𝒪_{C_U}(i): Adversary 𝒜 queries this oracle with user identifier i to obtain all identity information of the user, including the VCs the user owns, the set of DIDs, and the corresponding keys.

Oracle for VC 𝒪_VC(i, m): Adversary 𝒜 queries this oracle with user identifier i and attribute information m to generate a VC for the user. If i ∉ ℒ_{H_U}, return ⊥. Otherwise, randomly select VCDIDs ∈ ℒ_DIDs[i] and ensure VCDIDs ∩ ℒ_VCDIDs = ⌀. Execute the VCRequestGen and VCGen algorithms, updating (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs)=({i},{VC},{m},{VCDIDs}) ∪ (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs), and return ⊤.

Oracle for VC Request 𝒪_VCReq(i, m): Adversary 𝒜 queries this oracle with user identifier i and attribute information m to obtain a VC request. If i ∉ ℒ_{H_U}, return ⊥. Otherwise, randomly select VCDIDs ∈ ℒ_DIDs[i] and ensure VCDIDs ∩ ℒ_VCDIDs = ⌀. Execute the VCRequestGen algorithm, updating (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs)=({i},{⊥},{m},{VCDIDs}) ∪ (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs), and return VCReq, VCDIDs.

Oracle for VC Generation 𝒪_VCGen(i, m, VCDIDs, VCReq): Adversary 𝒜 queries this oracle with user identifier i, attribute information m, the identifier VCDIDs used to apply for the VC, and the VC request parameters VCReq to obtain a VC. If i ∉ ℒ_{H_U}, return ⊥. Otherwise, execute the VCGen algorithm, updating (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs)=({i},{VC},{m},{VCDIDs}) ∪ (ℒ_Owner, ℒ_VC, ℒ_m, ℒ_VCDIDs), and return VC.

Oracle for VP Generation 𝒪_VP(j): Adversary 𝒜 queries this oracle with VC index j to obtain a VP. Assume i = ℒ_Owner[j]. If i ∉ ℒ_{H_U} or ℒ_VC[j]∈ℒ_RevVC, return ⊥. Otherwise, set VCDIDs = ℒ_VCDIDs[j] and d_vc as the corresponding key. Randomly select VPDIDs ∈ ℒ_DIDs[i] and its corresponding key d_vp, ensuring VPDIDs ∩ ℒ_VPDIDs = ⌀. Execute VPGen(pp, VCIPK, ℒ_VC[j],d_vc, VPDIDs, d_vp)→(VP), and update (ℒ_VP, ℒ_VPDIDs)=(ℒ_VP, ℒ_VPDIDs)∪({VP},{VPDIDs}), then return VP,  VPDIDs.

Oracle for VC Revocation 𝒪_VCRev(j): Adversary 𝒜 queries this oracle with VC index j to revoke the VC. Execute VCRev(VCISK, VCIPK, ℒ_VC[j]) → (VCIPK) and update ℒ_RevVC = ℒ_RevVC ∪ {ℒ_VC[j]}. For all k  <  ℒ_VC.length and k ≠ j, execute (VCUpdate(VCIPK, ℒ_VC[k]) → ℒ_VC[k]). Finally, return VCIPK.

(1) Anonymity

In the SR-PP-VC scheme, anonymity is defined as except for the regulator, no other entities can infer a user’s identity information through DIDs. Additionally, VC issuers and verifiers can only access the necessary disclosed information within the user’s VC or VP and cannot learn more about the user’s identity attributes. Even if the same credential is used with different DIDs to disclose different attributes at different times, verifiers cannot link these presentations to the same user or credential, ensuring the unlinkability of DIDs and VPs.

$$\begin{array}{c}\hfill \begin{array}{c}Pr[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ VCIssuerKeyGen(pp)\to (VCISK,VCIPK);\\ {\mathcal{A}}^{\mathcal{O}}(pp,VCIPK)\to \{i_0,i_1,m^{\ast }\};\\ \mathcal{C}(pp,i_b,m^{\ast })\to ({\mathit{VP}}_{i_b},{\mathit{VPDIDs}}_{i_b});\\ \mathcal{A}(pp,{\mathit{VP}}_{i_b},{\mathit{VPDIDs}}_{i_b})\to b^{\ast }\\ \end{array}:b^{\ast }=b]-\frac{1}{2}\\ \end{array}\end{array}$$(4)

(2) Unforgeability

In the SR-PP-VC scheme, unforgeability is defined as without the VC issuer’s private key, no attacker can generate a verifiable VP, even if they have obtained multiple VPs from honest users. Additionally, users cannot modify any attribute values in an issued VC.

$$\begin{array}{c}\hfill \begin{array}{c}Pr\left[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ VCIssuerKeyGen(pp)\to (VCISK,VCIPK);\\ {\mathcal{A}}^{\mathcal{O}}(pp,VCIPK)\to ({\mathit{VP}}^{\ast },{\mathit{VPDIDs}}^{\ast },m^{\ast });\\ VPVer(pp,VCIPK,{\mathit{VP}}^{\ast },{\mathit{VPDIDs}}^{\ast })\to b^{\ast }:\\ (b^{\ast }=1),(m^{\ast }\notin {\mathcal{L}}_m\vee \\ ({\mathit{VP}}^{\ast }\notin {\mathcal{L}}_{\mathit{VP}},{\mathit{VPDIDs}}^{\ast }\notin {\mathcal{L}}_{\mathit{VPDIDs}}))\\ \end{array}\right]\end{array}\end{array}$$(5)

(3) Regulatory Reliability

In the SR-PP-VC scheme, regulatory reliability is defined as the regulator can correctly trace a user’s real identity information from the DIDs associated with the selectively disclosed VC.

(4) Revocation Reliability

In the SR-PP-VC scheme, revocation reliability is defined as: users with revoked VCs cannot forge a valid VC.

$$\begin{array}{c}\hfill \begin{array}{c}Pr\left[\begin{array}{c}SetUp\left(1^{\lambda }\right)\to pp;\\ VCIssuerKeyGen(pp)\to (VCISK,VCIPK);\\ {\mathcal{A}}^{\mathcal{O}}(pp,VCIPK,VC\in {\mathcal{L}}_{\mathit{RevVC}},VPDIDs)\to \left({\mathit{VP}}^{\ast }\right);\\ VPVer(pp,VCIPK,{\mathit{VP}}^{\ast },VPDIDs)\to b^{\ast }:\\ b^{\ast }=1\\ \end{array}\right]\end{array}\end{array}$$(6)

6.3. Scheme design

(1) SetUp(1^λ)→pp: This algorithm is the same as the SetUp algorithm in the SR-DIDs scheme. Output public parameters pp = (p, 𝔾₁,  𝔾₂,  𝔾_T, ℤ_p, g₁, g₂, e, ℋ, DR).

(2) VCIssuerKeyGen(pp)→(VCISK, VCIPK): The VC issuer selects an integer x ∈ ℤ_p and computes $\overline{X}=g_2^x$. Assume the number of attributes in the issued VC is l, set the attribute name list as AttrNames = [name₁, …, name_l], and randomly choose HATTR = (HAttr₁, …, HAttr_l)←𝔾₁. Then choose ${\tilde{g}}_1\leftarrow {\mathbb{G}}_1$, initialize the accumulator $\mathrm{\Delta }={\tilde{g}}_1$, and generate an empty VC revocation list VCRList = ⌀. Finally, output the VC issuer’s private key VCISK = x and public key $VCIPK=(\overline{X},AttrNames,HATTR,\mathrm{\Delta },VCRList)$. The VC issuer stores VCISK locally and uploads VCIPK to the blockchain in the issuer’s corresponding DID document.

(3) VCRequestGen(pp, m, VCIPK, VCDIDs)→(VCReq): Users can apply for a VC using any of their DIDs. Assume the DID used is VCDIDs = DSK^umsk ⋅ DRand^d_vc. The user provides their attribute information m based on the attribute name list AttrName, let m = (m₁, …, m_l)∈ℤ_p. The user’s attribute values are divided into two types: attributes to be hidden from the VC issuer (set HI) and attributes that do not need to be hidden (set NHI). The user computes the commitment of the hidden attributes: C_HI = g₁∏_i ∈ HIHAttr_i^m_i. The VC request parameters are VCReq = (C_HI, (m_i)_{i ∈ NHI}), which are sent to the VC issuer via VCDIDs.

(4) VCGen(pp, VCReq, VCISK, VCIPK)→(VC):

① The VC issuer verifies the validity of the applicant’s VCDIDs and (m_i)_{i ∈ NHI}. If valid, the issuer signs the user’s attributes. First, compute C = C_HI ⋅ VCDIDs ⋅ Δ ⋅ ∏_{i ∈ NHI}HAttr_i^m_i. Then, select an integer k ∈ ℤ_p and compute the BBS signature A = C^{1/(x + k)} and the validity proof Valid = Δ^{1/(x + k)}. Finally, send the attribute signature Sign = (A, C, k, Valid) to the user and store (Sign, VCDID, k, C_HI, (m_i)_{i ∈ NHI}) in the local database.

② Upon receiving Sign, the user can verify its validity by checking if $C=g_1·VCDIDs·\mathrm{\Delta }·\prod _i^l{{\mathit{HAttr}}_i}^{m_i}$ and $e(A·Valid,\overline{X})=e(C·A^{-k}·\mathrm{\Delta }·{\mathit{Valid}}^{-k},g_2)$ hold. If valid, the user generates the VC certificate VC = (A, C, k, Valid, m) and stores it locally; otherwise, the signature is invalid.

(5) VCRev(VCISK, VCIPK, VC)→ (VCIPK′): The VC issuer first finds the information related to the VC to be revoked $(\mathit{Sign}\prime ,\mathit{VCDIDs}\prime ,k\prime ,C_{\mathit{HI}}\prime ,{(m_i\prime )}_{i\in NHI})$ in the local database. Set VCRList = VCRList ∪ {k′} and update the revocation accumulator Δ_new = Δ^{1/(x + k′)}. Finally, update the issuer’s public key on the blockchain to $\mathit{VCIPK}\prime =(\overline{X},AttrNames,HATTR,{\mathrm{\Delta }}_{\mathit{new}},VCRList)$.

(6) VCUpdate(VCIPK′,VC)→ (VC′): Users can check if the issuer’s public key has been updated. If updated and the revoked VCs does not belong to them, they need to update their VC. First, update the validity proof Valid_new = (Valid/Δ_new)^1/(k′−k). Then, update the VC signature A_new = A ⋅ Valid_new/Valid. Finally, update their VC to VC′=(A_new, k, Valid_new, m).

(7) VPGen(pp, VCIPKSet, VCSet, dSet, VPDIDs, d_vp)→(VP): Users can combine n VCs into a single VP, using any DID for presentation, and selectively disclose attributes. The variables in this algorithm are explained in Table 1.

① Compute C_DIj = g₁ ⋅ VPDIDs ⋅ Δ_j ⋅ ∏_{i ∈ DIj}HAttr_j, i^m_j, i for all j ∈ N. Randomly select r₃ ∈ ℤ_p and compute ${\overline{A}}_j=A_j^{r_3}$ for all j ∈ N, ${\overline{F}}_j={(C_j·A_j^{-k_j})}^{r_3}$ for all j ∈ N, and let $\overline{G}=\prod _{j\in N}{\overline{F}}_j$, t_dj = d_vcj − d_vp for all j ∈ N.

② Compute the zero-knowledge proof ${{\pi }_2=NIZK-PoK}_2\{r_3,{(k_j)}_{j\in N},{(t_{\mathit{dj}})}_{j\in N},{(m_{j,i})}_{j\in N,i\in {\mathit{NDI}}_j}|\overline{G}$= ${\prod _{j\in N}((C_{{\mathit{DI}}_j}·{\mathit{DRand}}^{t_{\mathit{dj}}}·\prod _{i\in NDI}{{\mathit{HAttr}}_{j,i}}^{m_{j,i}})}^{r_3}·{{\overline{A}}_j}^{-k_j})\}$: Randomly select ${\overline{r}}_3$, ${({\overline{r}}_{k_j})}_{j\in N}$,${({\overline{r}}_{t_j})}_{j\in N}$, ${{(\overline{\delta }}_{j,i})}_{j\in N,i\in {\mathit{NDI}}_j}\in {\mathbb{Z}}_p$, and compute the auxiliary value $\overline{G}\prime =\prod _{j\in N}({C_{{\mathit{DI}}_j}}^{{\overline{r}}_3}·{\overline{A}}_j^{-{\overline{r}}_{k_j}}·{\mathit{DRand}}^{{\overline{r}}_{t_j}}·\prod _{i\in {\mathit{NDI}}_j}{{\mathit{HAttr}}_{j,i}}^{{\overline{\delta }}_{j,i}})$. Compute the challenge value $c_2=\mathcal{H}(VPDIDs,{{(\overline{A}}_j)}_{j\in N},\overline{G},\overline{G}\prime )$ and $s_{r_3}={\overline{r}}_3+c_2·r_3$, $s_{k_j}={\overline{r}}_{k_j}+c_2·k_j$, $s_{t_j}={\overline{r}}_{t_j}+c_2·t_{\mathit{dj}}·r_3$ and $s_{{\delta }_{j,i}}={\overline{\delta }}_{j,i}+c_2·r_3·m_{j,i}$ for all j ∈ N and i ∈ NDI_j. Let π₂ = (c₂, s_r3, (s_kj)_j ∈ N, (s_tj)_j ∈ N, (s_δj, i)_{j ∈ N, i ∈ NDIj}).

③ Finally, generate $VP=({({\overline{A}}_j)}_{j\in N},\overline{G},{(m_{j,i})}_{j\in N,i\in {\mathit{DI}}_j},{\pi }_2)$ and send VP to the verifier via VPDIDs.

(8) VPVer(pp, VCIPKSet, VP, VPDIDs)→(0/1): Upon receiving the VP, the verifier first checks if $\prod _{j\in N}(e({\overline{A}}_j,{\overline{X}}_j))=e(\overline{G},g_2)$. If not, the VP is invalid. Otherwise, proceed to zero-knowledge proof verification:

① Compute the auxiliary value C_DIj = g₁ ⋅ VPDIDs ⋅ Δ_j ⋅ ∏_{i ∈ DIj}HAttr_j, i^m_j, i for all j ∈ N and $\overline{G}″={\overline{G}}^{-c_2}·\prod _{j\in N}({C_{{\mathit{DI}}_j}}^{s_{r_3}}·{\overline{A}}_j^{-s_{k_j}}·{\mathit{DRand}}^{s_{t_j}}·\prod _{i\in {\mathit{NDI}}_j}{{\mathit{HAttr}}_{j,i}}^{s_{{\delta }_{j,i}}})$, where Δ_j should be the latest value on the blockchain.

② Compute the challenge value $c_2\prime =\mathcal{H}(VPDIDs,{{(\overline{A}}_j)}_{j\in N},\overline{G},\overline{G}″)$;

③ Verify if $c_2\prime =c_2$. If so, the VP is valid, output 1; otherwise, output 0.

6.4. Security analysis

(1) Anonymity

(2) Unforgeability

(3)Regulatory Reliability

(4) Revocation Reliability

7. Scheme analysis and comparison

7.1. Security comparison

The security comparison of the SR-DIDs scheme, SR-PP-VC scheme, and related works are shown in Tables 2 and 3, respectively. It can be seen that, compared to other similar schemes, the proposed schemes in this paper provide more comprehensive security and privacy protection measures.

7.2. Performance testing

The experiments were conducted on a PC running Windows 10 Professional 64-bit, equipped with Intel(R) Core(TM) i7-11700 @ 2.50GHz processor and 16GB of RAM. The simulation tests used Hyperledger Fabric blockchain version 2.5.4, deployed via Docker with 2 peer nodes and 1 order node. The development was done in JAVA, utilizing the BLS12-381 bilinear pairing curves [36], implemented using the MIRACL library, and the SHA-384 algorithm for the hash function ℋ.

(1) Performance comparison of SR-DIDs scheme

This study implemented the ring signature-based regulatory scheme proposed in Reference [9] and the BBS04-SR-DIDs scheme designed based on the BBS04 group signature [14], as benchmarks for evaluating the performance of the SR-DIDs scheme. The BBS04-SR-DIDs scheme uses the original BBS04 group signature to construct the generation and verification mechanism of PDIDs, while SR-DIDs employs an optimized group signature algorithm, demonstrating the effect of optimization.

For example, the space complexity comparison of generating a single proxy identity identifier among the three schemes is shown in Table 4, where ℤ_p, 𝔾₁, 𝔾₂, 𝔾_T represent the element lengths in the groups ℤ_p, 𝔾₁, 𝔾₂, 𝔾_T, respectively. In the BLS12-381 curve, their sizes are 48 bytes, 48 bytes, 96 bytes, and 576 bytes, respectively, and k is the number of ring signature members. In the BLS12-381 curve, the SR-DIDs scheme shows an increase in the space complexity of the regulator’s key pair and the user’s key compared to Reference [9], but since it is generated once and can be reused, the additional 336 bytes of space is negligible compared to modern storage capacities. In Reference [9], the complexity of identity generation increases with the number of ring signature members k, and its security is positively correlated with k, leading to higher overall space consumption. The SR-DIDs scheme and the BBS04-SR-DIDs scheme have limited differences, with only an additional 48 bytes.

The time complexity of identity generation, verification, and regulation for the three schemes is also compared, as shown in Table 5, and implemented and tested through code. Here, E₁, M₁ represent exponentiation and multiplication operations in the group 𝔾₁, E_T, M_T represent exponentiation and multiplication operations in the group 𝔾_T, P represents bilinear pairing operations, and H represents hash operations. The experimental design follows the principle that the number of ring signature members in practical applications usually does not exceed 10, with k = 5 chosen for testing. Figure 3 shows the average time results for 100 executions of each scheme’s algorithm. The identity generation, verification, and regulation times for the SR-DIDs scheme are approximately 11.8 ms, 17.5 ms, and 0.81 ms, respectively.

Figure 3. Time comparison of identity identifier management

(2) Performance comparison of SR-PP-VC scheme

This study compares the space complexity of the SR-PP-VC scheme with the anonymous certificate management scheme (Idemix) on Hyperledger Fabric, using examples of issuer key pair storage, single VC storage, and VP generation, as shown in Table 6. The parameters l represent the number of attributes in a single credential, n represents the number of VCs in the VP, and h represents the total number of hidden attributes in the VP. Although Idemix does not have a direct implementation of VP, VP is essentially multiple VCs combined, so the complexity of managing a single credential in Idemix multiplied by the number of credentials n can be considered the VP management complexity for Idemix.

This section also compares the time complexity of single credential application and issuance, update, and VP generation and verification for the SR-PP-VC scheme and the Idemix scheme, as shown in Table 7. Here, s represents the total number of attributes in each VC in the VP. The study tests and compares the management of a single credential for both schemes. In practical applications, the number of attributes in a single credential generally does not exceed 30, so tests were conducted for l = 5,10,20,30, and for h values at 0%, 20%, 40%, 60%, 80%, and 100% of l. The average time for 100 executions of single credential application and issuance, credential presentation, and verification are shown in Figure 4. When the number of credential attributes is 30, the SR-PP-VC scheme’s time for single credential application and issuance is approximately 9.6 ms, the time for full attribute hiding presentation is approximately 12.8 ms, and the verification time is approximately 15.9 ms, representing efficiency improvements of approximately 35.6%, 23.6%, and 13.4% over the Idemix scheme, respectively.

Figure 4. Time comparison of single credential management

(3) Contract testing

Based on the SR-DIDs and SR-PP-VC schemes, we deployed the MDIDs registration contract, DID document management contract, DIDs resolution contract, PDIDs verification contract, and DIDs revocation contract on Hyperledger Fabric. 12We used the Apache JMeter testing tool, with the number of test threads set to 10,000, to conduct average single-run time and TPS (transactions per second) tests for these contracts. The results are shown in Figure 5. The DID document management contract registers, updates, or disables DID documents on the blockchain, corresponding to the updating of VC issuer public keys in this paper.

Figure 5. Test of smart contract

7.3. Result analysis

Based on the results of security analysis and performance analysis, the following conclusions can be drawn:

SR-DIDs Scheme: The complexities of identity generation, verification, and regulation in the SR-DIDs scheme are all constant, reducing computational and storage overhead compared to Reference [9]. While the SR-DIDs scheme consumes an additional 2|𝔾₁| − 1|ℤ_p| storage space for signatures compared to the original BBS04 group signature algorithm (generally not exceeding 100 bytes on mainstream bilinear pairing curves), it optimizes the time efficiency for identity generation and verification, improving generation efficiency by approximately 48% and verification efficiency by approximately 38%.

SR-PP-VC Scheme: Compared to the Idemix scheme, the SR-PP-VC scheme optimizes credential management and performance while adding regulatory and revocation mechanisms. It reduces storage overhead by (6n − 2)|ℤ_p| + (3n − 1)|𝔾₁|. Although the time complexity of VP generation in the SR-PP-VC scheme is O(s) compared to O(h) in the Idemix scheme, when the number of attributes in a single credential does not exceed 30, the overall efficiency of the SR-PP-VC scheme is superior to the Idemix scheme. Furthermore, as n increases, the SR-PP-VC scheme saves more time compared to the Idemix scheme, as shown in Table 7. For credential revocation, both the SR-PP-VC scheme and Reference [16] use accumulator technology. However, the SR-PP-VC scheme includes the credential revocation accumulator as one of the attributes signed by the issuer, allowing it to be verified along with other attributes, and reducing computational overhead. Additionally, the SR-PP-VC scheme does not require a fixed number of credential issuances, making it more suitable for practical scenarios.

PDIDs Verification Contract on Hyperledger Fabric: The throughput of the PDIDs verification contract in Hyperledger Fabric is 327, which is primarily due to the cryptographic operations involved in the verification process, as well as hardware limitations. However, in the context of regional equity markets, where the frequency of user identity management operations is relatively low and primarily focused on identity verification, credential management, and equity trading, this performance is sufficient to meet practical demands. Furthermore, deploying the system on a production-level Fabric network would significantly enhance performance by leveraging distributed nodes, more powerful hardware resources, and optimized consensus mechanisms. The dynamic expansion of nodes and organizations would also allow the system to scale effectively, ensuring stable operation under increased loads as the market grows.

In summary, the proposed distributed digital identity privacy protection scheme offers improvements in both security and performance compared to related works. Each algorithm operates at the millisecond level, meeting the requirements for blockchain identity management scenarios.

8. Conclusion

This paper designs a blockchain-driven, regulatorily accountable, and revocable distributed digital identity privacy protection scheme. While effectively protecting the privacy of entity identities, the scheme achieves reliable supervision and revocation of identity identifiers and credentials. By optimizing cryptographic algorithms, the efficiency of identity management is improved. Future research will focus on further optimizing the VP generation scheme to ensure that the size of VPs remains constant. Additionally, the concepts presented in this paper will be used to enhance and optimize more signature algorithms, enabling VC issuers to sign VCs using various signature schemes, thereby further enhancing system security.

Conflicts of Interest

The authors declare that they have no conflict of interest.

Data Availability

No data are associated with this article.

Authors’ Contributions

Jing He was responsible for the design of the proposed scheme, simulation experiments, and writing the paper; Xiaofeng Ma provided guidance on the innovation and architectural design of the scheme and reviewed and revised the paper; Dawei Zhang was responsible for the feasibility analysis of the paper’s proposal; Feng Peng was responsible for the verification of feasibility and experimental design.

Acknowledgments

We thank the anonymous reviewers for their helpful comments.

Funding

This work was supported by the National Key Research and Development Program of China. Research on Reliable Regulatory Technology Based on Blockchain of Regional Equity Market (2021YFC3340600).

References

Jing He is currently a master’s student at Tongji University, China. His main research interests include blockchain and privacy protection.

Xiaofeng Ma is an associate professor at Tongji University, China. He is also the vice chairman of the blockchain branch of the Chinese Institute of Electronics. His main research interests include blockchain and financial technology.

Dawei Zhangis an associate professor at Beijing Jiaotong University, China. His main research interests include information security and blockchain.

Feng Peng is a senior engineer of China Securities Information Technology Service Limited Company. His main research interests include blockchain and financial technology.

All Tables

All Figures

	Figure 1. Basic component relationships of decentralized identity
In the text

	Figure 2. Architecture of identity management
In the text

	Figure 3. Time comparison of identity identifier management
In the text

	Figure 4. Time comparison of single credential management
In the text

	Figure 5. Test of smart contract
In the text