An Efficient Decentralized Identity Management System Based on Range Proof for Social Networks

Online social networks (OSNs) are becoming more and more popular in people's lives as the demand for online interaction continues to grow. Current OSNs are using centralized identity management system (IDM), which has some problems of single point of failure and privacy data leakage. The emergence of decentralized identity (DID) can solve these problems. However, most existing DID systems have some privacy issues that a user's attributes value are disclosed while accessing service. In this paper, we design a DID protocol to solve these challenges. The proposed protocol includes a range proof protocol to provide attribute privacy. The range proof protocol works with anonymous credentials and does not need a trusted setup. Moreover, the identity model behind the DID protocol is extended from an existing model, which achieves identity revocation. Finally, we implement a system prototype on the blockchain for evaluation. The security analysis shows that our protocol provides stronger privacy protection. The performance evaluation indicates that the computation cost and blockchain overheads of our protocol are acceptable in OSNs.

SECTION I. Introduction

The online social networks (OSNs) provide a new way for people to communicate and interact with others, which can cross geographical boundaries. A typical architecture of OSNs is shown in Fig. 1. Users need to register an account with social service providers, then they can interact with people who also have accounts with the same provider. The profile contains the user's identity information, and is stored on the service provider's server. In some OSNs, users are able to set access rules while others send a new friend request or want to access their sharing posts, and they can also build some groups based on the same attributes.

Figure 1.

The architecture of online social networks.

The traditional OSNs are using centralized identity management model, users need to register an identity on every service provider (SP), and store their identity information on the provider's server, which causes tremendous cost to users and personal data leakage [1] and [2]. This situation promotes the development of distributed OSNs (DOSNs) [3], which remove dependency on a centralized provider, and are usually implemented by a peer-to-peer (P2P) network. Although effectively protecting users' data, DOSNs also have some limitations. A major problem is the difficulty of identity management (IDM). In DOSNs, it is difficult to validate users' identities while all the information is managed by the user, thereby a fake identity can be easily forged by a malicious user.

Recently, a kind of IDM model which is user-centric appeared, and is named Self-Sovereign identity (SSI) [4]. The SSI is also known as the decentralized identity (DID), in which the identity data is in control of the user, who also has the right to decide which data to be shown while accessing service [5]. So the SSI is an appropriate IDM solution to the OSNs. The World Wide Web Consortium (W3C) designs Decentralized Identifiers [6] and verifiable credentials (VC) [7] to implement SSI. The W3C identity model is the most widely discussed identity model in SSI. However, while showing credentials to others, the user will expose the mapping of his identifier to the attribute in most existing DID systems, which compromises the user's identity privacy.

To address the privacy issues, some people suggested using anonymous credential [8]. With the anonymous credential technology, a user can show credentials to prove collegiality to others without revealing real identity. As a result, several decentralized anonymous credential protocols have been proposed (e.g., [9], [10]), which can be applied in DID systems. Nevertheless, attribute values are either exposed or fully hidden in these protocols, which limits the use of scenarios that the user may need to prove the satisfaction of the attributes (e.g., prove the age is over 18).

Range proof[11] can prove that some values in the credential are in a certain interval, such as age and income. Therefore the range proof is an effective method to hide attributes, and has been used to provide attribute privacy in [8]. The problem is that most range proofs are not practical enough to be applied in DID systems. Because some protocols need a trusted setup phase [12] and the others include linearly increasing public key operations with circuit size [13]. Therefore, we construct a range proof protocol to solve this.

A. Our Contributions

In this paper, we construct a Pointcheval and Sander's (PS) signature [14] based range proof protocol without a trusted setup. The protocol uses the randomizability of PS signature, making it possible to reuse signatures on the range with little overhead. Moreover, we extend the W3C identity model by introducing an identity named Account Provider (AP) to revoke users, which also make sure every user has a unique identity in the OSNs. Then, we combine these with blockchain to build our proposed system. We also develop a prototype of our proposal on the Ethereum [15] for simulation. Our paper's main contributions are summarized as follows:

• We propose a range proof protocol based on PS signature, and use it to build a identity management scheme for OSNs.

• We perform a security analysis of our proposed scheme. The result shows that our scheme can satisfy the security and privacy requirements in IDM systems.

• We implement our proposed system on the Ethereum and make the performance analysis on it. The results show that the gas cost and computation time for our system are acceptable.

B. Organization

The remaining of this article is structured as follows. In Section II, we review the related work of blockchain-based SSI identity management systems. In Section III, we introduce some preliminaries. The details of the proposed system model, as well as the design of the range proof protocol are presented in Section IV, and we analyze its security in Section V. Findings from the performance evaluation are shown in Section VI. Finally, Section VII concludes this paper.

SECTION II. Related Work

A. Traditional Identity Management in Social Networks

Most of the existing OSNs are based on centralized identity model, such as Facebook and Twitter. Users have an identity on each OSNs service providers, and need to handle a number of identities. The identity profile cannot be reused between different service providers. Federated identity model [16] appeared to solve this, which utilizes a OSNs service provider as an identity provider (IDP) to manage users' identity. The IDP can establish a trusted domain and provide a single sign-on service for users to access service from SPs in the trusted domain.

Security Assertion Markup Language (SAML) [17] is a protocol that can be used to build a federated IDM (FIDM) system. SAML protocol allows identity authentication between organizations where users are members of the IDP. Shibboleth [18] is a FIDM project based on SAML, which gives the IDP full control over the identity attribute. The SP can not access attributes without IDP's permission. The problem is that the SPs need to sign aggrements to join the federation and provide service, which limits the scope of user's identity.

OpenID Connect (OIDC) [19] is another way to achieve FIDM system, which is based on OAuth [20]. In OIDC, there is no need to build a trust relationship between the IDPs and the SPs. While accessing service from SP, users can select their preferred IDP and choose the attribute they want to disclose. Examples of this protocol are Facebook Connect and Google+ service. However, the protocol like OIDC only supports one IDP per authentication. In addition, as the user's authentication request will be redirected to the IDP, behavior privacy is exposed in the federated model.

