# Designated-Verifier Anonymous Credential for Identity Management in Decentralized Systems

Authors: Xudong Deng; Chengliang Tian; Fei Chen; Hequn Xian
Journal: Mobile Information Systems
 (2021)

---

## Abstract

Most of the existing identity management is the centralized architecture that has to validate, certify, and manage identity in a centralized approach by trusted authorities. Decentralized identity is causing widespread public concern because it enables to give back control of identity to clients, and the client then has the ability to control when, where, and with whom they share their credentials. A decentralized solution atop on blockchain will bypass the centralized architecture and address the single point of the failure problem. To our knowledge, blockchain is an inherited pseudonym but it cannot achieveanonymity and auditability directly. In this paper, we approach the problem of decentralized identity management starting from the designated-verifier anonymous credential (DVAC in short). DVAC would assist to build a new practical decentralized identity management with anonymity and auditability. Apart from the advantages of the conventional anonymous credential, the main advantage of the proposed DVAC atop blockchain is that the issued cryptographic token will be divided into shares at the issue phase and will be combined at the showing credential phase. Further, the smooth projective hash function (SPHF in short) is regarded as a designated-verifier zero-knowledge proof system. Thus, we introduce the SPHF to achieve the designated verifiability without compromising the privacy of clients. Finally, the security of the proposed DVAC is proved along with theoretical and experimental evaluations.


---

## Body

## 1. Introduction

Identity management is viewed as a tool for the protection of user identification and account privacy security, government enterprise management, and public service demand, or the security and economic needs of operators and providers. Before, the ID card system is succinct for the government to manage people’s identity. With the rapid development of the Internet, a large number of identity management systems appear in our field of vision. They all have their merits for some special demand and also vulnerability for practice at the same time.Typically, a trusted party certificate authority (CA) is used to manage and store identities for users. As far back as the late twentieth century, “Passport” is a unified identity management project based on the NET platform implemented in [1]. “Passport” provides great convenience to users by allowing them to authenticate with only one site. However, as its system architecture is centralized and coordinated, the problem follows. In practice, single points of failure are coming through a trusted party. Such as the DigiNotar incident [2], CA was held hostage by hackers, in which Google’s certificate was published mistakenly. So, we need to effectively store a person’s identity information and ensure its privacy and effectiveness on the Internet where threats and vulnerabilities are ubiquitous. And, how to protect the privacy of individuals and ensure their identity is verified without giving away their privacy is an important issue.Bitcoin and blockchain had been proposed in 2008 [3]. The transaction of virtual currency built on the chain can guarantee the privacy and security of both parties. The natural decentralization and unchangeability of blockchain give us a new direction. With the rapid development of blockchain, there are more and more decentralized systems appearing based on blockchain. Furthermore, IBM and Samsung have been working on an idea called ADEPT that uses blockchain technology to form a decentralized network of IoT devices. Simply, it is feasible to construct a relatively secure identity management system with blockchain because some security features on blockchain fully meet the requirements of the identity management system.Recently, blockchain-based identity management has also had limited success, such asDAC [4] and DBLACR [5]. In these systems, users obtain information credentials from an authority (e.g., government) and upload their credentials to the blockchain. When an entity, such as a service provider, has requirements for its customers, users can prove those requirements for verification by the blockchain, which is used as a transparent infrastructure for authentication. Since we want to ensure the privacy of user information, we need to encrypt user information, but how to verify the encrypted information and verify it accurately and effectively is a problem (we certainly cannot provide authentication after decrypting user information, which violates the principle of privacy).In this paper, we propose DVAC, a decentralized anonymous credential system to protect the privacy of the clients. In particular, interaction in the system is completely anonymous and the registered identity information is self-sovereign. Instead of traditional CA for the whole system level, DVAC employs a decision-making institution committee; the committee consists of an indefinite number of members. The function of the committee is the same as that of a traditional CA, which issues credentials to users, except that it requires the approval of its members when making important decisions. This can be seen as effectively diminishes the power of CA and avoiding the problem of single points of failure. Moreover, DVAC supports the change of membership in the committee. On the contrary, conflicts are inevitable between service providers and users because of the anonymity of users in the anonymous credential system. We need a reasonable and fair audit to protect the interests of both parties in the conflict.To this end, we introduced proactive secret sharing. We use proactive secret sharing to distribute the private key of the committee to members, and no party in the committee can decide on its own. Moreover, proactive secret sharing can redistribute the secret key periodically according to the system conditions. In this way, members of the committee are prevented from being heavily bribed to ensure the correctness of the committee’s decision-making. When a conflict occurs, members of the committee negotiate whether to conduct an audit, but only if the number of supporting reaches a certain threshold.Contribution. Below, we conclude our main contribution along with the techniques’ roadmap as follows:(i)
A Neat Decentralized Anonymous Credential via Cost-EfficiencySPHF. We construct a decentralized identity management system and describe each step of our scheme in detail. We use SPHF to realize anonymous authentication of the system, and we add an audit function to our system. It points us to a new way of identity management.(ii)
A Privacy-Preserving DVAC Service via Our DesignedDAC. We design an application using our DVAC system for identity management.(iii)
A Simply Prototype of DVAC. We implement and evaluate our system and test its performance under different lengths of the secret key.Organization. The rest of the paper is organized as follows: Section 2 shows the related work of DVAC. Section 3 presents our hardness assumptions and cryptographic building blocks. Our system model and security model are presented in Section 4. We reviewed previous scenarios for anonymous credentials in Section 5. In Section 6, we describe each step of the construction of our solution in detail and we have proved the correctness and security of our scheme. In Section 7, we briefly introduce an application of our scheme. In Section 8, we evaluate the performance of DVAC. Finally, we conclude our work in Section 9.


## 2. Related Work

DVAC is engaged in anonymous authentication and identity management of private data and privacy protection blockchains. DVAC uses a zero-knowledge proof scheme and proactive secret sharing to create a new decentralized anonymous identity management system, which achieved fast and provable correct queries.


### 2.1. Anonymous Credential (over Blockchain)

In [6], a bilinear pair-based signature scheme was proposed, and based on the signature scheme, they constructed an efficient anonymous credential system. Au et al. proposed a constant-size anonymous authentication scheme [7], which use short group signature in [8]. The scheme can achieve multiple dynamic authentications, and the signature certificate length is constant, which makes the scheme have better efficiency. Additionally, Begum et al. [9] proposed another pairing-based anonymous credential system that also satisfies the constant size of the formula proof. In 2010, IBM proposed “Identity Mixer” [10], which can be used for anonymous authentication and the transfer of authentication attributes. It allows users to authenticate without collecting any other personal data. But the “Identity Mixer” has a defect, it does not provide identity tracking. In 2020, Li et al. [11] proposed a round-optimal asymmetric PAKE protocol, which could construct a new anonymous credential system. “DAC” [4] and “DBLACR” [5] are two decentralized anonymous credential systems based on blockchain. The anonymity of blockchain ensures that users’ private information will not be disclosed. However, there must have a trusted party to verify the reasonableness of the user’s identity information. There is still a risk of single points of failure.


### 2.2. Identity Management (over Blockchain)

“Liberty Alliance” proposed a three-way interaction protocol based on users, identity provider, and service provider [12]. It has improved the issue of leakage of users’ private information based on “Passport.” Subsequently, there comes out many identity management systems such as Tivoli Access Manager [13] and Central Authentication Service [14]. These systems provide a more secure privacy protection protocol. At the same time, these systems provide more complete basic functions and expand the application scope. But with the rapid popularization of electronic identity and the increasing demand of people, the centralized management scheme has become the most fundamental drawback [15]. CertCoin [16] was proposed by Conner Fromknecht et al. It constructs a distributed authentication system and maintains a common ledger for storing user IDs and public key information by using blockchain. After that, Blockstack decentralized PKI system [17] was proposed by Ali et al. Blockstack uses bitcoin’s working proof mechanism to maintain the system’s state consistency. In Coconut [18], Sonnino et al. proposed a new signature scheme based on Waters signature scheme, BGLS signature [19], and signature scheme of Pointcheval and Sanders [20]. Coconut enables general-purpose selective disclosure credentials to be efficiently used in settings with no natural single trusted third party to issue them. In addition, because of Shamir’s secret sharing [21], it will waste more time when adding and removing authorities. After Coconut, Nym credentials [22] were proposed by Halpin et al., namely, Nym credentials can be viewed as an improvement or extension of Coconut.


### 2.3. Public Distributed Ledger (atop Blockchain)

In ZkLedeger [23], Narula et al. proposed the first privacy-protected, verifiable audit distributed ledger system. All information about the transaction is uploaded to a public ledger and publicly verifiable. Unlike zk-SNARKs, Zkledger provides efficient and fast audits through noninteractive zero-knowledge proof and it does not require a trusted setup. Furthermore, ZkLedger provides much different auditing queries and real-time feedback to the auditor. In PrETP [24], Balasch et al. proposed a new way in privacy-protection ETP system. It can protect the user’s privacy to the greatest extent and provide the correct audit. PrETP resolves the conflict between the user’s right to privacy and the service provider’s right of interest. After PrETP, Meiklejohn et al. proposed Milo [25]. Milo solves the problem of privacy leakage in the audit process in PrETP and provides a new way in preventing drivers from ganging up to cheat.


## 2.1. Anonymous Credential (over Blockchain)

