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 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 ( in short) is regarded as a designated-verifier zero-knowledge proof system. Thus, we introduce the 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.
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 as [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-Efficiency. We construct a decentralized identity management system and describe each step of our scheme in detail. We use 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. 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
is engaged in anonymous authentication and identity management of private data and privacy protection blockchains. 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.
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., ) and the matrix using the lower letter and upper letter, respectively. In addition, let be a group of prime order with generator .
Decisional Diffie–Hellman (DDH) Assumption is that given a group of order , distribution , and 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 from .
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 and a complete SPHF are defined as follows:(i): takes a language as input and generates a hashing key .(ii): for a word , use and as inputs, and output the projective hashing key .(iii): the algorithm’s inputs are same as ; output a value .(iv): is a witness for that . This algorithm uses as inputs and outputs a value . The SPHF contains two properties, one is smoothness and another projective.(v)Projective(Correctness). For all and its witness , satify .(vi)Smoothness. For any and any parameters, the following distributions are statistically indistinguishable: , where is the set of hash values.
3.1. Pedersen Commitment
Let is a generator of the group , and we denote as the message. Randomly select a commitment parameter . The commitment scheme is proceeded as follows:(i) computes and outputs (ii)
Pedersen commitments contain two important properties, one is perfectly hiding: the commitment reveals nothing about the committed value . Another is computationally binding: an adversary of probabilistic polynomial time cannot find a value for such that .
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 , the detailed construction is as follows:(i): is the private key; is the public key. We select randomly, and let and .(ii): is a message, are random scalars, we use public key , , and as input and output a ciphertext .(iii): we use ciphertext and private key as input and output plaintext .
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 and a vector , which defines the Waters hash of a message as . Below, we review the construction of Waters signature:(i): is the private key used for signing, and is the public key used for public verification. where .(ii): we use a message , private key , and a random as inputs and generate a signature of .(iii): we use , message , and its signature as inputs. The verify algorithm will output a result that showed whether the signature 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 are considering to instantiate in a decentralized way. Below, as shown in Figure 1, we adopt the definition of discussed by Garman et al. [4] that contains seven PPT algorithms.
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 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. 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.
Figure 2 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 unique on the blockchain, which cannot be changed. A new client needs to register his identity information and his attribute to the blockchain. He generates a commitment for his identity information and sends to committee after signing by his secret key. The committee will first verify the validity of after receiving it. If the verification passes, the committee will generate credentials for the user’s attributions 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, the 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’ 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) takes as input the security parameter and then proceeds the following computations:(1), where are parameters of RSA, are primes such that for , and are random generators of a group (2)Output (ii) generates a main secret key for the user , while the is the only one that is bound to the user, and the detailed procedures are as follows:(1), where is randomly selected, and it will be used in the credential mint phase(2)Output (iii). The pseudonym (from the user to the origination ) is generated by who proceeds under the master secret key as follows:(1), picks up a randomness from , and sets (2) and computes for an organization (3)Output (iv) is executed by the user to generate a credential which is essential to a Pedersen commitment for his corresponding attributes , i.e., for its randomness and , along with a secret key for the user and a zero-knowledge proof(1), and it takes as input a selected random number and sets ; then, the user calculates(2), and the user proves that the commitment and the pseudonym contain the same master secret key and the attributes are in some allowed set(3)Output
After generating a credential of attributes, user submits with auxiliary data to blockchain.(i). This algorithm is run by nodes in the organization . The credential’s legality is accepted to the blockchain if and only if this algorithm returns 1.(1)(2)Output 1 if verification is successful, otherwise 0 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. This process is noninteractive and anonymous.(ii). In this phase, the user shows a proof to a verifier, where a verifier is either an organization or a third verifier.(1) and outputs , where (2) and outputs for a verifier (3), on inputs is executed by the user and computes where are a set of credentials fetched from the blockchain(4), on inputs ; then, the user computes a witness (5):(6)Outputs a proof
At first, the user should generate a new nym and its secret key for this verifier. Then, the user calculates a proof that(i)He knows a credential on the blockchain from organization (ii)The credential opens to the same pseudonym, and(iii)It has some attributes
At the end of this phase, the prover sends to verifier through his nym .(i). Upon receiving the proof from , the verifier executes the verify algorithm.(1), and verifier computes (2), and verify that is the aforementioned proof of knowledge on and 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 of -based anonymous credential that follows the solution of Blazy et al. [34]. In a nutshell, they adopt the(i) is performed by the credential issuer, and it takes as input the security parameter and then proceeds the following computations:(1), where are parameters of a bilinear map, (2), where are parameters of a bilinear map(3)Output (ii) generates key pair of Waters signature for the credential issuer while issuing secret and public key pair of linear encryption to the user, and the detailed procedures are as follows:(1), where (2), where (iii) is executed by the credential issuer to generate a cryptographic credential token that is essential to a signature of Waters by inputting attributes of the user under . In more detail, the credential issuer proceeds as follows:(1)Takes as input a selected random number and calculates where for a vector and an attribute set .(2)Outputs
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). 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 .(1)Prover proceeds as follows (a) , selects a randomness to blind the issued credential from the centralized credential issuer (a.k.a, certification authority), where , and outputs , i.e., (b) , selects two different random numbers , encrypts under , and outputs the ciphertext At the end of this phase, the prover sends to verifier(2)Upon receiving the ciphertext, the verifier proceeds as follows (a) and outputs the hashing key by picking up three randomnesses from (b) and outputs the projective hashing key (c) and outputs as ; particularly, (d) Chooses a random session key and a random challenge , and computes . Finally, the verifier sends to the prover.(3)Upon receiving , the prover proceeds as follows (a) and computes , where is a witness owned by user privately. Particularly, (b) Computes a session and a random challenge .
At the end of this phase, the prover sends to verifier.
Finally, the verifier returns 1 if 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.
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 and proceeds the following steps with SPHF over :(i)Define a vector (ii)A function for a vector , where is an attribute set (iii)A hash function
Then, the committee proceeds as follows:(1) generates global parameters for the whole system, where are two circle groups of order , is a generator of group , is a generator of group , and , (2)Process of key generation(i) and generate a keypair of ElGamal signature (), where and is a generator of group (ii), select a random generator , and generate a keypair of Waters signature (), where (iii) generate a keypair of ElGamal (), where and is a generator of group (3)The committee divides into shares , and the committee selects a polynomial of order : where is the number of members of committee, is publicly constructible Lagrange coefficient, and is the threshold value, .(4)Outputs , , , , and
Finally, 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 on the blockchain.(1)New Client generates his public key and private key locally and proceeds as follows: (a) , where , and is a random generator in group . The keypair is used to sign and encrypt message at the registration phase. (b) , where . The key pair will be used in the second phase. (c) and output a commitment parameter . (d) , call attribution extraction function , extract his attributes from his private information , and output . (e) and output a ciphertext by calculating , where . (f) , take inputs as commitment parameter , and output a commitment for ciphertext , where and are two random generator of group . (g) and output a ciphertext by calculate , where . (h) , sign for ciphertext , and output a signature by , where is a random generator of group and . Finally, the New Client sends to the committee. The request part is all done offline by the New Client.(2)After receiving the request from New Client, the Committee proceeds as follows: (a) and verify the validity of by at first. Calculate . Continue if the output is 1, otherwise return false to New Client. (b) and output by calculating . (c) , take as input a selected random number , and calculate and output . (d) Upload to bulletin board. This 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. 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) , select a randomness to blind the issued credential from the centralized credential issuer (a.k.a, certification authority), where , and output , i.e., (b) , select two different random numbers , encrypt under , and output the ciphertext At the end of this phase, the prover sends to SP.(2)Upon receiving the ciphertext, the SP proceeds as follows: (a) and output the hashing key by picking up three randomnesses from (b) and output the projective hashing key (c) and output as; particularly, Finally, the SP sends to the User.(3), and upon receiving , the User computes , where is a witness owned by user privately.
At the end of this phase, the User sends to SP.
Finally, the verifier returns 1 if 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)The Committee first performs the following actions: (a) , and when running the Audit() algorithm, the committee randomly selects on blockchain and the corresponding credentials committee had issued. (b) , and the committee generates a request message based on the relevant credentials. (c) , and generate a signature of the request message , and the committee calculates , where . After that, the Committee sends 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), and verify the validity of the audit request by computing . Then, the User sends his opening and to Committee.(3)Upon reception of opening and , the committee executes as follows: (a) , and the committee opens the user’s commitment which uploads to blockchain in the registration phase and computes ; return true if output 1; otherwise, return false to the user. (b) , and is a temporary private key related to , and it can only be used once for each user. The committee recovers temporary private key by calculate and then output . (c) , and the committee calculates (d) , and the committee verifies whether is generated by . 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), and all members of the committee decide the new number of members , the new threshold , and the new time of interval .(2), and each of them constructs a random polynomial of the form , where is a coefficient of polynomial . Then, they compute and send all other players , where .(3), and each of them updates their share by .
Theorem 1 (correct). DVAC is a scheme which satisfies soundness.
Proof. The soundness of Show Credential phase relies on the correctness of , , and .
Proof. The soundness of the Audit phase relies on the binding of Pedersen commitment and the correctness of Shamir’s Secret Sharing, , thus .
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 adversary against the semantic security of our scheme with advantage . We start from this initial security game. is consistent with the situation in a real attack.
. Let us emulate this security game:(1) emulates the initialization of the system: it runs , generates , and sends to adversary (2) simulates oracles of the transcripts of protocol:(i)Runs for a message and outputs (ii)Runs for a and outputs (iii)Runs and outputs (iv)Runs for an and outputs (3) generates two inputs and sends to (4) chooses a random bit and simulates the protocol for , and then, sends and to adversary (5) outputs a bit and sends to In this game, only plays the role of a challenger; in s perspective, he/she is still interacting with the real DVAC. We then modify the challenger to obtain Games and . In each game, denotes the random bit chosen by the challenger , while denotes the bit output by . Also, for j = 0, 1, and 2, we define to be the event win this game for . By definition, we have. In this game, the challenger is as , except a little modifications as follows:(i) uses a randomness such that . Adversary plays attack game against challenger of DDH and plays the role of challenger to as . When outputs , if , then outputs 1; else, outputs 0. So, we have . In this game, the challenger is as , except a little modifications as follows:(ii) chooses a random bit , sends to challenger of DL, and then obtains . Finally, sends to adversary .In more detail, adversary plays attack game against challenger of DL and plays the role of challenger to . When outputs , if , then outputs 1; else, outputs 0. Based on DL assumption, the adversary has only 1/2 probability win this game. So, we haveCombining 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 of [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 . 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 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. 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 . 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 (, ) 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 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.
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 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. The timing of the distribution of the secret keys is only related to the number of participants involved in the distribution.
(a)
(b)
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. 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 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.
(a)
(b)
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. 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.
(a)
(b)
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.
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.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by National Natural Science Foundation of China (61702294), Applied Basic Research Project of Qingdao City (17-1-1-10-jch).