B. SSI Using Blockchain

In industry, many SSI systems are built based on the blockchain technology. ShoCard [21] is one of them which digitizes user's paper-based credentials and publishes hash of credentials on Bitcoin [22]. So user's attributes hash is public and the ShoCard server has ability to track user's behavior.

Sovrin [23] choosed another way to implement SSI, which stores identity record on a permissioned blockchain named Hyperledger Indy¹. Users can get credentials from trusted nodes called stewards and selectively disclose the attributes they owned through zero-knowledge proofs. UPort [24] is another SSI system built in Ethereum [15] to solve this drawback, which utilises its smart contract to automatically manage users' identity.

In academia, people tried to solve some problems and improve the weakness of privacy in the SSI system. Maram et al. [25] proposed CanDID, which provides a method to recover users' private keys with their online accounts, and has ability to resist Sybil attacks. CanDID solves the problem in SSI that users may lose their keys, but does not have enough privacy support.

Yang et al. [26] designed BPDIMS to avoid exposure of attributes ownership using zero-knowledge proof and smart contracts, which enhanced privacy of its identity management system. The problem is that it's using zk-SNARK zero-knowledge proof system, thereby requiring a secret trusted setup, and may lead to breaking of its protocol while this step is not properly handled.

Kassem et al. [27] also proposed an IDM system with smart contract, their protocol allows user to securly manage personal data. Hamer et al. [28] constructed a protocol based on W3C identity model, and support cancelable biometrics. Their work achieves unlinkability of the user's identity. Borse et al. [29] designed a zero-knowledge proof protocol with Pedersen commitment, which can be used to protect user's attribute privacy.

Yu et al. [30] proposed BASS to provide selective revocation without non-transferability in the credential protocol, as they failed to bind the credential and user's identity properly, so the credential can be simply transferred to others without sharing the owner's private key. Sucasas et al. [31] proposed a anonymous credential protocol, which is based on pseudonym, and provides unlinkability while showing credentials to SPs. The protocol also support attribute privacy.

SECTION III. Preliminaries

In this section, we briefly review the related preliminaries and basic security assumptions used in this paper.

A. PS Signature

Pointcheval and Sanders' signature [14] is a signature scheme with a short signature size, and it consists of the following four algorithms:

• Setup: Given a security parameter $\lambda$, this algorithm generates public parameters $PP = (q, G_{1}, G_{2}, G_{T}, e, g_{1}, g_{2})$, where $(q, G_{1}, G_{2}, G_{T}, e)$ are type 3 bilinear group, $g_{1}$ and $g_{2}$ are generators of $G_{1}$ and $G_{2}$.

• Keygen: Given the public parameters $PP$, this algorithm randomly chooses $x,y \in \mathbb {Z}_{q}$ to compute $\widehat{X} = g_{2}^{x}, \widehat{Y} = g_{2}^{y}$. Then it outputs the keypair ($sk,pk$), where $sk = (x,y)$ and $pk = (g_{2}, \widehat{X}, \widehat{Y})$.

• Sign: Given the public parameters $PP$, a private key $sk$, and message $m$, this algorithm randomly chooses $u \in \mathbb {Z}_{q}$ and computes $A = g_{1}^{u}, B = A^{x+ym}$, then it returns $\sigma = (A,B)$ as the signature of $m$.

• Verify: Given the public parameters $PP$, a public key $pk$, a message $m$ and signature $\sigma$, this algorithm returns 1 if $e(A, \widehat{X}\widehat{Y}^{m}) = e(B, g_{2})$; otherwise, returns 0.

Moreover, PS signature has the property of randomizability, a PS signature $\sigma = (A,B)$ on a message $m$ can be randomized by randomly selecting $t \in \mathbb {Z}_{q}$ and getting a new signature $\sigma ^{\prime} = (A^{t},B^{t})$, which is also a valid signature to be verified by the same public key.

B. Zero-knowledge proof

Zero-knowledge proof [33] is a kind of proof protocol that have the following three properties:

1. Completeness: If the statement is true, the verifier accepts the result of the proof.

2. Soundness: A cheating prover is not able to create a false proof to fool the verifier into accepting it with a false statement.

3. Zero-knowledge: The verifier does not learn any information about the witness from the prover other than what is in the proof.

The $\Sigma$-protocol is a three-move zero-knowledge proof system, and is an interactive protocol that achieves honest-verifier zero-knowledge, which means it has the property of zero-knowledge while the verifier is honest. With the notion in [34], we let $ZKP\lbrace (\alpha):y = g^{\alpha }\rbrace$ denote a zero-knowledge proof of integer $\alpha$ that $y = g^{\alpha }$, where $y,g$ are elements of a group $G$. There are other relation instances can be proved, like $ZKP\lbrace (\alpha, \beta, \gamma): y = g_{1}^{\alpha }h_{1}^{\beta } \wedge t = g_{2}^{\alpha }g_{2}^{\gamma }\rbrace$. In addition, with the Fiat-Shamir heuristics [35], the above interactive protocols could be transformed to be noninteractive, and achieves zero-knowledge.

C. Accumulators

Accumulators [36] are used to accumulate a set $\Phi = \lbrace \phi _{1},..., \phi _{n}\rbrace$ into an accumulator $\Delta$, and a value so-called witness can be efficiently computed to prove the membership of element $\phi _{i}$. In addition, it can be made dynamic by supporting insertion and deletion of elements in the set dynamically. Here we introduced the pairing-based dynamic accumulators [37] [38], which has the constant size of witness. The accumulators work on type 3 bilinear group $(q, G_{1}, G_{2}, G_{T},e)$, let $g_{1}$ and $g_{2}$ to be generators of $G_{1}$ and $G_{2}$ respectively, and have $\tilde{g} \in G_{1}$. Set $Y_{1} = g_{1}^{y}, Y_{2} = g_{2}^{y}$ for $y \in \mathbb {Z}_{q}$.