In [6], a bilinear pair-based signature scheme was proposed, and based on the signature scheme, they constructed an efficient anonymous credential system. Au et al. proposed a constant-size anonymous authentication scheme [7], which use short group signature in [8]. The scheme can achieve multiple dynamic authentications, and the signature certificate length is constant, which makes the scheme have better efficiency. Additionally, Begum et al. [9] proposed another pairing-based anonymous credential system that also satisfies the constant size of the formula proof. In 2010, IBM proposed “Identity Mixer” [10], which can be used for anonymous authentication and the transfer of authentication attributes. It allows users to authenticate without collecting any other personal data. But the “Identity Mixer” has a defect, it does not provide identity tracking. In 2020, Li et al. [11] proposed a round-optimal asymmetric PAKE protocol, which could construct a new anonymous credential system. “DAC” [4] and “DBLACR” [5] are two decentralized anonymous credential systems based on blockchain. The anonymity of blockchain ensures that users’ private information will not be disclosed. However, there must have a trusted party to verify the reasonableness of the user’s identity information. There is still a risk of single points of failure.


## 2.2. Identity Management (over Blockchain)

“Liberty Alliance” proposed a three-way interaction protocol based on users, identity provider, and service provider [12]. It has improved the issue of leakage of users’ private information based on “Passport.” Subsequently, there comes out many identity management systems such as Tivoli Access Manager [13] and Central Authentication Service [14]. These systems provide a more secure privacy protection protocol. At the same time, these systems provide more complete basic functions and expand the application scope. But with the rapid popularization of electronic identity and the increasing demand of people, the centralized management scheme has become the most fundamental drawback [15]. CertCoin [16] was proposed by Conner Fromknecht et al. It constructs a distributed authentication system and maintains a common ledger for storing user IDs and public key information by using blockchain. After that, Blockstack decentralized PKI system [17] was proposed by Ali et al. Blockstack uses bitcoin’s working proof mechanism to maintain the system’s state consistency. In Coconut [18], Sonnino et al. proposed a new signature scheme based on Waters signature scheme, BGLS signature [19], and signature scheme of Pointcheval and Sanders [20]. Coconut enables general-purpose selective disclosure credentials to be efficiently used in settings with no natural single trusted third party to issue them. In addition, because of Shamir’s secret sharing [21], it will waste more time when adding and removing authorities. After Coconut, Nym credentials [22] were proposed by Halpin et al., namely, Nym credentials can be viewed as an improvement or extension of Coconut.


## 2.3. Public Distributed Ledger (atop Blockchain)

In ZkLedeger [23], Narula et al. proposed the first privacy-protected, verifiable audit distributed ledger system. All information about the transaction is uploaded to a public ledger and publicly verifiable. Unlike zk-SNARKs, Zkledger provides efficient and fast audits through noninteractive zero-knowledge proof and it does not require a trusted setup. Furthermore, ZkLedger provides much different auditing queries and real-time feedback to the auditor. In PrETP [24], Balasch et al. proposed a new way in privacy-protection ETP system. It can protect the user’s privacy to the greatest extent and provide the correct audit. PrETP resolves the conflict between the user’s right to privacy and the service provider’s right of interest. After PrETP, Meiklejohn et al. proposed Milo [25]. Milo solves the problem of privacy leakage in the audit process in PrETP and provides a new way in preventing drivers from ganging up to cheat.


## 3. Preliminaries

Below, we will outline the cryptographic building blocks that will be used in the following sections.Notation. Throughout this paper, let λ be the security parameter; then, we denote the vector (i.e., a) and the matrix using the lower letter and upper letter, respectively. In addition, let G be a group of prime order p with generator g.Decisional Diffie–Hellman (DDH) Assumption is that given a group G=g of order q, distribution ga,gb,gc|a,b,c⟵$ℤq, and ga,gb,gab|a,b⟵$ℤq are indistinguishable for any polynomial time adversary.Decisional Bilinear Diffie–Hellman (DBDH) Assumption is that no polynomial time algorithm can achieve nonnegligible advantage in deciding the BDH problem; in other words, no adversary has the ability to distinguish the distribution g,ga,gb,gc,eg,gabc from g,ga,gb,gc,eg,gz.Smooth Projective Hash Function (SPHF) was proposed by Cramer and Shoup [26]. SPHF gives us a method to achieve zero-knowledge proof for the specified verifier [27–29]. For a NP language L, a word x∈L and a complete SPHF are defined as follows:(i)
hk⟵SPHF.HashKGL: takes a language L as input and generates a hashing key hk.(ii)
hp⟵SPHF.ProjKGhk,L,x: for a word x∈L, use hk and L as inputs, and output the projective hashing key hp.(iii)
H⟵SPHF.Hashhk,L,x: the algorithm’s inputs are same as SPHF.ProjKG; output a value H.(iv)
H′⟵SPHF.Projhp,L,x;w: w is a witness for that x∈L. This algorithm uses hp,L,x;w as inputs and outputs a value H′.The SPHF contains two properties, one issmoothness and another projective.(v)
Projective(Correctness). For all x∈L and its witness w, satify SPHF.Hashhk,L,x=SPHF.Projhp,L,x;w.(vi)
Smoothness. For any x∉L and any parameters, the following distributions are statistically indistinguishable:hp,H:hk⟵SPHF.HashKGL,hp⟵SPHF.ProjKGhk,L,x,H⟵SPHF.Hashhk,L,x, hp,H:hk⟵SPHF.HashKGL,hp⟵SPHF.ProjKGhk,L,x,H⟵$Θ,where Θ is the set of hash values.


### 3.1. Pedersen Commitment

Leth∈G is a generator of the group G, and we denote x∈G as the message. Randomly select a commitment parameter r∈G. The commitment scheme is proceeded as follows:(i)
c⟵Comx,r computes and outputs c=gxhr(ii)
0/1⟵Openc,x,rPedersen commitments contain two important properties, one is perfectly hiding: the commitmentc reveals nothing about the committed value x. Another is computationally binding: an adversary of probabilistic polynomial time cannot find a value x′ for r such that c=gx′hr.Linear Encryption (LE in short) is based on Decision Linear problem [8]. Below, we review the original scheme proposed by Boneh et al. [8]. For the public common parameters of LE scheme G,G1,p,g,g1,e, the detailed construction is as follows:(i)
lsk,lpk⟵LE.KGen1λ: lsk is the private key; lpk is the public key. We select x1,x2⟵ℤp randomly, and let lsk=x1,x2 and lpk=Y1=gx1,Y2=gx2.(ii)
c⟵LE.Encm;lpk: m∈G is a message, r=r1,r2←$Zp are random scalars, we use public key lpk, m, and r1andr2 as input and output a ciphertext c=c1=Y2r1,c2=Y2r2,c3=gr1+r2·m.(iii)
m⟵LE.Decc;lsk: we use ciphertext c and private key lsk as input and output plaintext m=c3/c1x1−1c2x2−1.Waters Signature is an efficient signature scheme with some optimizations and follow-up works [30, 31]. In our solution, we only use the original one to assist DVAC. We define a generator h←$G and a vector u=u1,u2,…,uk←$Gk+1, which defines the Waters hash of a message m=m1,m2,…,mk∈0,1k as Fm=u0∏i=1kuimi. Below, we review the construction of Waters signature:(i)
wsk,wpk⟵Waters.KGen1λ: wsk is the private key used for signing, and wpk is the public key used for public verification. wsk=hzand wpk=gz where z←$Zp.(ii)
σ⟵Waters.Signm;wsk: we use a message m, private key wsk, and a random s←$Zp as inputs and generate a signature σ=σ1=hz·Fms,σ2=gs of m.(iii)
0,1⟵Waters.Verifym,σ;wpk: we use wpk, message m, and its signature σ as inputs. The verify algorithm will output a result that showed whether the signature eg,σ=egz,h·eFm,σ2 is valid.Decentralized Anonymous Credential (DAC in short) inherits the properties of anonymous credential [32, 33] except distributing the cryptographic token into a couple of token shares. Most of state-of-art of DAC are considering to instantiate in a decentralized way. Below, as shown in Figure 1, we adopt the definition of DAC discussed by Garman et al. [4] that contains seven PPT algorithms.Figure 1
A brief illustration of DAC. ① user gets essential parameters of the system; ②③④ are executed offline by the user on the local side and finally uploads resulting values to the bulletin board; ⑤ the nodes of the organization verify the information from the bulletin board; ⑥ the user plays the role of a prover, and he sends proof of his credential with other auxiliary information to the verifier; ⑦ the verifier downloads the essential information from the bulletin board and validates the proof sent from the prover.


## 3.1. Pedersen Commitment

