Designated-Verifier Anonymous Credential for Identity Management in Decentralized Systems

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 achieve anonymity 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. *us, 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.


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. ey 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]. e transaction of virtual currency built on the chain can guarantee the privacy and security of both parties. e 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 as DAC [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 selfsovereign. 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. e 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. is 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-Efficiency SPHF. 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 Designed DAC. 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. e 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.

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.

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]. e 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. e 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. ere is still a risk of single points of failure.

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]. ese 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.

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 zeroknowledge 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.

Preliminaries
Below, we will outline the cryptographic building blocks that will be used in the following sections.
Notation. roughout 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 (g a , g b , g c |a, b, c⟵ $ Z q ), and (g a , g b , g ab |a, b⟵ $ Z 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, g a , g b , g c , e(g, g) abc ) from (g, g a , g b , g c , e(g, g) z ).
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][28][29]. For a NP language L, a word x ∈ L and a complete SPHF are defined as follows:

Pedersen Commitment.
Let h ∈ G is a generator of the group G, and we denote x ∈ G as the message. Randomly select a commitment parameter r ∈ G.
e commitment scheme is proceeded as follows: Pedersen commitments contain two important properties, one is perfectly hiding: the commitment c 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 � g x ′ h r . 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, G 1 , p, g, g 1 , e), the detailed construction is as follows: (i) (lsk, lpk) ⟵ LE.KGen(1 λ ): lsk is the private key; lpk is the public key. We select (x 1 , x 2 ) ⟵ Z p randomly, and let lsk � (x 1 , x 2 ) and lpk � ( .

Mobile Information Systems
(ii) c ⟵ LE.Enc(m; lpk): m ∈ G is a message, r � (r 1 , r 2 )← $ Z p are random scalars, we use public key lpk, m, and r 1 and r 2 as input and output a ciphertext c � (c 1 � Y r 1 2 , c 2 � Y r 2 2 , c 3 � g r 1 +r 2 · m). (iii) m ⟵ LE.Dec(c; lsk): we use ciphertext c and private key lsk as input and output plaintext m � c 3 /(c 2 ). 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 � message m, and its signature σ as inputs. e verify algorithm will output a result that showed whether the signature e(g, σ) � e(g z , h) · e(F(m), σ 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.

System Participants.
During our whole scheme, we separate five entities including user, committee, bulletin board (BB), service provider (SP), and auditor as illustrated in Figure 2 and optimized system model in distribution way in Figure 1.
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. e 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. Figure 2 illustrates an example of the model of our scheme. e 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 ① User send his information to committee. ② e 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. ④ e auditor requests the audit process by interacting with the committee. ⑤ e auditor interacts with the user to get the required information. ⑥ e auditor gets the information uploaded by the user at ① from the blockchain and returns the audit result. SPHF scheme guarantees zero-knowledge, and the blockchain could provide an environment which ensures anonymity. is 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: First of all, the dealer generates system parameters and a pair of keys for the committee. e 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. e committee can then perform the corresponding function (audit) only if the person who has reached this threshold agrees.

Registration.
In registration, the user will get his unique id 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. e 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.

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. e process of interaction is anonymous; each presentation of a credential is anonymized. e 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.

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. ere 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, the Refresh 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.

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. is 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.

reat 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. ere 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.

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.
Mobile Information Systems 5

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) param DAC ⟵ Setup(1 λ ) takes as input the security parameter λ and then proceeds the following computations: (1) param ACC ⟵ AccSetup(1 λ ), where param ACC � (N, u, p, q, g 0 , . . . , g n ) are parameters of RSA, p and q are primes such that p � 2 w q + 1 for w ≥ 1, and g 0 , . . . , g n are random generators of a group G (2) Output param DAC � param ACC (ii) msk ⟵ MskGen(param DAC ) 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 ⟵ Z q , where msk is randomly selected, and it will be used in the credential mint phase (2) Output msk is executed by the user U to generate a credential σ which is essential to a Pedersen commitment for his corresponding attributes att � (a 0 , a 1 , . . . , a m ) ∈ Z q , i.e., c � g for its randomness r ped ∈ Z q and msk, along with a secret key sk U for the user U and a zeroknowledge proof (1) c ⟵ Ped.Com(param, msk, att), and it takes as input a selected random number r ped ∈ Z q and sets sk U � r ped ; then, the user calculates (2) π U ⟵ ZK.Prove(msk, r msk , r ped , aux), and the user proves that the commitment c and the pseudonym nym U O contain the same master secret key msk and the attributes are in some allowed set After generating a credential of attributes, user submits (c, π U , att, nym U O ) with auxiliary data aux to blockchain.
. is algorithm is run by nodes in the organization O. e credential's legality is accepted to the blockchain if and only if this algorithm returns 1. ( If 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.
is process is noninteractive and anonymous.
(ii) π s ⟵ CredShow(msk, UV nym , mskUV nym , σ, sk U , C O ). In this phase, the user shows a proof to a verifier, where a verifier is either an organization O or a third verifier.

(6) Outputs a proof π s
At first, the user should generate a new nym UV nym and its secret key msk nym V U for this verifier. en, the user calculates a proof that (i) He knows a credential on the blockchain from organization O (ii) e credential opens to the same msk pseudonym, and (iii) It has some attributes At the end of this phase, the prover sends π s to verifier through his nym nym V U . (i) 0, 1 { } ⟵ ShowVerify(param DAC , nym V U , π s , C O ). Upon receiving the proof π s from UV nym , the verifier executes the verify algorithm. 6 Mobile Information Systems (1) A � Acc(param) ACC , C O , and verifier computes A � u c·c 1 ·c 2 ,...,c n (2) 0, 1 { } ⟵ ZK.Verify(param DAC , nym V U , π s , A, ), and verify that π s is the aforementioned proof of knowledge on (c, C O ) and nym V U using the known public values (3) Output 1 if verification is successful, otherwise 0

Review (Interactive) Anonymous Credential via SPHF.
Below, we recall the generic construction of SPHF-based anonymous credential that follows the solution of Blazy et al. [34]. In a nutshell, they adopt the (i) param BPV ⟵ BPV. Setup(1 λ ) is performed by the credential issuer, and it takes as input the security parameter λ and then proceeds the following computations: (1) param Waters  (1) (sk, vk) ⟵ Waters.KGen(param), where sk � h z and vk � g z , z ∈ Z p (2) (ek, dk) ⟵ LE.KGen(param), where ek � (ek 1 � g y 1 , ek 2 � g y 2 ) and dk � (y 1 , y 2 ), y 1 and y 2 ∈ Z p (iii) σ ⟵ CredMint(sk, M) is executed by the credential issuer to generate a cryptographic credential token that is essential to a signature of Waters σ ⟵ Waters.Sign(sk, 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 number s← $ Z * p and calculates where Remarkably, 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) CredShow(Prover(vk, ek, σ, M), Verifier(vk, M)).
is 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 r 1 and r 2 .
At the end of this phase, the prover sends r ′ to verifier. Finally, the verifier returns 1 if r ′ is valid, 0 otherwise.

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. Initialization phase is performed by Committee members, and at the end of this phase, all public parameters of DVAC are generated. e committee specifies a language L: WLin(wpk, lpk, M) and proceeds the following steps with SPHF over L: en, the committee proceeds as follows: (1) param DVAC ⟵ Setup(λ) generates global parameters param DVAC � (G, G t , g, g t , p, e) for the whole system, where G and G t are two circle groups of order p, g is a generator of group G, g t is a generator of group G t , and e: G × G ⟶ G t , g t � e(g, g) (2) Process of key generation where n is the number of members of committee, λ j is publicly constructible Lagrange coefficient, and t is the threshold value, t < n. to send a registration request to the committee. e committee runs an Authenticate(·) algorithm to issue credentials to a new client. e 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. KGen(1 λ ), where esk � x e , epk � g x e e , x e ← $ G, and g e is a random generator in group G. e keypair (esk, epk) is used to sign and encrypt message at the registration phase.
, and x 1 and e key pair (lsk, lpk) will be used in the second phase.
(d) attrs ⟵ f(info), call attribution extraction function f(·), extract his attributes attrs from his private information info, and output attrs.
(e) I ⟵ EG.Enc(info, vpk) and output a ciphertext I by calculating I � g (f ) C I ⟵ Ped.Com(I, ck), take inputs as commitment parameter ck, and output a commitment C I � g I c h ck c for ciphertext I, where g c and h c are two random generator of group G.
(g) m ⟵ EG.Enc(C I , attrs, id; upk) and output a ciphertext m by calculate m � (g r 2 m , upk r 2 · (C I ‖attrs‖id)), where r 2 ← $ G. . Continue if the output is 1, otherwise return false to New Client.
(d) Upload (id: C I , epk) to bulletin board. is information will not be changed forever. Finally, the Committee 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. is means that the SP can only provide the appropriate service based on the credentials, and it can learn no information from the user. is phase is shown in the second part of Figure 3. User runs Prove(·) algorithm and SP run Verify(·) algorithm.
(2) Upon receiving the ciphertext, the SP proceeds as follows:

Mobile Information Systems
x 3 ) ∈ Z 3 p by picking up three randomnesses x 1 , x 2 , and x 3 from Z p (b) hp ⟵ SPHF.ProjKG(param DVAC , L, hk, lpk) and output the projective hashing key hp � (hp 1 � lpk Hash(param DVAC , hk, (L, attrs), ct) and output v asc At the end of this phase, the User sends v ′ to SP. Finally, the verifier 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(·). is phase is shown in the third part of Figure 3.
(1) e Committee 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.Gen(attrs), and the committee generates a request message r based on the relevant credentials.
(c) s r ⟵ EGSign.Sign(r, usk), and generate a signature of the request message r, and the committee calculates s r � (g After that, the Committee sends (r, s r ) 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. e user's behavior in the future will be affected. If the user accepts, he/she will do the following: (2) (0, 1) ⟵ EGSign. Verify(r, s r , upk), and verify the validity of the audit request by computing  , σ), 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. is 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.
e DVAC is Semantically Secure if DDH holds for G, and the commitment scheme is perfectly hiding: Proof. We assume that an adversary A against the semantic security of our scheme with advantage ϵ. We start from this initial security game. G 0 is consistent with the situation in a real attack.
Game G 0 . Let us emulate this security game: (1) B emulates the initialization of the system: it runs EG.KGen(1 λ ), generates (vpk, upk), and sends (vpk, upk) to adversary A In this game, B 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 G 1 and G 2 . In each game, b denotes the random bit chosen by the challenger B, while b ′ denotes the bit output by A. Also, for j � 0, 1, and 2, we define W j to be the event A win this game Game G 1 . In this game, the challenger is as G 0 , except a little modifications as follows: (i) B uses a randomness c← $ G such that m � (g r 2 m , g c m · (C I ‖|attrs|‖id)). Adversary B plays attack game against challenger of DDH and plays the role of challenger to A as G 0 . When A outputs b ′ , if b � b ′ , then B outputs 1; else, outputs 0. So, we have Game G 2 . In this game, the challenger is as G 1 , except a little modifications as follows: (ii) B chooses a random bit b ∈ 0, 1 { }, sends to challenger of DL, and then obtains C b ′ . Finally, B sends C b ′ to adversary A.
In more detail, adversary B plays attack game against challenger of DL and plays the role of challenger to A. When A outputs b ′ , if b � b ′ , then B outputs 1; else, outputs 0. Based on DL assumption, the adversary A has only 1/2 probability win this game. So, we have Combining 2 and 3, yields 1, which completes the proof of the theorem.

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. is 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. is application extends the work of DAC [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 in DAC.
ere 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 of Committee 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. ese attributes could be age, address, or credibility. e Committee checks the user's information and issues a long-term credential (signature) on its sign private key wsk. is 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. en, he/she follows the WLin language interactive with SP. is 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. en, 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. e 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 Table 1, 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.

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.
e future work of DVAC is to provide a forwardsecure audit and noninteractive proof system.

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 Figure 4(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. e timing of the distribution of the secret keys is only related to the number of participants involved in the distribution. Figure 4 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. e 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 Figure 5(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.
To evaluate the time-consuming during the secret reconstruction phase, as shown in Figure 5(b) and Figure 6(a), we select the threshold as 4 and evaluate the 4 out of 7 setting. e 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. is is due to the multiple modular exponentiations. When the length of the secret key is longer, its time grows faster. is is the main disadvantage in realization.
As shown in Figure 6(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.

Conclusion
e 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 designatedverifier 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.

Mobile Information Systems 13
Data Availability e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.