Then for a set $\Phi = \lbrace \phi _{1},..., \phi _{n}\rbrace$, we can compute its accumulator as $\Delta = \tilde{g}^{ {\textstyle \prod _{i=1}^{n}(y+\phi _{i})} }$. To prove the membership of an element $\phi _{i}$, we need to compute a witness $Wit_{i} = \Delta ^{\frac{1}{y+\phi _{i}} }$, and the verification will be $e(\Delta, g_{2}) = e(Wit_{i}, Y_{2}g_{2}^{\phi _{i}})$.

The insertion and deletion of pairing-based dynamic accumulators need to update the witness. Here we use the method mentioned in [39] to delete a value $\phi _{t}$ from accumulator $\Delta$.

D. Identity Model

The identity model of our system is built by extending the W3C identity model with an additional entity named Account Provider (AP). The various components of our identity model are shown in Fig. 2.

Figure 2.

Our identity model.

There are four entities in our identity model, namely Account Provider, Identity Provider, Service Provider, and User. The details of these entities are described as follows:

• Account provider (AP): The AP hold accounts of the system, it generates public key and publishes the public parameters to blockchain. The user needs to get an account from it to join the system. AP updates the public params on blockchain to revoke a user.

• Identity provider (IDP): The IDP is an entity to issue and revoke credentials, it will check whether the user satisfies the attributes, and issue different type credentials depend on the privacy requirements.

• Service provider (SP): The SP is an entity to provides service for users. It can be a OSNs service provider or a server owned by a user in DOSNs. The access policy of a SP may need some attributes, it will verify the credentials provided by the user to check the requirements.

• User: The user has to register with the Account provider to get an account, using it to acquire credentials from the IDP, and access the service from SP by proving ownership of the required attributes.

The security goals of our identity model are defined as follows.

• Attribute Privacy: When showing credentials, other entities can only get the attributes disclosed by the user, and can not learn anything about the hidden attributes.

• Unforgeability: It's impossible for a user to publish a valid credential on the blockchain without the permission of IDP. Specifically, a user cannot forge a legal credential to be disguised as other users or prove the ownership of attributes he does not have.

• Soundness: A malicious user should not be able to show a credential if he does not own it.

• Unlinkability: While accessing service from SPs, it's hard to know what attributes the user actually have, which also means link two access service request is difficult.

• Behavior Privacy: The service that the user requests for cannot be learned by other entities.

SECTION IV. Our proposed protocols

In this section, we construct a set membership protocol based on the PS signature, which can be extended to construct range proofs. After that, we describe each phase of our identity management system, and explain how to apply the PS signature based range proof to the anonymous credentials used in the system.

A. PS-based Set Membership and Range Proofs

The starting point of this protocol is inspired by the construction in [40]. The main idea of it is that while generating the proof, the prover first requests a set of signatures from the verifier which are generated from every element in the set $\Phi$. Then the prover blinds the signature of the element it wants to commit (i.e., $\phi \in \Phi$) and generates a proof of knowledge to convince the verifier that it owns a signature on the committed element. Boneh-Boyen short (BBS) signature is used in [40] to build the original protocol.

However, the basic scheme with BBS signature is not suitable for anonymous credentials, for each attribute hidden in the range proof needs to compute a set of signatures and stored by the user. Thus we consider reusing the signatures already stored by users, for some credentials usually contain the same attributes user wants to hide (i.e., like the age). But the BBS signature in use may cause linkable of two credentials while showing these signatures to the verifier, the way to make BBS signature unlinkable is expensive [14], for a commitment is inevitable to make, and needs to be proved in a zero-knowledge way. As a result, we consider replacing it with PS signature, as shown in Section III-A, it can be easily randomized to achieve unlinkability, which perfectly satisfies our requirements. The details of our proposed set membership protocol (as shown in Fig. 3) are described as follows.

• Setup: Given a security parameter $\lambda$, this algorithm generates the public parameters $PP = \lbrace q, G_{1},G_{2},G_{T},e, g_{1},g_{2}, g,h, \Phi \rbrace $, where q is a large prime numbers of $\lambda$ bits length, $(G, G_{1},G_{2},G_{T})$ are cyclic groups generated with order q. The $e:G_{1}\times G_{2}\to G_{T}$ is a bilinear map. $g_{1}$ and $g_{2}$ are generators of $G_{1}$ and $G_{2}$, and $\Phi$ is a set.

• Initialize: The verifier needs to generate signatures for all elements in set $\Phi$. It randomly chooses $x, y\in \mathbb {Z}_{q}$ as its signing key and computes $\widehat{X} = g_{2}^{x},\widehat{Y} = g_{2}^{y}$ as the corresponding public key. For any $i \in \Phi$, the verifier randomly chooses $u\in \mathbb {Z}_{q}$, and computes $A_{i} = g_{1}^{u}, B_{i} = A_{i}^{x+yi}$. Then it sends $\widehat{X}, \widehat{Y}, A_{i}, B_{i} \forall i \in \Phi$ to the prover.

• Excute: This step is executed by the prover and verifier to prove the following zero knowledge proof \begin{align*} ZKP \lbrace (\phi, r, s) :&\left.C = g^{\phi }h^{r}\right.\\ &\left.\wedge \frac{e(\widehat{B_{\phi }}, g_{2}) }{e(\widehat{A_{\phi }},\widehat{X}) }= e(\widehat{A_{\phi }},\widehat{Y})^{\phi }e(\widehat{A_{\phi }},g_{2})^{s}\rbrace \right. \end{align*}

Figure 3.

The design of our PS-based set membership protocol.