Leth∈G is a generator of the group G, and we denote x∈G as the message. Randomly select a commitment parameter r∈G. The commitment scheme is proceeded as follows:(i)
c⟵Comx,r computes and outputs c=gxhr(ii)
0/1⟵Openc,x,rPedersen commitments contain two important properties, one is perfectly hiding: the commitmentc reveals nothing about the committed value x. Another is computationally binding: an adversary of probabilistic polynomial time cannot find a value x′ for r such that c=gx′hr.Linear Encryption (LE in short) is based on Decision Linear problem [8]. Below, we review the original scheme proposed by Boneh et al. [8]. For the public common parameters of LE scheme G,G1,p,g,g1,e, the detailed construction is as follows:(i)
lsk,lpk⟵LE.KGen1λ: lsk is the private key; lpk is the public key. We select x1,x2⟵ℤp randomly, and let lsk=x1,x2 and lpk=Y1=gx1,Y2=gx2.(ii)
c⟵LE.Encm;lpk: m∈G is a message, r=r1,r2←$Zp are random scalars, we use public key lpk, m, and r1andr2 as input and output a ciphertext c=c1=Y2r1,c2=Y2r2,c3=gr1+r2·m.(iii)
m⟵LE.Decc;lsk: we use ciphertext c and private key lsk as input and output plaintext m=c3/c1x1−1c2x2−1.Waters Signature is an efficient signature scheme with some optimizations and follow-up works [30, 31]. In our solution, we only use the original one to assist DVAC. We define a generator h←$G and a vector u=u1,u2,…,uk←$Gk+1, which defines the Waters hash of a message m=m1,m2,…,mk∈0,1k as Fm=u0∏i=1kuimi. Below, we review the construction of Waters signature:(i)
wsk,wpk⟵Waters.KGen1λ: wsk is the private key used for signing, and wpk is the public key used for public verification. wsk=hzand wpk=gz where z←$Zp.(ii)
σ⟵Waters.Signm;wsk: we use a message m, private key wsk, and a random s←$Zp as inputs and generate a signature σ=σ1=hz·Fms,σ2=gs of m.(iii)
0,1⟵Waters.Verifym,σ;wpk: we use wpk, message m, and its signature σ as inputs. The verify algorithm will output a result that showed whether the signature eg,σ=egz,h·eFm,σ2 is valid.Decentralized Anonymous Credential (DAC in short) inherits the properties of anonymous credential [32, 33] except distributing the cryptographic token into a couple of token shares. Most of state-of-art of DAC are considering to instantiate in a decentralized way. Below, as shown in Figure 1, we adopt the definition of DAC discussed by Garman et al. [4] that contains seven PPT algorithms.Figure 1
A brief illustration of DAC. ① user gets essential parameters of the system; ②③④ are executed offline by the user on the local side and finally uploads resulting values to the bulletin board; ⑤ the nodes of the organization verify the information from the bulletin board; ⑥ the user plays the role of a prover, and he sends proof of his credential with other auxiliary information to the verifier; ⑦ the verifier downloads the essential information from the bulletin board and validates the proof sent from the prover.


## 4. System and Threat Models

### 4.1. DVAC System Model Overview

#### 4.1.1. System Participants

During our whole scheme, we separate five entities including user, committee, bulletin board (BB), service provider (SP), and auditor as illustrated in Figure2 and optimized system model in distribution way in Figure 1.Figure 2
System model of DVAC. ① User send his information to committee. ② The committee upload user’s information to blockchain and issue a credential to the user after verifying the information. ③ User shows his credential to the SP and acquires service. ④ The auditor requests the audit process by interacting with the committee. ⑤ The auditor interacts with the user to get the required information. ⑥ The auditor gets the information uploaded by the user at ① from the blockchain and returns the audit result.User is required to register their information on the bulletin board and get a credential from the committee.Committee is a group of members who can perform the same function as a certificate authority (CA) only under certain conditions.Bulletin board is a distributed ledger that can be instantiated by the blockchain. The data stored on the BB pseudonymously are public and unchangeable, but only the client who has the secret key could read the data.Service provider is an organization or government that provides concrete services to clients, and SP determines whether the client has the qualification to access his services.Auditor is an entity used to audit user information on the blockchain, which is typically acted by some of the members of the committee.Figure2 illustrates an example of the model of our scheme. The concept of this paper is that remove the single points of failure of CA and guarantee the privacy information of users during the certification process. We propose a decentralized self-sovereign credential management system. We use secret sharing, and blockchain provides the decentralized function and the immutability of data, and the SPHF scheme guarantees zero-knowledge, and the blockchain could provide an environment which ensures anonymity. This means the security of users’ private information is more strongly guaranteed when they obtain certifications. For simplicity, we have omitted the parameters of the entire system, and our approach proceeds as follows:


#### 4.1.2. Initialization

First of all, the dealer generates system parameters and a pair of keys for the committee. The committee’s public key is open for everyone and uses a secret share scheme to distribute the committee’s secret key for people in this group. Meanwhile, the committee should set a threshold value for recovering the secret key. The committee can then perform the corresponding function (audit) only if the person who has reached this threshold agrees.


#### 4.1.3. Registration

In registration, the user will get his uniqueid on the blockchain, which cannot be changed. A new client needs to register his identity information info and his attribute attr to the blockchain. He generates a commitment c for his identity information info and sends id,c,attr to committee after signing by his secret key. The committee will first verify the validity of id,c,attr after receiving it. If the verification passes, the committee will generate credentials for the user’s attributions attrs and upload the client’s cryptographic information and attributions to the bulletin board.


#### 4.1.4. Interactive Verification

After a client gets his credential, he is a legitimate user of the blockchain. He could interact with an SP or any other users as a prover. The process of interaction is anonymous; each presentation of a credential is anonymized. The prover proves that his identity info satisfies some requirement which comes from verifier through SPHF. Prover and verifier get the required parameters for proof and verification through an interaction. A verifier could verify the correctness of the user’s credentials.


#### 4.1.5. Secret Refresh

In our system, the group of the committee is not fixed and we should keep the number of members in a stable state. There must have members quit or join. For example, members of the committee may be bribed or some user wants to be a member of this committee. Although a few bribes do not affect the overall situation, the committee must regularly check and weed out those who have been bribed. So, we need to satisfy (1) security: let the sharing in the hands of the person weed out to be invalid, that is, he can no longer participate in the decision-making and his share cannot use to recover the secret key of the committee. (2) Fairness: provide regular rights of membership for new members.To ensure the security and fairness of the system, we must refresh the secret key held by the members of the committee. After the committee’s secret key had been shared, theRefresh algorithm will be recalled after some time (periodic testing by the committee) or some special change of participants. We will describe the details in Section 6.


#### 4.1.6. Audit

Consider that the user can provide attributes that he does not have to get the committee to sign or the member of the committee falsified. If an SP doubts the truth of a user’s credential, SP could apply an audit for the user’s identity. When the member in the committee who has reached the threshold agrees, the committee will generate an audit request for the client. This request will ask the user to open the commitment of his identity and compare it with the credential issued by the committee. If the user agreed, he should open the commitment of his information. At the end of the audit, the auditor returns a list of dishonest users and the committee will cancel these users’id on the blockchain. If he refused, the committee will adopt other means of restriction for him.


### 4.2. Threat Model

In DVAC, it is assumed that the members of the committee will be bribed. We assume that no more than a third of the members will be malicious in each period of a secret refresh. In terms of privacy, we need to protect against a malicious SP speculate the identity of a user in the course of interacting with the user, even if SPs arbitrarily collude. We assume that there are dishonest users who try to trick SP into providing services without the relevant credentials. In DVAC, auditing is only used as a solution for resolving conflicts when they occur. There must have been information leaked to the auditor by an audit process. Users’ privacy might be hard to protect if frequent audits are carried out.


### 4.3. System Goals

As an identity management system, DVAC should achieve the following goals:(i)
Completeness. A prover who shows his credentials correctly will surely pass the verification of the verifier.(ii)
Anonymity. Private information of each user can only be read by oneself. It means that a verifier does not know the prover’s other information except the validity of the credential.(iii)
Unforgeability. Prover can generate a valid verifier convinced proof if and only if it has a valid credential and the information contained in the certificate meets the security policy.(iv)
Unlinkability. In any two credential showing processes, or in the credential issuance process and credential showing process, an adversary verifier has only one negligible advantage linking them.(v)
Decentralized Auditability (D-Auditability). If there is a dispute between SP and user in the process of interaction between the two parties, third parties will intervene and audit. But third parties must reach a consensus (majority rule) to avoid a single point of failure on the part of the auditor.


## 4.1. DVAC System Model Overview

### 4.1.1. System Participants

During our whole scheme, we separate five entities including user, committee, bulletin board (BB), service provider (SP), and auditor as illustrated in Figure2 and optimized system model in distribution way in Figure 1.Figure 2
System model of DVAC. ① User send his information to committee. ② The committee upload user’s information to blockchain and issue a credential to the user after verifying the information. ③ User shows his credential to the SP and acquires service. ④ The auditor requests the audit process by interacting with the committee. ⑤ The auditor interacts with the user to get the required information. ⑥ The auditor gets the information uploaded by the user at ① from the blockchain and returns the audit result.User is required to register their information on the bulletin board and get a credential from the committee.Committee is a group of members who can perform the same function as a certificate authority (CA) only under certain conditions.Bulletin board is a distributed ledger that can be instantiated by the blockchain. The data stored on the BB pseudonymously are public and unchangeable, but only the client who has the secret key could read the data.Service provider is an organization or government that provides concrete services to clients, and SP determines whether the client has the qualification to access his services.Auditor is an entity used to audit user information on the blockchain, which is typically acted by some of the members of the committee.Figure2 illustrates an example of the model of our scheme. The concept of this paper is that remove the single points of failure of CA and guarantee the privacy information of users during the certification process. We propose a decentralized self-sovereign credential management system. We use secret sharing, and blockchain provides the decentralized function and the immutability of data, and the SPHF scheme guarantees zero-knowledge, and the blockchain could provide an environment which ensures anonymity. This means the security of users’ private information is more strongly guaranteed when they obtain certifications. For simplicity, we have omitted the parameters of the entire system, and our approach proceeds as follows:


### 4.1.2. Initialization

First of all, the dealer generates system parameters and a pair of keys for the committee. The committee’s public key is open for everyone and uses a secret share scheme to distribute the committee’s secret key for people in this group. Meanwhile, the committee should set a threshold value for recovering the secret key. The committee can then perform the corresponding function (audit) only if the person who has reached this threshold agrees.


### 4.1.3. Registration