1. The prover randomly chooses $r, \rho _{1},\rho _{2},\rho _{3} \in \mathbb {Z}_{q}$, and computes $C = g^{\phi }h^{r}, D = g_{1}^{\rho _{1}}g_{2}^{\rho _{2}},E=e(\widehat{A_{\phi }},\widehat{Y})^{\rho _{1}}e(\widehat{A_{\phi }},g_{2})^{\rho _{3}}$, where $\phi \in \Phi$ is the secret value that prover holds. It also randomly chooses $s,t\in \mathbb {Z}_{q}$, and computes $\widehat{A_{\phi }} = A_{\phi }^{t},\widehat{B_{\phi }} = (B_{\phi }A_{\phi }^{s})^{t}$. Then it sends $D,E,\widehat{A_{\phi }},\widehat{B_{\phi }}$ to the verifier.

2. The verifier chooses a random value $c \in \mathbb {Z}_{q}$ as challenge and sends $c$ to the prover.

3. The prover computes $s_{1} = \rho _{1}-c\phi, s_{2} = \rho _{2}-cr,s_{3} = \rho _{3}-cs$, and sends $s_{1},s_{2},s_{3}$ to the verifier.

4. The verifier checks if the equations: $\begin{array}{l}D=g_{1}^{s_{1}} g_{2}^{s_{2}} C^{c}, \\ E=e(\widehat{A_{\phi }}, \hat{Y})^{s_{1}} e(\widehat{A_{\phi }}, g_{2})^{s_{3}}\left(\frac{e(\widehat{B_{\phi }}, g_{2})}{e(\widehat{A_{\phi }}, \hat{X})}\right)^{c} \end{array}$ hold or not.If yes, the verifier accepts the proof.

Theorem 1:

If the adopted PS signature is existential unforgeability under chosen message attack (EUF-CMA), the proposed set membership for a set $\Phi$ is a zero-knowledge argument with completeness, soundness and zero-knowledgeness.

Proof: The provement of our proposed set membership protocol is as follows.

Completeness: The completeness achieves by checking the equations

\begin{align*} D &=g^{s_{1}} h^{s_{2}}C^{c}\\ &=g^{(\rho _{1}-c\phi)}h^{(\rho _{2}-cr)}(g^{\phi }h^{r})^{c}\\ &=g^{\rho _{1}}h^{\rho _{2}}=D\\ E &=e(\widehat{A_{\phi }}, \hat{Y})^{s_{1}} e(\widehat{A_{\phi }}, g_{2})^{s_{3}}\left(\frac{e(\widehat{B_{\phi }}, g_{2})}{e(\widehat{A_{\phi }}, \hat{X})}\right)^{c}\\ &=e(\widehat{A_{\phi }}, \hat{Y})^{\rho _{1}-c\phi } e(\widehat{A_{\phi }}, g_{2})^{\rho _{3}-cs}\left(\frac{e(\widehat{B_{\phi }}, g_{2})}{e(\widehat{A_{\phi }}, \hat{X})}\right)^{c}\\ &=e(A_{\phi }^{t}, \hat{Y})^{\rho _{1}-c\phi } e(A_{\phi }^{t}, g_{2})^{\rho _{3}-cs}\left(\frac{e(B_{\phi }^{t}A_{\phi }^{st}, g_{2})}{e(A_{\phi }^{t}, \hat{X})}\right)^{c}\\ &=e(A_{\phi }^{t}, \hat{Y})^{\rho _{1}-c\phi } e(A_{\phi }^{t}, g_{2})^{\rho _{3}-cs}\\ &\frac{e(A_{\phi }^{cst}, g_{2})e(B_{\phi }^{ct},g_{2})}{e(A_{\phi }^{ct}, \hat{X})}\\ &=e(A_{\phi }^{t}, \hat{Y})^{\rho _{1}-c\phi } e(A_{\phi }^{t}, g_{2})^{\rho _{3}-cs}e(A_{\phi }^{cst}, g_{2})\\ &e(A_{\phi }^{ct},\hat{X}\hat{Y}^{\phi })e(A_{\phi }^{-ct}, \hat{X})\\ &=e(\widehat{A_{\phi }},\widehat{Y})^{\rho _{1}}e(\widehat{A_{\phi }},g_{2})^{\rho _{3}}=E \end{align*}

Soundness: The soundness can be proved with the extraction property of the proof of knowledge. It means that if any prover $P^{*}$, could convince verifier $V$ with probability $\epsilon$, then there exits an extractor that can output a witness ($\phi, r, s$) with probability $ O(\epsilon)$ by interacting with $P^{}*$. In addition, we can assume that the input of the extractor consists two arguments like $\lbrace \hat{X},\hat{Y}, (A_{i}, B_{i}), (\widehat{A_{\phi }},\widehat{B_{\phi }}), D, E, c, c^{\prime},s_{1}, s_{1}^{\prime}, s_{2}, s_{2}^{\prime},s_{3}, s_{3}^{\prime}\rbrace$, then the witness can be extracted by computing: $v = (c^{\prime}-c)^{-1}, \phi = (s_{1}-s_{1}^{\prime})\cdot v, r= (s_{2}-s_{2}^{\prime})\cdot v, s = (s_{3}-s_{3}^{\prime})\cdot v$.

When $(c^{\prime}-c)$ is invertible in $\mathbb {Z}_{q}$, the extractor can successfully output the witness. If $\phi \notin \Phi$, then $P^{*}$ can be (almost) directly used to successfully execute an adaptively chosen message attack against PS signature with probability $O(\epsilon)$. Therefore, the $\epsilon$ must be negligible.

Honest-verifier zero-knowledge: To prove this property, we need to construct a simulator $Sim$ to simulate all interactions with verifier $V^{*}$(see Fig. 5).

Figure 4.

System architecture.

Figure 5.

Simulator for the PS-based set membership protocol.

Since the protocol has random $s, t \in \mathbb {Z}_{q}$, so the first two steps achieve perfect blinding.Which means no one except $P^{*}$ can recover $(A_{\phi }, B_{\phi })$ from the $(\widehat{A_{\phi }}, \widehat{B_{\phi }})$. In addition, benefits from the zero-knowledge property of the $\Sigma$-protocol (steps 3 to 5), the witness will not be leaked. Thus our set membership protocol achieves zero-knowledge property.