In registration, the user will get his uniqueid on the blockchain, which cannot be changed. A new client needs to register his identity information info and his attribute attr to the blockchain. He generates a commitment c for his identity information info and sends id,c,attr to committee after signing by his secret key. The committee will first verify the validity of id,c,attr after receiving it. If the verification passes, the committee will generate credentials for the user’s attributions attrs and upload the client’s cryptographic information and attributions to the bulletin board.


### 4.1.4. Interactive Verification

After a client gets his credential, he is a legitimate user of the blockchain. He could interact with an SP or any other users as a prover. The process of interaction is anonymous; each presentation of a credential is anonymized. The prover proves that his identity info satisfies some requirement which comes from verifier through SPHF. Prover and verifier get the required parameters for proof and verification through an interaction. A verifier could verify the correctness of the user’s credentials.


### 4.1.5. Secret Refresh

In our system, the group of the committee is not fixed and we should keep the number of members in a stable state. There must have members quit or join. For example, members of the committee may be bribed or some user wants to be a member of this committee. Although a few bribes do not affect the overall situation, the committee must regularly check and weed out those who have been bribed. So, we need to satisfy (1) security: let the sharing in the hands of the person weed out to be invalid, that is, he can no longer participate in the decision-making and his share cannot use to recover the secret key of the committee. (2) Fairness: provide regular rights of membership for new members.To ensure the security and fairness of the system, we must refresh the secret key held by the members of the committee. After the committee’s secret key had been shared, theRefresh algorithm will be recalled after some time (periodic testing by the committee) or some special change of participants. We will describe the details in Section 6.


### 4.1.6. Audit

Consider that the user can provide attributes that he does not have to get the committee to sign or the member of the committee falsified. If an SP doubts the truth of a user’s credential, SP could apply an audit for the user’s identity. When the member in the committee who has reached the threshold agrees, the committee will generate an audit request for the client. This request will ask the user to open the commitment of his identity and compare it with the credential issued by the committee. If the user agreed, he should open the commitment of his information. At the end of the audit, the auditor returns a list of dishonest users and the committee will cancel these users’id on the blockchain. If he refused, the committee will adopt other means of restriction for him.


## 4.1.1. System Participants

During our whole scheme, we separate five entities including user, committee, bulletin board (BB), service provider (SP), and auditor as illustrated in Figure2 and optimized system model in distribution way in Figure 1.Figure 2
System model of DVAC. ① User send his information to committee. ② The committee upload user’s information to blockchain and issue a credential to the user after verifying the information. ③ User shows his credential to the SP and acquires service. ④ The auditor requests the audit process by interacting with the committee. ⑤ The auditor interacts with the user to get the required information. ⑥ The auditor gets the information uploaded by the user at ① from the blockchain and returns the audit result.User is required to register their information on the bulletin board and get a credential from the committee.Committee is a group of members who can perform the same function as a certificate authority (CA) only under certain conditions.Bulletin board is a distributed ledger that can be instantiated by the blockchain. The data stored on the BB pseudonymously are public and unchangeable, but only the client who has the secret key could read the data.Service provider is an organization or government that provides concrete services to clients, and SP determines whether the client has the qualification to access his services.Auditor is an entity used to audit user information on the blockchain, which is typically acted by some of the members of the committee.Figure2 illustrates an example of the model of our scheme. The concept of this paper is that remove the single points of failure of CA and guarantee the privacy information of users during the certification process. We propose a decentralized self-sovereign credential management system. We use secret sharing, and blockchain provides the decentralized function and the immutability of data, and the SPHF scheme guarantees zero-knowledge, and the blockchain could provide an environment which ensures anonymity. This means the security of users’ private information is more strongly guaranteed when they obtain certifications. For simplicity, we have omitted the parameters of the entire system, and our approach proceeds as follows:


## 4.1.2. Initialization

First of all, the dealer generates system parameters and a pair of keys for the committee. The committee’s public key is open for everyone and uses a secret share scheme to distribute the committee’s secret key for people in this group. Meanwhile, the committee should set a threshold value for recovering the secret key. The committee can then perform the corresponding function (audit) only if the person who has reached this threshold agrees.


## 4.1.3. Registration

In registration, the user will get his uniqueid on the blockchain, which cannot be changed. A new client needs to register his identity information info and his attribute attr to the blockchain. He generates a commitment c for his identity information info and sends id,c,attr to committee after signing by his secret key. The committee will first verify the validity of id,c,attr after receiving it. If the verification passes, the committee will generate credentials for the user’s attributions attrs and upload the client’s cryptographic information and attributions to the bulletin board.


## 4.1.4. Interactive Verification

After a client gets his credential, he is a legitimate user of the blockchain. He could interact with an SP or any other users as a prover. The process of interaction is anonymous; each presentation of a credential is anonymized. The prover proves that his identity info satisfies some requirement which comes from verifier through SPHF. Prover and verifier get the required parameters for proof and verification through an interaction. A verifier could verify the correctness of the user’s credentials.


## 4.1.5. Secret Refresh

In our system, the group of the committee is not fixed and we should keep the number of members in a stable state. There must have members quit or join. For example, members of the committee may be bribed or some user wants to be a member of this committee. Although a few bribes do not affect the overall situation, the committee must regularly check and weed out those who have been bribed. So, we need to satisfy (1) security: let the sharing in the hands of the person weed out to be invalid, that is, he can no longer participate in the decision-making and his share cannot use to recover the secret key of the committee. (2) Fairness: provide regular rights of membership for new members.To ensure the security and fairness of the system, we must refresh the secret key held by the members of the committee. After the committee’s secret key had been shared, theRefresh algorithm will be recalled after some time (periodic testing by the committee) or some special change of participants. We will describe the details in Section 6.


## 4.1.6. Audit

Consider that the user can provide attributes that he does not have to get the committee to sign or the member of the committee falsified. If an SP doubts the truth of a user’s credential, SP could apply an audit for the user’s identity. When the member in the committee who has reached the threshold agrees, the committee will generate an audit request for the client. This request will ask the user to open the commitment of his identity and compare it with the credential issued by the committee. If the user agreed, he should open the commitment of his information. At the end of the audit, the auditor returns a list of dishonest users and the committee will cancel these users’id on the blockchain. If he refused, the committee will adopt other means of restriction for him.


## 4.2. Threat Model

In DVAC, it is assumed that the members of the committee will be bribed. We assume that no more than a third of the members will be malicious in each period of a secret refresh. In terms of privacy, we need to protect against a malicious SP speculate the identity of a user in the course of interacting with the user, even if SPs arbitrarily collude. We assume that there are dishonest users who try to trick SP into providing services without the relevant credentials. In DVAC, auditing is only used as a solution for resolving conflicts when they occur. There must have been information leaked to the auditor by an audit process. Users’ privacy might be hard to protect if frequent audits are carried out.


## 4.3. System Goals

As an identity management system, DVAC should achieve the following goals:(i)
Completeness. A prover who shows his credentials correctly will surely pass the verification of the verifier.(ii)
Anonymity. Private information of each user can only be read by oneself. It means that a verifier does not know the prover’s other information except the validity of the credential.(iii)
Unforgeability. Prover can generate a valid verifier convinced proof if and only if it has a valid credential and the information contained in the certificate meets the security policy.(iv)
Unlinkability. In any two credential showing processes, or in the credential issuance process and credential showing process, an adversary verifier has only one negligible advantage linking them.(v)
Decentralized Auditability (D-Auditability). If there is a dispute between SP and user in the process of interaction between the two parties, third parties will intervene and audit. But third parties must reach a consensus (majority rule) to avoid a single point of failure on the part of the auditor.


## 5. Neat Decentralized Anonymous Credential from SPHF

### 5.1. Review Decentralized Anonymous Credential

Below, we recall the generic construction of decentralized anonymous credential (DAC) that follows the solution of Garman et al. [4]. In a nutshell, they adopt the following:(i)
paramDAC⟵Setup1λ takes as input the security parameter λ and then proceeds the following computations:(1)
paramACC⟵AccSetup1λ, where paramACC=N,u,p,q,g0,…,gn are parameters of RSA, pandq are primes such that p=2wq+1 for w≥1, and g0,…,gn are random generators of a group G(2)
OutputparamDAC=paramACC(ii)
msk⟵MskGenparamDAC generates a main secret key msk for the user U, while the msk is the only one that is bound to the user, and the detailed procedures are as follows:(1)
msk⟵Zq, where msk is randomly selected, and it will be used in the credential mint phase(2)
Outputmsk(iii)
nymUO,msknymUO⟵NymGenparamDAC,msk,U,O. The pseudonym nymUO (from the user U to the origination O) is generated by U who proceeds under the master secret key msk as follows:(1)
msknymUO⟵NymMskGen1λ, picks up a randomness rmsk from Zq, and sets msknymUO=rmsk(2)
nymUO⟵BuildNymparamDAC,msknymUO,msk and computes nymUO=g0rmskg1msk for an organization O(3)
OutputnymUO,msknymUO(iv)
σ,skU,πU⟵CredMintmsk,nymUO,msknymUO,att,aux is executed by the user U to generate a credential σ which is essential to a Pedersen commitment for his corresponding attributes att=a0,a1,…,am∈Zq, i.e., c¯=g0rpedg1msk∏i=0mgi+2ai for its randomness rped∈Zq and msk, along with a secret key skU for the user U and a zero-knowledge proof(1)
c¯⟵Ped.Comparam,msk,att, and it takes as input a selected random number rped∈Zq and sets skU=rped; then, the user calculates(1)σ≔c¯=g0rpedg1msk∏i=0mgi+2ai.(2)
πU⟵ZK.Provemsk,rmsk,rped,aux, and the user proves thatthe commitment c¯ and the pseudonym nymUO contain the same master secret key msk andthe attributes are in some allowed set(3)
Outputc¯,skU,πUAfter generating a credential of attributes, user submitsc¯,πU,att,nymUO with auxiliary data aux to blockchain.(i)
0,1⟵MintVerifyparamDAC,att,σ,nymUO,aux,πU. This algorithm is run by nodes in the organization O. The credential’s legality is accepted to the blockchain if and only if this algorithm returns 1.(1)
0,1⟵ZK.VerifyparamDAC,att,σ,nymUO,aux,πU(2)
Output 1 if verification is successful, otherwise 0If user’s credential through verification of organization’s nodes, he could show others a proof that he is a legal user and satisfy some attributes without revealing his credential. This process is noninteractive and anonymous.(ii)
πs⟵CredShowmsk,nymUV,msknymUV,σ,skU,CO. In this phase, the user shows a proof to a verifier, where a verifier is either an organization O or a third verifier.(1)
msknymUV⟵NymMskGen1λ and outputs msknymUV=rmsk′, where rmsk′∈Zq(2)
nymUV⟵BuildNymmsknymUV,msknymUV,msk and outputs nymUV=g0rmsk′g1msk for a verifier V(3)
A=AccparamACC,CO, on inputs paramN,u is executed by the user U and computes A=uc¯·c¯1·c¯2,⋯.c¯n where CO=c¯,c¯1,c¯2,…,c¯n are a set of credentials fetched from the blockchain(4)
w=WitGenparam,c,CO, on inputs paramN,u; then, the user computes a witness w=uc¯¯1·c¯2,…,c¯n(5)
πs⟵ZK.Provemsk,w,rmsk′,c¯,rped,nymUV:(2)AccVerparamACC,A,c¯,w=1∧c¯=g0rpedg1msk∏i=0mgi+2ai∧nymUV=g0rmsk′g1msk.(6)
Outputs a proofπsAt first, the user should generate a new nymnymUV and its secret key msknymUV for this verifier. Then, the user calculates a proof that(i)
He knows a credential on the blockchain from organizationO(ii)
The credential opens to the samemsk pseudonym, and(iii)
It has some attributesAt the end of this phase, the prover sendsπs to verifier through his nym nymUV.(i)
0,1⟵ShowVerifyparamDAC,nymUV,πs,CO. Upon receiving the proof πs from nymUV, the verifier executes the verify algorithm.(1)
A=AccparamACC,CO, and verifier computes A=uc¯·c¯1·c¯2,…,c¯n(2)
0,1⟵ZK.VerifyparamDAC,nymUV,πs,A,, and verify that πs is the aforementioned proof of knowledge on c¯,CO and nymUV using the known public values(3)
Output 1 if verification is successful, otherwise 0


### 5.2. Review (Interactive) Anonymous Credential via SPHF

Below, we recall the generic construction ofSPHF-based anonymous credential that follows the solution of Blazy et al. [34]. In a nutshell, they adopt the(i)
paramBPV⟵BPV.Setup1λ is performed by the credential issuer, and it takes as input the security parameter λ and then proceeds the following computations:(1)
paramWaters⟵Waters.Setup1λ, where paramWatersp,G,g,Gt,e are parameters of a bilinear map, h∈G(2)
paramLE⟵LE.Setup1λ, where p,G,g,Gt,e are parameters of a bilinear map(3)
OutputparamLZ=paramLE,paramWaters(ii)
ek,dk,sk,vk⟵LZ.KGenparamLZ generates key pair sk,vk of Waters signature for the credential issuer while issuing secret and public key pair ek,dk of linear encryption to the user, and the detailed procedures are as follows:(1)
sk,vk⟵Waters.KGenparam, where sk=hzand vk=gz,z∈Zp(2)
ek,dk⟵LE.KGenparam, where ek=ek1=gy1,ek2=gy2and dk=y1,y2,y1andy2∈Zp(iii)
σ⟵CredMintsk,M is executed by the credential issuer to generate a cryptographic credential token that is essential to a signature of Waters σ⟵Waters.Signsk,M by inputting attributes M of the user under sk. In more detail, the credential issuer proceeds as follows:(1)
Takes as input a selected random numbers←$Zp∗ and calculates(3)σ1=sk·FMsσ2=gs,whereFM=u0∏i=1kuimi for a vector u=u0,u1,…,uk∈Gk+1 and an attribute set M=m1,m2,…,mk∈0,1k.(2)
Outputsσ=σ1,σ2Remarkably, conventional DAC eliminates the centralized origination to issue the cryptographic credential token in a noninteractive approach; however, the simple AC should depend on a centralized part to issue the credential with an associated knowledge proof. Hence, compared with the syntax of DAC, in AC, there is no legal verification after issuing the credential by the origination.(i)
CredShowProvervk,ek,σ,M,Verifiervk,M. This algorithm is played by the prover and the verifier, and we regard the user as a prover for simplicity of illustration, where the witness of the prover is denoted as the randomness for the linear encryption r1andr2.(1)
Prover proceeds as follows(a) σ′⟵Blindσ, selects a randomness s′←$Zp to blind the issued credential σ from the centralized credential issuer (a.k.a, certification authority), where σ⟵Waters.SignsK,M=σ1=sk·FMs,σ2=gs, and outputs σ′=σ1′,σ2′, i.e.,(4)σ1′=σ1·FMs′,σ2′=σ2·gs′.(b) ct⟵LE.Encek,σ′, selects two different random numbers r1,r2←$Zp, encrypts σ′ under ek, and outputs the ciphertext ct=c1=ek1r1,c2=ek2r2,c3=gr1+r2·σ1′,σ2′At the end of this phase, the prover sendsct=c1=ek1r1,c2=ek2r2,c3=gr1+r2·σ1′,σ2′ to verifier(2)
Upon receiving the ciphertext, theverifier proceeds as follows(a) hk⟵SPHF.HashKGparam,L and outputs the hashing key hk=x1,x2,x3∈Zp3 by picking up three randomnesses x1,x2,andx3 from Zp(b) hp⟵SPHF.ProjKGparam,L,hk,ek and outputs the projective hashing key hp=hp1=ek1x1gx3,hp2=ek2x2gx3(c) v⟵SPHF.Hashparam,hk,L,M,ct and outputs v as c1x1c2x2c3/Mx3; particularly,(5)ec1,gx1ec2,gx2ec3,geh,vkeFM,σ2′x3.(d) Chooses a random session key K and a random challenge r∈0,1n, and computes Q=K⊕KDFvandW=K⊕r.Finally, theverifier sends hp,Q,W to the prover.(3)
Upon receivinghp,Q,W, the prover proceeds as follows(a) v′⟵SPHF.Projparam,hp,L,M,ct;w and computes v′=hp1r1hp2r2,\\g, where w=r1,r2 is a witness owned by user privately. Particularly,(6)ehp1r1hp2r2,g=eg,gy1r1x1+y2r2x2+r1+r2x3.(b) Computes a session K′=Q⊕KDFv′ and a random challenge r′=K′⊕W.At the end of this phase, theprover sends r′ to verifier.Finally, theverifier returns 1 if r′ is valid, 0 otherwise.


## 5.1. Review Decentralized Anonymous Credential

Below, we recall the generic construction of decentralized anonymous credential (DAC) that follows the solution of Garman et al. [4]. In a nutshell, they adopt the following:(i)
paramDAC⟵Setup1λ takes as input the security parameter λ and then proceeds the following computations:(1)
paramACC⟵AccSetup1λ, where paramACC=N,u,p,q,g0,…,gn are parameters of RSA, pandq are primes such that p=2wq+1 for w≥1, and g0,…,gn are random generators of a group G(2)
OutputparamDAC=paramACC(ii)
msk⟵MskGenparamDAC generates a main secret key msk for the user U, while the msk is the only one that is bound to the user, and the detailed procedures are as follows:(1)
msk⟵Zq, where msk is randomly selected, and it will be used in the credential mint phase(2)
Outputmsk(iii)
nymUO,msknymUO⟵NymGenparamDAC,msk,U,O. The pseudonym nymUO (from the user U to the origination O) is generated by U who proceeds under the master secret key msk as follows:(1)
msknymUO⟵NymMskGen1λ, picks up a randomness rmsk from Zq, and sets msknymUO=rmsk(2)
nymUO⟵BuildNymparamDAC,msknymUO,msk and computes nymUO=g0rmskg1msk for an organization O(3)
OutputnymUO,msknymUO(iv)
σ,skU,πU⟵CredMintmsk,nymUO,msknymUO,att,aux is executed by the user U to generate a credential σ which is essential to a Pedersen commitment for his corresponding attributes att=a0,a1,…,am∈Zq, i.e., c¯=g0rpedg1msk∏i=0mgi+2ai for its randomness rped∈Zq and msk, along with a secret key skU for the user U and a zero-knowledge proof(1)
c¯⟵Ped.Comparam,msk,att, and it takes as input a selected random number rped∈Zq and sets skU=rped; then, the user calculates(1)σ≔c¯=g0rpedg1msk∏i=0mgi+2ai.(2)
πU⟵ZK.Provemsk,rmsk,rped,aux, and the user proves thatthe commitment c¯ and the pseudonym nymUO contain the same master secret key msk andthe attributes are in some allowed set(3)
Outputc¯,skU,πUAfter generating a credential of attributes, user submitsc¯,πU,att,nymUO with auxiliary data aux to blockchain.(i)
0,1⟵MintVerifyparamDAC,att,σ,nymUO,aux,πU. This algorithm is run by nodes in the organization O. The credential’s legality is accepted to the blockchain if and only if this algorithm returns 1.(1)
0,1⟵ZK.VerifyparamDAC,att,σ,nymUO,aux,πU(2)
Output 1 if verification is successful, otherwise 0If user’s credential through verification of organization’s nodes, he could show others a proof that he is a legal user and satisfy some attributes without revealing his credential. This process is noninteractive and anonymous.(ii)
πs⟵CredShowmsk,nymUV,msknymUV,σ,skU,CO. In this phase, the user shows a proof to a verifier, where a verifier is either an organization O or a third verifier.(1)
msknymUV⟵NymMskGen1λ and outputs msknymUV=rmsk′, where rmsk′∈Zq(2)
nymUV⟵BuildNymmsknymUV,msknymUV,msk and outputs nymUV=g0rmsk′g1msk for a verifier V(3)
A=AccparamACC,CO, on inputs paramN,u is executed by the user U and computes A=uc¯·c¯1·c¯2,⋯.c¯n where CO=c¯,c¯1,c¯2,…,c¯n are a set of credentials fetched from the blockchain(4)
w=WitGenparam,c,CO, on inputs paramN,u; then, the user computes a witness w=uc¯¯1·c¯2,…,c¯n(5)
πs⟵ZK.Provemsk,w,rmsk′,c¯,rped,nymUV:(2)AccVerparamACC,A,c¯,w=1∧c¯=g0rpedg1msk∏i=0mgi+2ai∧nymUV=g0rmsk′g1msk.(6)
Outputs a proofπsAt first, the user should generate a new nymnymUV and its secret key msknymUV for this verifier. Then, the user calculates a proof that(i)
He knows a credential on the blockchain from organizationO(ii)
The credential opens to the samemsk pseudonym, and(iii)
It has some attributesAt the end of this phase, the prover sendsπs to verifier through his nym nymUV.(i)
0,1⟵ShowVerifyparamDAC,nymUV,πs,CO. Upon receiving the proof πs from nymUV, the verifier executes the verify algorithm.(1)
A=AccparamACC,CO, and verifier computes A=uc¯·c¯1·c¯2,…,c¯n(2)
0,1⟵ZK.VerifyparamDAC,nymUV,πs,A,, and verify that πs is the aforementioned proof of knowledge on c¯,CO and nymUV using the known public values(3)
Output 1 if verification is successful, otherwise 0