Range Proofs: It is obvious that our set membership protocol can be directly extended to build range proofs by signing each element in the range, but it's not efficient and costs large amounts of signatures. As a result, we choose to use the method introduced in [40]. More detaily, For a range $[0, u^{l})$ (where $u,l \in \mathbb {N}$), we first write the committed value $\phi$ in u-ary notation (i.e., $\phi = {\textstyle \sum _{j=0}^{l-1}\phi _{j}\cdot u^{j}}$), then we can prove $\phi \in [0, u^{l})$ by proving each $\phi _{j}$ in $\Phi$ on the set $[0, u-1]$ using our set membership protocol. Specifically, the most communication is costed by the first verifier message, and the signatures for each $\phi _{j}$ can be reused to reduce the cose. In addition, the above range proof protocol can be adopted to arbitrary range $[a, b]$, the work [40] give a detailed explanation of how to make it, interested readers could refer to it for more details.

B. Our constructed DID protocol

With the above proposed range proofs, we can design a DID protocol on a blockchain system (e.g., Ethereum). The identity model of our DID protocol is described in Section III-D. The system architecture of our proposed DID protocol is shown in Fig. 4. In our construction, four smart contract are developed to build the system, including Entity Register Contract (ERC), Credential Manage Contract (CMC), Account Manage Contract (AMC), and Attribute Set Contract (ASC).

Our proposed scheme consists of ten phases: Setup, Keygen, RegisterAccount, RequestCred, IssueCred, Show, Verify, RevokeCred, RecoverCred, RevokeUser.

• Setup: Given a security parameter $\lambda$, this algorithm generates the public parameters $PP = \lbrace q, G_{1},G_{2},G_{T},e, g_{1},g_{2}, g,h, \lbrace h_{1},..., h_{k}\rbrace \rbrace $, where q is a large prime numbers of $\lambda$ bits length, $(G, G_{1},G_{2},G_{T})$ are cyclic groups generated with order q. The $e:G_{1}\times G_{2}\to G_{T}$ is a bilinear map. $g_{1}$ and $g_{2}$ are generators of $G_{1}$ and $G_{2}$, $\lbrace g, h, h_{1},..., h_{k}\rbrace$ are generators of $G$, where k denotes the number of attributes.

• Keygen:

1. AP Keygen: Given the public prarmeters $PP$, this algorithm randomly chooses $\tilde{g} \in G_{1}$ and $d, w_{1},w_{2},...,w_{n} \in \mathbb {Z}_{q}$ to compute $Y_{AP} = g_{2}^{d}$ and the accumulator $\Delta =\tilde{g} ^{(d + w_{1})\cdot \cdot \cdot (d + w_{n})}$, where n denotes the number of users. The $sk_{AP} = d, pk_{AP} = Y_{AP}$. An empty User revocation list $URL=\emptyset$ is also generated to set AP parameters $param_{AP} = \lbrace \tilde{g}, Y_{AP},\Delta, URL \rbrace $ and the AP calls AMC.paramsInit($param_{AP}$) to put $param_{AP}$ on blockchain.

2. IDP Keygen: Given the public prarmeters $PP$, this algorithm randomly chooses $x, y\in \mathbb {Z}_{q}$, computes $\widehat{X} = g_{2}^{x},\widehat{Y} = g_{2}^{y}$. Then the IDP get $sk_{IDP}= (x, y), pk_{IDP}= (\widehat{X},\widehat{Y})$, and calls ERC.entityRegister($pk_{IDP}$) to put the public key on blockchain.

• RegisterAccount: The user who wants to join the system need to first register an account from the AP. For a new user $u$, the AP selects an unused value $w_{u}$ from $\lbrace w_{1},...,w_{n}\rbrace $, and computes the witness $W_{u} = \triangle ^{(\frac{1}{d+w_{u}})}$. Then the AP sends $(W_{u}, w_{u})$ to the user $u$.

• RequestCred: The user who wants to get an valid credential make a request to the IDP. With the the attributes list $AttrL = \lbrace a_{1},...,a_{m}\rbrace$, this algorithm randomly chooses $t \in \mathbb {Z}_{q}$ and computes $T = g^{t}, \tau = T^{w_{u}} {\textstyle \prod _{i=1}^{m}}h_{i}^{a_{i}}$.Then it gets the credential $C =(T, \tau)$ and generates \begin{align*} ZKP_{1} \lbrace (w_{u}, W_{u}) :&\left.\tau = T^{w_{u}}{\textstyle \prod _{i=1}^{m}}h_{i}^{a_{i}}\right.\\ &\left.\wedge e(\Delta, g_{2}) =e (W_{u},Y_{AP}g_{2}^{w_{u}}) \rbrace \right. \end{align*}prove to IDP that the user has a valid account $w_{u}$ and the credential is generated by the same account. In addition, for privacy requirements, the user can select privacy attributes from $AttrL$ and mark the indices of the privacy attributes as $PrivInd = [I_{1},...,I_{l}]$, where $l$ denotes the number of privacy attributes. Then the user prepares attributes sets $AttrSets = (\Phi _{1},...,\Phi _{l})$ containing his privacy attributes (e.g., $a_{I_{1}} \in \Phi _{1},..., a_{I_{l}} \in \Phi _{l}$). Finally, it gets the credential request $CredQst=(C, ZKP_{1}, AttrL, PrivInd, AttrSets)$, and send $CredQst$ to the IDP via a secure channel.