## 5.2. Review (Interactive) Anonymous Credential via SPHF

Below, we recall the generic construction ofSPHF-based anonymous credential that follows the solution of Blazy et al. [34]. In a nutshell, they adopt the(i)
paramBPV⟵BPV.Setup1λ is performed by the credential issuer, and it takes as input the security parameter λ and then proceeds the following computations:(1)
paramWaters⟵Waters.Setup1λ, where paramWatersp,G,g,Gt,e are parameters of a bilinear map, h∈G(2)
paramLE⟵LE.Setup1λ, where p,G,g,Gt,e are parameters of a bilinear map(3)
OutputparamLZ=paramLE,paramWaters(ii)
ek,dk,sk,vk⟵LZ.KGenparamLZ generates key pair sk,vk of Waters signature for the credential issuer while issuing secret and public key pair ek,dk of linear encryption to the user, and the detailed procedures are as follows:(1)
sk,vk⟵Waters.KGenparam, where sk=hzand vk=gz,z∈Zp(2)
ek,dk⟵LE.KGenparam, where ek=ek1=gy1,ek2=gy2and dk=y1,y2,y1andy2∈Zp(iii)
σ⟵CredMintsk,M is executed by the credential issuer to generate a cryptographic credential token that is essential to a signature of Waters σ⟵Waters.Signsk,M by inputting attributes M of the user under sk. In more detail, the credential issuer proceeds as follows:(1)
Takes as input a selected random numbers←$Zp∗ and calculates(3)σ1=sk·FMsσ2=gs,whereFM=u0∏i=1kuimi for a vector u=u0,u1,…,uk∈Gk+1 and an attribute set M=m1,m2,…,mk∈0,1k.(2)
Outputsσ=σ1,σ2Remarkably, conventional DAC eliminates the centralized origination to issue the cryptographic credential token in a noninteractive approach; however, the simple AC should depend on a centralized part to issue the credential with an associated knowledge proof. Hence, compared with the syntax of DAC, in AC, there is no legal verification after issuing the credential by the origination.(i)
CredShowProvervk,ek,σ,M,Verifiervk,M. This algorithm is played by the prover and the verifier, and we regard the user as a prover for simplicity of illustration, where the witness of the prover is denoted as the randomness for the linear encryption r1andr2.(1)
Prover proceeds as follows(a) σ′⟵Blindσ, selects a randomness s′←$Zp to blind the issued credential σ from the centralized credential issuer (a.k.a, certification authority), where σ⟵Waters.SignsK,M=σ1=sk·FMs,σ2=gs, and outputs σ′=σ1′,σ2′, i.e.,(4)σ1′=σ1·FMs′,σ2′=σ2·gs′.(b) ct⟵LE.Encek,σ′, selects two different random numbers r1,r2←$Zp, encrypts σ′ under ek, and outputs the ciphertext ct=c1=ek1r1,c2=ek2r2,c3=gr1+r2·σ1′,σ2′At the end of this phase, the prover sendsct=c1=ek1r1,c2=ek2r2,c3=gr1+r2·σ1′,σ2′ to verifier(2)
Upon receiving the ciphertext, theverifier proceeds as follows(a) hk⟵SPHF.HashKGparam,L and outputs the hashing key hk=x1,x2,x3∈Zp3 by picking up three randomnesses x1,x2,andx3 from Zp(b) hp⟵SPHF.ProjKGparam,L,hk,ek and outputs the projective hashing key hp=hp1=ek1x1gx3,hp2=ek2x2gx3(c) v⟵SPHF.Hashparam,hk,L,M,ct and outputs v as c1x1c2x2c3/Mx3; particularly,(5)ec1,gx1ec2,gx2ec3,geh,vkeFM,σ2′x3.(d) Chooses a random session key K and a random challenge r∈0,1n, and computes Q=K⊕KDFvandW=K⊕r.Finally, theverifier sends hp,Q,W to the prover.(3)
Upon receivinghp,Q,W, the prover proceeds as follows(a) v′⟵SPHF.Projparam,hp,L,M,ct;w and computes v′=hp1r1hp2r2,\\g, where w=r1,r2 is a witness owned by user privately. Particularly,(6)ehp1r1hp2r2,g=eg,gy1r1x1+y2r2x2+r1+r2x3.(b) Computes a session K′=Q⊕KDFv′ and a random challenge r′=K′⊕W.At the end of this phase, theprover sends r′ to verifier.Finally, theverifier returns 1 if r′ is valid, 0 otherwise.


## 6. Our Construction: Self-Sovereign Decentralized Anonymous Credential Management System