• IssueCred: Receiving the credential request $CredQst$ from user $u$, the IDP first verifies the $ZKP_{1}$ and checks whther the user indeed satisfies the request attributes $AttrL$. If the verification result is success, the IDP calls ASC.setStore($AttrSets$) and gets the returned $SetsId$, which can be used to query the $AttrSets$, then it calls CMC.credentialIssue($C, SetsId, CredType$) and gets the returned $CredId$; otherwise, the IDP rejects this request. $CredType$ indicates the type of issued credential, like Bachelor's degree certificate. The details of credentialIssue() are described in Algorithm 1. In addition, as the credential has been issued, if it has privacy requirements, the IdP generates signatures of each privacy attribute and output the signature sets $ AttrSigns = (\lbrace (\sigma _{\Phi _{I_{1}1}},...,\sigma _{\Phi _{I_{1}f_{1}}}),...,(\sigma _{\Phi _{I_{l}1}},...,\sigma _{\Phi _{I_{l}f_{l}}}) \rbrace)$, where $ \sigma _{\Phi _{ij}}$ = Sign$(sk_{IDP}, \sigma _{\Phi _{I_{i}j}})(i = \lbrace 1,...,l\rbrace, j = f_{i})$ are signatures of all the elements in set $\Phi _{I_{i}}$ (of length $f_{i}$). Finally, IDP sends the values $(CredId, AttrSigns)$ to the user. As we mentioned in Section IV-A, an optimisation can be made here by reusing the $AttrSigns$ for different type of credentials while the credentials contain the same $Attrsets$. The $CredQst$ above will change to $(C, ZKP_{1}, AttrL, PrivInd, SetsId)$ relatively.

• Show: The user who wants to access service from the SP needs to provide a valid credential to prove the satisfaction of required attributes. Given the account $(W_{u}, w_{u})$, the credential $C$, and signature sets $AttrSigns$, the user $u$ first chooses an identity for authentication, here we use a blockchain address $Addr_{u}$ as example, and it can be used to run the challenge-response protocol designed in [6]. Then for the privacy attributes in $PrivInd$ the user wants to hide, computes a proof \begin{align*} ZKP_{2}&\left. \lbrace (a_{I_{1}},...,a_{I_{l}}, w_{u}, W_{u}):\right.\\ &\left.\tau = T^{w_{u}}{\textstyle \prod _{i=1}^{m}}h_{i}^{a_{i}} \right.\\ &\left.\wedge e(\Delta, g_{2}) =e (W_{u},Y_{AP}g_{2}^{w_{u}})\right.\\ &\left.\wedge (a_{I_{1}} \in \Phi _{I_{1}}) \wedge... \wedge (a_{I_{l}} \in \Phi _{I_{l}})\rbrace \right. \end{align*} showing to SP the ownership of the attributes. Finally, the user $u$ gets the $ServiceQst = (Addr_{u}, ZKP_{2}, CredId, AttrL_{pub})$, where $AttrL_{pub}$ is selected from $AttrL$ with attributes that needs to be public, and sends $ServiceQst$ to the SP via a secure channel.

• Verify: Receiving the service request $ServiceQst$ from user $u$, there are several steps to verify the request, and the SP excutes as follows:

1. Calls CMC.credentialQuery$(CredId)$ to get the status of the credential, the content of credential $C$, the issuer of the credential and the $SetsId$, if the status is $True$, then continue; othervise, rejects the request. The details of credentialQuery() are shown in Algorithm 2

2. Checks the issuer of the credential to see if it is a valid IDP, gets the $pk_{IDP}$ from ERC if the result is OK; otherwise, rejects the request.

3. Calls ASC.setQuery($SetsId$) to get the $AttrSets$, check if the attributes $AttrSets$ combine with the $AttrL_{pub}$ satisfies the requirements. If the result is OK, continue; otherwise, rejects the request.

4. Verifies the $ZKP_{2}$, if the result is success, the SP performs an authorization operation to grant the service access request. In addition, the SP can store the $Addr_{u}$ for the future authenticate.

• RevokeCred: To revoke a credential $C$ with its id $CredId$, IDP calls CMC.credentialRevoke($CredId$). Algorithm 3 shows the details of credentialRevoke(). The ’status' of $CredId$ will be set to $False$ in this function.

• RecoverCred: To recover a credential $C$ with its id $CredId$, IDP calls CMC.credentialRecover($CredId$). The details of credentialRecover() are almost the same with Algorithm 3, except that it will set the ’status' of $CredId$ to $True$.

• RevokeUser: To revoke user $u$, AP updates $URL$ with $w_{u}$, where $URL = URL \cup \lbrace w_{u}\rbrace$, and computes a new accumulator $\Delta _{new} = \Delta ^{\frac{1}{d+w_{u}} }$. Then the AP calls AMC.accountRevoke() to update the $URL$ and $\bigtriangleup$ stored on blockchain. Each user $i(i\ne u)$ needs to update the witness $W_{i}$ with $W_{i_{new}} = \frac{W_{i}}{\Delta _{new}}^{(\frac{1}{w_{u}-w_{i}}) }$.

Algorithm 1: CMC.credentialIssue().

Algorithm 2: CMC.credentialQuery().

Input: $CredId$

Output: $status, C, issuer, SetsId$

1:

$status \leftarrow CredMaps[CredId].status$;

2:

$C \leftarrow CredMaps[CredId].credential$;

3:

$CredType\leftarrow CredMaps[CredId].credentialType$;

4:

$issuer \leftarrow CredMaps[CredId].issuer$;

5:

$SetsId\leftarrow CredMaps[CredId].attrSets$;

6:

return ($status, C, issuer, SetsId$)

Algorithm 3: CMC.credentialRevoke().

Input: $CredId$

Output: Void

1:

Require CMC.issuerQuery($CredId$) == $msg.sender$;

2:

$CredMaps[CredId].status = False$;

Algorithm 4 AMC.accountRevoke()

Input: $w_{u}, \Delta _{new}$

Output: Void

1:

Require $msg.sender$ == $owner$;

2:

Append $w_{u}$ to the user revocation list;

3:

$accumulator \leftarrow \Delta _{new}$;

SECTION V. Security Analysis