Below, we will specifically describe our solution that contains four phases, i.e., Initialization, Registration, Show Credential, and Audit, as illustrated in Figure 3.Figure 3
An illustration of DVAC.Initialization phase is performed by Committee members, and at the end of this phase, all public parameters of DVAC are generated. The committee specifies a language L:WLinwpk,lpk,M and proceeds the following steps with SPHF over L:(i)
Define a vectoru=u0,…,uk←$Gk+1(ii)
A functionFM=u0∏i=1kuimi for a vector u=u0,u1,…,uk∈Gk+1, where mi is an attribute set mi∈0,1k,i∈1,k(iii)
A hash functionH·Then, the committee proceeds as follows:(1)
paramDVAC⟵Setupλ generates global parameters paramDVAC=G,Gt,g,gt,p,e for the whole system, where GandGt are two circle groups of order p, g is a generator of group G, gt is a generator of group Gt, and e:G×G⟶Gt, gt=eg,g(2)
Process of key generation(i)
vsk,vpk⟵EGSign.KGen1λ and generate a keypair of ElGamal signature (vsk=xv,vpk=gvxv), where xv←$G and gv is a generator of group G(ii)
wsk,wpk⟵Waters.KGen1λ, select a random generator hw←$G, and generate a keypair of Waters signature (wsk=hwxw,wpk=gxw), where xw←$G(iii)
usk,upk⟵EG.KGen1λ generate a keypair of ElGamal (usk=xm,upk=gmxm), where xm←$G and gm is a generator of group G(3)
The committee dividesvsk into n shares s1,s2,…,sn⟵SS.Sharevsk, and the committee selects a polynomial pX of order n:(7)pX=xv+a1X+a2X2+⋯+at−1Xt−1∧p0=xv=λ1s1+λ2s2+⋯+λtst,wheren is the number of members of committee, λj is publicly constructible Lagrange coefficient, and t is the threshold value, t<n.(4)
OutputsparamDVAC, vsk,vpk, wsk,wpk, usk,upk, and s1,s2,…,snFinally,s1,s2,…,sn is distributed by the dealer to all members of committee randomly.(i)
Registration. A new client runs Request(·) algorithm to send a registration request to the committee. The committee runs an Authenticate(·) algorithm to issue credentials to a new client. The entire process we have illustrated by the first part of Figure 3. When a new client joins this system, he will get his unique id on the blockchain.(1)
New Client generates his public key and private key locally and proceeds as follows:(a) esk,epk⟵EG.KGen1λ, where esk=xe,epk=gexe,xe←$G, and ge is a random generator in group G. The keypair esk,epk is used to sign and encrypt message at the registration phase.(b) lsk,lpk⟵LE.KGen1λ, where lsk=lsk1=x1,lsk2=x2,lpk=lpk1=gx1,lpk2=gx2,andx1andx2←$G. The key pair lsk,lpk will be used in the second phase.(c) ck⟵Ped.KGen1λ and output a commitment parameter ck←$G.(d) attrs⟵finfo, call attribution extraction function f·, extract his attributes attrs from his private information info, and output attrs.(e) I⟵EG.Encinfo,vpk and output a ciphertext I by calculating I=gvr1,vpkr1·info, where r1←$G.(f) CI⟵Ped.ComI,ck, take inputs as commitment parameter ck, and output a commitment CI=gcIhcck for ciphertext I, where gc and hc are two random generator of group G.(g) m⟵EG.EncCI,attrs,id;upk and output a ciphertext m by calculate m=gmr2,upkr2·CIattrsid, where r2←$G.(h) sm⟵EGSign.Signm,esk, sign for ciphertext m, and output a signature sm=geke,ke−1Hm−xegeke by eski, where ge is a random generator of group G and ke←$G.Finally, theNew Client sends m,sm to the committee. The request part is all done offline by the New Client.(2)
After receiving the request fromNew Client, the Committee proceeds as follows:(a) 0,1⟵EGSign.Verifym,sm,epk and verify the validity of m by epk at first. Calculate geHm=?gexegekegekeke−1Hm−xegeke. Continue if the output is 1, otherwise return false to New Client.(b) CI,attrs,id⟵EG.Decm,usk and output CI,attrs,id by calculating CIattrsid=upkr2·CIattrsid·gmr2usk−1.(c) σ⟵Waters.Signattrs,wsk, take as input a selected random number rw←$G, and calculate and output σ=σ1=hwxw·Fattrsrw,σ2=grw.(d) Upload id:CI,epk to bulletin board. This information will not be changed forever.Finally, theCommittee returns σ to New Client.(ii)
Show Credential. After a new client gets his credentials from the committee, it means that he is a legal user of blockchain. When a user wants to obtain a service from SP, he needs to provide the corresponding credentials. And, this process is anonymous for SP. This means that the SP can only provide the appropriate service based on the credentials, and it can learn no information from the user. This phase is shown in the second part of Figure 3. User runs Prove(·) algorithm and SP run Verify(·) algorithm.(1)
User proceeds as follows:(a) σ′⟵Blindσ,s, select a randomness s←$Zp to blind the issued credential σ from the centralized credential issuer (a.k.a, certification authority), where σ⟵Water.Signwsk,attrs=σ1=wsk·Fattrsrw,σ2=grw, and output σ′=σ1′,σ2′, i.e., σ1′=σ1·FMs,σ2′=σ2·gs(b) ct⟵LE.Encσ′,lpk, select two different random numbers r1,r2←$Zp, encrypt σ′ under lpk, and output the ciphertext ct=c1=lpk1r1,c2=lpk2r2,c3=gr1+r2·σ1′,σ2′At the end of this phase, the prover sendsct=c1=lpk1r1,c2=lpk2r2,c3=gr1+r2·σ1′,σ2′ to SP.(2)
Upon receiving the ciphertext, the SP proceeds as follows:(a) hk⟵SPHF.HashKGparamDVAC,L and output the hashing key hk=x1,x2,x3∈Zp3 by picking up three randomnesses x1,x2,andx3 from Zp(b) hp⟵SPHF.ProjKGparamDVAC,L,hk,lpk and output the projective hashing key hp=hp1=lpk1x1gx3,hp2=lpk2x2gx3(c) v⟵SPHF.HashparamDVAC,hk,L,attrs,ct and output v asc1x1c2x2c3/attrsx3; particularly,(8)ec1,gx1ec2,gx2ec3,geh,wpkeFattrs,σ2′x3.Finally, the SP sendshp to the User.(3)
v′⟵SPHF.ProjparamDVAC,hp,L,M,ct;w, and upon receiving hp, the User computes v′=hp1r1hp2r2,g, where w=r1,r2 is a witness owned by user privately.At the end of this phase, the User sendsv′ to SP.Finally, theverifier returns 1 if r′ is valid, 0 otherwise.(i)
Audit. We denote the algorithm implemented by the committee and user, respectively, as Attest(·) and Audit(·). This phase is shown in the third part of Figure 3.(1)
TheCommittee first performs the following actions:(a) σ;id⟵Randomλ, and when running the Audit(·) algorithm, the committee randomly selects id on blockchain and the corresponding credentials committee had issued.(b) r⟵Audit.Request.Genattrs, and the committee generates a request message r based on the relevant credentials.(c) sr⟵EGSign.Signr,usk, and generate a signature of the request message r, and the committee calculates sr=gmkm,km−1Hr−xmgmkm, where km←$G.After that, theCommittee sends r,sr to User.When the user receives the committee’s audit request, the user should decide whether he is audited. If the user refuses, the committee will add a suspect tag to the blockchain. The user’s behavior in the future will be affected. If the user accepts, he/she will do the following:(2)
0,1⟵EGSign.Verifyr,sr,upk, and verify the validity of the audit request by computing gmHr=?gmxmgmkmgmkmkm−1Hr−xmgmkm.Then, theUser sends his opening ck and I to Committee.(3)
Upon reception of openingck and I, the committee executes as follows:(a) 0,1⟵Ped.OpenCI,ck,I, and the committee opens the user’s commitment which uploads to blockchain in the registration phase and computes gcIhcck=?CI; return true if output 1; otherwise, return false to the user.(b) vsk′⟵SS.Recsi,…,st, and vsk′ is a temporary private key related to vsk, and it can only be used once for each user. The committee recovers temporary private key by calculate vsk′=gvr1λ1s1,…,gvr1λtst and then output vsk′.(c) info⟵EG.DecI,vsk, and the committee calculates info=vpkr1·info·vsk′−1(d) 0,1⟵Auditinfo,σ, and the committee verifies whether σ is generated by info. If the audit fails, the committee will remove the user’s information on the blockchain; otherwise, return true.(ii)
Secret Refresh. This phase usually has a fixed amount of time to run within a period, unless something special happens to trigger it (such as a sudden occurrence). Same as the Audit phase, there must be approval by threshold members of the committee in the current period, and the Secret Refresh phase will be run.(1)
m,k,l⟵SS.RefSetupλ, and all members of the committee decide the new number of members m, the new threshold k, and the new time of interval l.(2)
ui,j⟵SS.RefComputen,m, and each of them constructs a random polynomial of the form δiz=δi,1z1+δi,2z2+⋯+δi,kzk−1, where δi,k is a coefficient of polynomial δiz. Then, they compute and send all other players ui,j=δij, where i∈0,nandj∈0,1,…,m.(3)
sil+1⟵SS.Recsi,u1,j,…,un,j, and each of them updates their share by sil+1=sil+u1,jl+⋯+un,jl.(9)DVACAdvAsem≤2·DDHAdvBDDH+2·DLAdvBDL.Theorem 1 (correct).
DVAC is a scheme which satisfies soundness.Proof.
The soundness ofShow Credential phase relies on the correctness of SPHF, SPHF.Hashhk,L,ct=SPHF.Projhp,L,ct;w, and v′=v.Proof.
The soundness of the Audit phase relies on the binding of Pedersen commitment and the correctness of Shamir’s Secret Sharing,gcIhcck=CI,vsk′==gvr1λ1s1,…,gvr1λtst, thus info=vpkr1·info·vsk′−1.Theorem 2 (semantically secure).
The DVAC is Semantically Secure if DDH holds for G, and the commitment scheme is perfectly hiding:Proof.
We assume that an adversaryA against the semantic security of our scheme with advantage ϵ. We start from this initial security game. G0 is consistent with the situation in a real attack.
GameG0. Let us emulate this security game:(1)
ℬ emulates the initialization of the system: it runs EG.KGen1λ, generates vpk,upk, and sends vpk,upk to adversary A(2)
ℬ simulates oracles of the transcripts of protocol:(i)
RunsEG.EncM,vpk for a message M and outputs I(ii)
RunsPed.ComI,ck for a I and outputs CI(iii)
Runs and outputsm(iv)
RunsEG.EncCI,attrs,id;upkEGSign.Signm,esk for an I and outputs sm(3)
A generates two inputs M0,M1 and sends to ℬ(4)
ℬ chooses a random bit b⟵0,1 and simulates the protocol for Mb, and then, ℬ sends m and sm to adversary A(5)
A outputs a bit b′ and sends b′ to ℬ
In this game,ℬ only plays the role of a challenger; in A′s perspective, he/she is still interacting with the real DVAC. We then modify the challenger to obtain Games G1 and G2. In each game, b denotes the random bit chosen by the challenger ℬ, while b′ denotes the bit output by A. Also, for j = 0, 1, and 2, we define Wj to be the event A win this game for b′=b. By definition, we have(10)DVACAdvAsem=PrW0−12.
GameG1. In this game, the challenger is as G0, except a little modifications as follows:(i)
ℬ uses a randomness γ←$G such that m=gmr2,gmγ·CIattrsid.Adversaryℬ plays attack game against challenger of DDH and plays the role of challenger to A as G0. When A outputs b′, if b=b′, then ℬ outputs 1; else, outputs 0. So, we have(11)DDHAdvBsem=PrW0−PrW1.GameG2. In this game, the challenger is as G1, except a little modifications as follows:(ii)
ℬ chooses a random bit b∈0,1, sends to challenger of DL, and then obtains Cb′. Finally, ℬ sends Cb′ to adversary A.
In more detail, adversaryℬ plays attack game against challenger of DL and plays the role of challenger to A. When A outputs b′, if b=b′, then ℬ outputs 1; else, outputs 0. Based on DL assumption, the adversary A has only 1/2 probability win this game. So, we have(12)DLAdvBsem=PrW1−1/2.
Combining 2 and 3, yields 1, which completes the proof of the theorem.