In this section, we will discuss the security properties of our proposed protocol, and proof that it achieves the security goals of our identity model, which include attribute privacy, unforgeability, soundness, unlinkability, and behavior privacy.

Lemma 1:

Our DID protocol achieves attribute privacy if the proof $ZKP_{2}$ is zero-knowledge.

Proof:

During the generation of the $ServiceQst$ in the show phase, the user will add $AttrL_{pub}$ to present the attributes that he wants to disclose, and no operation will be performed for the attributes that need to be completely hidden. For the privacy attributes that require range proofs to prove their range, the corresponding proofs are included in the zero-knowledge proof $ZKP_{2}$, thereby the specific attribute values of these privacy attributes are hidden. The zero-knowledge nature of the range proofs is proven in Section IV-A, so no additional information about user privacy attributes will be leaked in $ZKP_{2}$.

In summary, after obtaining $ServiceQst$ during the show phase, other entities will be unable to learn any attribute information other than the user's own public attribute set $AttrL_{pub}$ and the set of range proofs for privacy attributes $AttrSets$. This means that the relevant information for hidden attributes will not be disclosed.

Lemma 2:

Our DID protocol achieves Unforgeability if the blockchain private keys in the protocol are all properly kept and not leaked.

Proof:

During the proceeding of a credential, only the credential formed by IDPs can be stored in CMC, which requires the blockchain private key of a valid IDP. In addition, as the credential is issued with the user's account involved, the account $w$ is needed to show a valid credential, which means a malicious user cannot replace the account with others'. Hence, assuming that an adversary can show a valid credential, it must own the related account; othervise it will break the soundness and honest-verifier zero-knowledge of the PS-based set membership in $ZKP_{2}$. Thus no one can impersonate others without their accounts.

Lemma 3:

Our DID protocol achieves soundness if $ZKP_{2}$ is sound.

Proof:

In show phase, the user $u$ needs to generate a valid zero-knowledge proof $ZKP_{2}$ along with account $w_{u}$ and privacy attributes set $(a_{I_{1}},...,a_{I_{l}})$. The soundness property of $ZKP_{2}$ guarantees that if a user can generate $ZKP_{2}$ for a tuple $(a_{I_{1}},...,a_{I_{l}}, W_{u}, w_{u})$ and pass the verification, then there exists an extract algorithm $Extract$ that can output the witness.

Lemma 4:

Our DID protocol achieves unlinkability if $ZKP_{2}$ is zero-knowledge.

Proof:

In show phase, the user $u$ needs to generate a valid zero-knowledge proof $ZKP_{2}$ along with account $w_{u}$ and privacy attributes set $(a_{I_{1}},...,a_{I_{l}})$. The honest-verifier zero-knowledge property of the PS-based set membership in $ZKP_{2}$ guarantees that no additional information about privacy attributes and user's account is revealed while showing the credential. The signatures used in our PS-based set membership protocol is randomized for each privacy attribute in $ZKP_{2}$, ensuring that the relations between user's account and privacy attributes is hidden, thus guaranteeing the unlinkability.

Lemma 5:

Our DID protocol achieves behavior privacy if the SPs are not colluded with other entities.

Proof:

While user $u$ making $ServiceQst$ in show phase, the used $Addr_{u}$ is selected independently for different request, and has no relation with the user's account, due to the zero-knowledge property of the $ZKP_{2}$, there is no information leaked about account $w_{u}$, thus the attacker cannot deduce the user's account that represents user's real identity from the $Addr_{u}$ used in $ServiceQst$. In addition, the $CMC.credentialQuery()$ made by the SP is a state query for the blockchain, and will not be packaged as a transaction in ethereum blockchain, thus it's not visible to others except the blockchain node which handles this query. It means that others cannot analysis from the blockchain to see which service the target credential owner is accessing.

Table 1 shows the comparisions of some mentioned identity systems build on blockchain. The comparisions mainly focus on the security property and privacy protection, from the results, our proposed protocol has robust security and enhanced privacy protection.

TABLE 1 Comparisions of identity systems build on blockchain

SECTION VI. Experimental Evaluation

We simulate the application scenario of our proposal by developing a prototype that includes a simple client for users and a server for AP, IDP and SP. The framework of the client and server is MIRACL + Node.js + Web3.js + Vue.js, and the code of core algorithms (such as the zero-knowledge proof) is using the MIRACL library, then we call these functions in Node.js with native addon. The operating environment of our prototype is a macOS desktop computer with Intel(R) Core(TM) i5-1038NG7 16.00GB RAM. Additionally, we implement the smart contract functions in our scheme with solidity and deploy it to Ethereum. The client can generate zero-knowledge proof and query the status of credentials from blockchain, and the server can act as AP, IDP and SP to verify the proof provided by the client and call functions in smart contracts through transactions. The code of our proposal is published on Github².

We evaluate the performance of our proposed DID protocol; first, we give a complexity analysis of each algorithm and then we make a benchmark of these algorithms to show the execution times. Furthermore, we count the communication costs of our proposed PS-based range proof protocols, and compare it with other range proof protocols. Finally we evaluate the smart contract functions to measure the gas consumption and transaction throughput in Ethereum.

A. Use Case

In this section, we will show an example of our proposed protocol use case. Assuming that a user named Alice has registered an account from the AP already, and she wants to request a credential from an IDP (e.g., the company). As shown in Fig. 6, the credential includes some attributes that the IDP support to hide, like the value of income or the year of the birth date. If Alice wants to hide the attribute value, she could click the option and select the range that the value is hidden in. In our protocol, the larger range means a higher cost to the IDP, so Alice will choose the range based on the demand.

Figure 6.

Request credential in client of user.

While receiving the credential, Alice can query the information of it through the $CredId$ from blockchain. Fig. 7 shows that the client is checking the status of the credential, which indicates whether the credential is revoked by the issuer.

Figure 7.

Check status of credential in client of user.

Then Alice wants to join a online group whihc has a threshold that requires applicants to be over 18 years old and have an annual income over $50000. Fig. 8 shows that Alice's client could generate proof of $ZKP_{2}$ for the selected privacy attributes, here she chooses to hide the birth year and the actual income value, then sends the proof to the target server for the verification. While all of the check steps are passed, Alice join the online group successfully.

Figure 8.

Show credential to SP for verifying.

B. Complexity Analysis

We make a complexity analysis of our proposal and compare it to BASS[30] and Sucasas et al. [31], the result is shown in Table 2, where $m,l$ denotes the number of all attributes and privacy attributes, the $|\Phi |$ represents the size of set. We use $E_{1}, E_{2},E_{T},E_{P}, M_{1},M_{2},M_{T},M_{P}$ to represent the exponentiation operation and multiplication operation in $G_{1}, G_{2}, G_{T}$ and $F_{P}$ respectively, and the pairing operation is denoted as $P$, the $H$ is a hash operation.

TABLE 2 Complexity analisis of algorithms

From the result, we can find that in some phases like “RevokeCred”, “RecoverCred” and “RevokeUser”, our proposed scheme behaves much better than BASS [30] and Sucasas et al. [31], this is because the revocation status is updated on blockchain in our protocol, thereby avoid recomputing new credential. Specifically, the $|\Phi |E_{1}$ during “IssueCred” phase can be Optimised while the user chooses to reuse previously obtained signatures. Additionally, while the number of privacy attributes $l=1$, the computation cost between our protocols and BASS are almost equal in the remaining phases, while the pairing cost of [31] grows with $m$. But our protocol support range proofs while showing the credentials, which provides enhanced privacy.

C. Timing Benchmark

Table 3 shows the execution time of each procedure described in Section IV-B with both single privacy attribute and multi privacy attributes (two attributes in the table), note that we execute each entry for 10000 times and computes the average value.

TABLE 3 Execution times of algorithms (milliseconds)

The comparision between single privacy attribute and multi privacy attributes is shown in Fig. 9. The cost of multi privacy attributes is surely higher, due to the extra pairing and exponentiation operation in $G_{T}$ during the “Show” and “Verify” phases relating to the growing number of privacy attributes. For the “IssueCred” phase, there are additional exponentiation in $G_{1}$ to generate PS signatures for the attributes sets, which increases with the size of the set and the number of privacy attributes. Finally, the performance in “RequestCred” phase is actually the same, for the cost of this step grows linearly with the number of attributes the credential contains.

Figure 9.

Comparison of our proposal with single and multi privacy attributes.

D. Communication Analysis

Our proposed range proof scheme and the scheme designed in [40] both require the transmission of signatures during the initialization phase. Therefore, the communication cost of the initialization phase is included in the overall communication cost analysis. In contrast, the scheme proposed in [41] does not include this phase. Table 5 presents a comparison of the communication costs of these three schemes.

TABLE 4 Gas cost of our DID protocol

TABLE 5 Communication cost

Since the initialization phase is only executed once during the proof process, we mainly focus the execution phase cost here. In this phase, our scheme has a slightly higher communication cost compared to Camenisch et al.’s scheme [40], with an additional size of $|G_{1}|$. On the other hand, the communication cost of Poelstra et al.’s scheme increases linearly with the size of the set to be proved. Therefore, in the execution phase, our scheme has a lower communication cost compared to [41] but slightly higher compared to [40].

E. Blockchain Implementation

1) Gas Consumption

The blockchain platform of our work is Ethereum with the version of London. While performing operations in Ethereum, it needs to consume a certain quantity of gas. The gas price is set by the transaction sender and reflects the quality of ethers that the sender is willing to pay. The fee cost for the whole transaction is calculated as $Fee_{cost} = Gas_{price} * Gas_{cost}$. During the analysis, the transaction fee in Ethereum is high, so we set the gas price to the average price of 20Gwei (0.00000002 Eth) to make sure our transactions can be packaged within minutes. The cost of different functions in our protocol is shown in Table 4.

2) Transaction Throughput

While our proposal is deployed in Ethereum, the long time takes to wait for the transaction confirmation and the low TPS (Transactions Per Second) of public blockchain may become a limitation. In our proposed system, the functions like “RegisterAccount” and “IssueCred” need to send transactions to call smart contract functions, thereby the throughput of these phases depend on the transaction throughput. The TPS in the Ethereum can be calculated as $TPS = Block_{gaslimit} / (TX_{gas} * Block_{time})$, where $Block_{gaslimit}$ represents the gas limit of a single block, $TX_{gas}$ represents the gas cost to execute the transaction and $Block_{time}$ denotes the block time interval.

During the evaluation, the $Block_{gaslimit}$ of Ethereum is about 30000000, and the average $Block_{time}$ is 15 seconds. In this situation, the TPS of “RegisterAccount” and “IssueCred” functions can reach 21.60 and 15.82, which can meet the most needs of register an account and request for a credential. Additionally, the main traffic in our protocol is concentrated in “Show” and “Verify” phases to use the credentials. However, there is no need to send transactions in the “Show” and “Verify” phases, so the whole throughput of our system will not be limited by the transaction throughput.

SECTION VII. Conclusion

Most of the online social networks are using centralized identity management systems, which lack of privacy protection. DID can be a solution to this, but existing protocols do not provide a full set of desired properties, especially the user's attributes privacy and behavior privacy. In this paper, we first propose a range proof protocol based on PS signature, which is suitable for our application scene. Then we change the W3C identity model and introduce a new entity named AP to guarantee the uniqueness of identity and provide user revocation with dynamic accumulators. Finally, we design a DID protocol using our proposed range proof. The proposed protocol is based on blockchain and achieves attribute privacy, unlinkability, and behavior privacy. It can be shown from the experimental evaluation and findings that the extra overheads of our protocol are tolerable compared to BASS, for our scheme enhanced the privacy of users.

ACKNOWLEDGMENT

We greatly appreciate the invaluable suggestions provided by the anonymous reviewers and the associate editor.