## 7. Self-Sovereign Decentralized Identity Management via DVAC

### 7.1. Application of Identity Management

In this section, we discuss several of the applications by DVAC. We consider the scenario where a user wants to register a long-term identity credential on the blockchain. This credential enables repeated presentation to any third parties several times without revealing extrainformation. A third party could verify the validity (whether it has the corresponding attributes) of credentials and provide related services for the user. All users on blockchain will be managed by the miner nodes which we called members of the committee. Miner nodes are not permanent, and each user could be a miner node. In addition to maintaining the system, these nodes are responsible for auditing users with a decentralized operation. This application extends the work ofDAC [4] which does not consider audit and the issuance of a decentralized credential.Our identity management system is based on blockchain and cryptocurrency. We use a public ledger to record the credentials of users with their other information, such as the bulletin board inDAC. There are three types of parties except for the public ledger: a group of credentials issuance and audit Committee, a set of SP, and a set of User.Before the system initializes, the first batch of members ofCommittee should be specified. As shown in Figure 3, the system parameters have been setup at the initialization phase. A user sends a registration request, a commitment of encrypted privacy information, and some information needed to prove his identity attributes to Committee. These attributes could be age, address, or credibility. The Committee checks the user’s information and issues a long-term credential (signature) on its sign private key wsk. This credential can be obtained only once and will not gonna change.When a user wants to get service from a SP, he/she needs to show his attribute that satisfies the request of the SP. He/she should show the corresponding credential (age, sex, or property) through a zero-knowledge proof for a specified verifier. To prevent SP replay attacks, he/she blinds this credential at first. Then, he/she follows the WLin language interactive with SP. This process could not reveal any other information except the user’s attributes.Committee could doubt attributes’ authenticity of users and combine with an audit algorithm to judge it periodically. At first, the Committee selects users on blockchain randomly. Then, the Committee sends an audit request to these users. It means that the right to accept the audit or not is in the hands of the users. If the user refuses, the Committee will mark him and his reputation will be impacted. If users accept, they send commitment openings (ck, I) to Committee. The Committee opens the commitment that is sent by the user in the registration phase. Finally, the Committee recovers the corresponding secret key and audits the privacy information of the user. If the result of the audit is right, return true; otherwise, the user will be removed from the blockchain and investigated relevant legal liabilities.In Table1, we compare our construction DVAC with other systems. Although DVAC has a slight deficiency in performance because of the secret sharing, it has a sufficient guarantee in security and privacy.Table 1
Comparison of the identity management system.
SchemePassport [1]CertCion [16]DAC[4]DBLACR [5]DVACUnlinkability✘✘✔✔✔Unforgability✘✘✔✔✔Anonymity✘✔✔✔✔D-Auditability✘✘✘✘✔


### 7.2. Future Work

DVAC’s focus is on adding audit capability to a decentralized identity management system and addressing the single point of failure that can occur during the audit process. However, it is still an interactive proof system between the user and the SP, which will incur unnecessary waiting time loss. If in an environment with high network latency, it is likely to cause network congestion. DVAC also does not support forward-secure for audit secret key. The future work of DVAC is to provide a forward-secure audit and noninteractive proof system.


## 7.1. Application of Identity Management

In this section, we discuss several of the applications by DVAC. We consider the scenario where a user wants to register a long-term identity credential on the blockchain. This credential enables repeated presentation to any third parties several times without revealing extrainformation. A third party could verify the validity (whether it has the corresponding attributes) of credentials and provide related services for the user. All users on blockchain will be managed by the miner nodes which we called members of the committee. Miner nodes are not permanent, and each user could be a miner node. In addition to maintaining the system, these nodes are responsible for auditing users with a decentralized operation. This application extends the work ofDAC [4] which does not consider audit and the issuance of a decentralized credential.Our identity management system is based on blockchain and cryptocurrency. We use a public ledger to record the credentials of users with their other information, such as the bulletin board inDAC. There are three types of parties except for the public ledger: a group of credentials issuance and audit Committee, a set of SP, and a set of User.Before the system initializes, the first batch of members ofCommittee should be specified. As shown in Figure 3, the system parameters have been setup at the initialization phase. A user sends a registration request, a commitment of encrypted privacy information, and some information needed to prove his identity attributes to Committee. These attributes could be age, address, or credibility. The Committee checks the user’s information and issues a long-term credential (signature) on its sign private key wsk. This credential can be obtained only once and will not gonna change.When a user wants to get service from a SP, he/she needs to show his attribute that satisfies the request of the SP. He/she should show the corresponding credential (age, sex, or property) through a zero-knowledge proof for a specified verifier. To prevent SP replay attacks, he/she blinds this credential at first. Then, he/she follows the WLin language interactive with SP. This process could not reveal any other information except the user’s attributes.Committee could doubt attributes’ authenticity of users and combine with an audit algorithm to judge it periodically. At first, the Committee selects users on blockchain randomly. Then, the Committee sends an audit request to these users. It means that the right to accept the audit or not is in the hands of the users. If the user refuses, the Committee will mark him and his reputation will be impacted. If users accept, they send commitment openings (ck, I) to Committee. The Committee opens the commitment that is sent by the user in the registration phase. Finally, the Committee recovers the corresponding secret key and audits the privacy information of the user. If the result of the audit is right, return true; otherwise, the user will be removed from the blockchain and investigated relevant legal liabilities.In Table1, we compare our construction DVAC with other systems. Although DVAC has a slight deficiency in performance because of the secret sharing, it has a sufficient guarantee in security and privacy.Table 1
Comparison of the identity management system.
SchemePassport [1]CertCion [16]DAC[4]DBLACR [5]DVACUnlinkability✘✘✔✔✔Unforgability✘✘✔✔✔Anonymity✘✔✔✔✔D-Auditability✘✘✘✘✔


## 7.2. Future Work

DVAC’s focus is on adding audit capability to a decentralized identity management system and addressing the single point of failure that can occur during the audit process. However, it is still an interactive proof system between the user and the SP, which will incur unnecessary waiting time loss. If in an environment with high network latency, it is likely to cause network congestion. DVAC also does not support forward-secure for audit secret key. The future work of DVAC is to provide a forward-secure audit and noninteractive proof system.


## 8. Evaluation

To evaluate DVAC, we implemented each step of DVAC with C++. Our essential environment is based on GMP and PCB library. We run microbenchmarks on a 4 core Intel machine with i7-8500T 2.1 GHz CPU and 8 GB of RAM, running 64-bit Windows 10. We measured the time-consuming of the key generation process, secret sharing process, and secret reconstruct process for secret keys of different bit lengths because the real interactive system is related to the speed of network transmission and is not stable. Let us assume that the network transfer does not take time and only measures the time consumption in the local calculation.As shown in Figure4(a), we compare the time-consuming of different key lengths. At the secret key distribution stage, there is no time consumption of secret keys of different lengths is no significant change. The timing of the distribution of the secret keys is only related to the number of participants involved in the distribution.Figure 4
(a) Time-consuming of secret distribution in different thresholds (left). (b) Time-consuming of secret reconstruction (right).
(a)(b)Figure4 rightly depicts the time required for the auditor to recover the user information for different thresholds and different secret key lengths during the audit phase. The values of the points are very close to each other when the secret key size is less than 1024 bits. Only when the secret key size is 1024 bit and 2048 bit, the time difference required by different threshold sizes are relatively significant changes.As shown in Figure5(a), we can find that, with the increase of the length of the secret key, the generation time of the secret key increases exponentially. However, this increase in time is not something we should care about because the entire initialization phase is done entirely offline.Figure 5
(a) Time-consuming of key generation (left). (b) Time-consuming of secret reconstruction by different methods (right).
(a)(b)To evaluate the time-consuming during the secret reconstruction phase, as shown in Figure5(b) and Figure 6(a), we select the threshold as 4 and evaluate the 4 out of 7 setting. The results imply that the time consumption in the audit stage is much greater than that in the secret key distribution stage when the length of the secret key is greater than 1024 bits. Further, comparing with traditional “reconstruction then decryption,” the approach of “reconstruction and decryption” is more time-consuming. This is due to the multiple modular exponentiations. When the length of the secret key is longer, its time grows faster. This is the main disadvantage in realization.Figure 6
(a) Time-consuming of secret distribution and secret reconstruction (left). (b) Time-consuming in Waters key-generation (W.KG), Waters signature (W.Sig), linear encryption key-generation (LE.KG), and entire interaction process of SPHF (right).
(a)(b)As shown in Figure6(b), we compare the time-consuming verification algorithms including key-generation and signature of Waters scheme, key-generation of linear encryption, and total verification of SPHF.


## 9. Conclusion

The existing anonymous credential identity management system usually exposes two shortcomings when it is implemented. One is that the correctness of identity information cannot be guaranteed when the privacy of the user’s identity information is guaranteed. Second, its centralized management will lead to a single point of the failure problem. In this paper, we propose DVAC, a designated-verifier anonymous credential in self-sovereign decentralized identity management. We added the audit function to solve the problem that the correctness of user identity information could not be guaranteed. We also solved the problem of single-point failure of the centralized management system to some extent through secret sharing and realized decentralized identity management. We provide the detailed step of the DVAC system and the cryptographic primitives underlying DVAC. We also implement and evaluate DVAC and application of identity management. DVAC provides a new way for designing an identity management system.



---

*Source: 2807395-2021-09-10.xml*