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.


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.
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. 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: r We propose a range proof protocol based on PS signature, and use it to build a identity management scheme for OSNs.
r 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.
r 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.

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

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: r Setup: Given a security parameter λ, 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 .
r Sign: Given the public parameters PP, a private key sk, and message m, this algorithm randomly chooses u ∈ Z q and computes A = g u 1 , B = A x+ym , then it returns σ = (A, B) as the signature of m.
r Verify: Given the public parameters PP, a public key pk, a message m and signature σ , this algorithm returns 1 if e(A, X Y m ) = e(B, g 2 ); otherwise, returns 0. Moreover, PS signature has the property of randomizability, a PS signature σ = (A, B) on a message m can be randomized by randomly selecting t ∈ Z q and getting a new signature σ = (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 -protocol is a three-move zero-knowledge proof system, and is an interactive protocol that achieves honestverifier zero-knowledge, which means it has the property of zero-knowledge while the verifier is honest. With the notion in [34], we let ZKP{(α) : y = g α } denote a zero-knowledge proof of integer α that y = g α , where y, g are elements of a group G. There are other relation instances can be proved, like ZKP{(α, β, γ ) : 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 = {φ 1 , ..., φ n } into an accumulator , and a value so-called witness can be efficiently computed to prove the membership of element φ 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 haveg ∈ G 1 . Set Then for a set = {φ 1 , ..., φ n }, we can compute its accumulator as =g n i=1 (y + φ i ) . To prove the membership of an element φ i , we need to compute a witness Wit i = 1 y+φ i , and the verification will be e( , 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 φ t from accumulator .

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.
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: r 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.
r 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.
r 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.
r 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.
r 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.
r 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. r 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.
r Behavior Privacy: The service that the user requests for cannot be learned by other entities.

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 . Then the prover blinds the signature of the element it wants to commit (i.e., φ ∈ ) 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.
r Setup: Given a security parameter λ, this algorithm generates the public parameters PP = {q, G 1 , G 2 , G T , e, g 1 , g 2 , g, h, }, where q is a large prime numbers of λ bits length, (G, G 1 , G 2 , G T ) are cyclic groups generated with order q. The e : G 1 × G 2 → G T is a bilinear map. g 1 and g 2 are generators of G 1 and G 2 , and is a set.
r Initialize: The verifier needs to generate signatures for all elements in set . It randomly chooses x, y ∈ Z q as its signing key and computes X = g x 2 , Y = g y 2 as the corresponding public key. For any i ∈ , the verifier ZHU ET AL.: EFFICIENT DECENTRALIZED IDENTITY MANAGEMENT SYSTEM BASED ON RANGE PROOF FOR SOCIAL NETWORKS  randomly chooses u ∈ Z q , and computes r Excute: This step is executed by the prover and verifier to prove the following zero knowledge proof The prover randomly chooses r, ρ 1 , ρ 2 , ρ 3 ∈ Z q , and com- where φ ∈ is the secret value that prover holds. It also randomly chooses s, t ∈ Z q , and computes 2. The verifier chooses a random value c ∈ Z q as challenge and sends c to the prover. 3. The prover computes  Proof: The provement of our proposed set membership protocol is as follows.
Completeness: The completeness achieves by checking the equations 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 , then there exits an extractor that can output a witness (φ, r, s) with probability O( ) by interacting with P * . In addition, we can assume that the input of the extractor consists two arguments then the witness can be extracted by computing: When (c − c) is invertible in Z q , the extractor can successfully output the witness. If φ / ∈ , then P * can be (almost) directly used to successfully execute an adaptively chosen message attack against PS signature with probability O( ). Therefore, the 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).
Since the protocol has random s, t ∈ Z q , so the first two steps achieve perfect blinding.Which means no one except P * can recover (A φ , B φ ) from the ( A φ , B φ ). In addition, benefits from the zero-knowledge property of the -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 ∈ N), we first write the committed value φ in u-ary notation (i.e., φ = l−1 j=0 φ j · u j ), then we can prove φ ∈ [0, u l ) by proving each φ j in 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 φ 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. r Keygen: a) AP Keygen: Given the public prarmeters PP, this algorithm randomly choosesg ∈ G 1 and d, w 1 , w 2 , ..., w n ∈ Z q to compute Y AP = g d 2 and the accumulator = g (d+w 1 )···(d+w n ) , where n denotes the number of users. The sk AP = d, pk AP = Y AP . An empty User revocation list U RL = ∅ is also generated to set AP parameters param AP = {g, Y AP , ,U RL} and the AP calls AMC.paramsInit(param AP ) to put param AP on blockchain. b) IDP Keygen: Given the public prarmeters PP, this algorithm randomly chooses x, y ∈ Z q , computes X = g x 2 , Y = g y 2 . Then the IDP get sk IDP = (x, y), pk IDP = ( X , Y ), and calls ERC.entityRegister(pk IDP ) to put the public key on blockchain.
r 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 {w 1 , ..., w n }, and computes the witness W u = ( 1 d+wu ) . Then the AP sends (W u , w u ) to the user u.
r RequestCred: The user who wants to get an valid credential make a request to the IDP. With the the attributes list Att rL = {a 1 , ..., a m }, this algorithm randomly chooses t ∈ Z q and computes T = g t , τ = T w u m i=1 h a i i .Then it gets the credential C = (T, τ ) and generates 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 Att rL 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 = ( 1 , ..., l ) containing his privacy attributes (e.g., a I 1 ∈ 1 , ..., a I l ∈ l ). Finally, it gets the credential request CredQst = (C, ZKP 1 , Att rL, PrivInd, AttrSets), and send CredQst to the IDP via a secure channel.
r 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 Att rL. 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 Att rSigns = ({(σ I 1 1 , ..., σ I 1 f 1 ), ..., (σ I l 1 , ..., σ I l f l )}), where σ i j = Sign(sk IDP , σ I i j )(i = {1, ..., l}, j = f i ) are signatures of all the elements in set I i (of length f i ). Finally, IDP sends the values (CredId, Att rSigns) to the user. As we mentioned in Section IV-A, an optimisation can be made here by reusing the Att rSigns for different type of credentials while the credentials contain the same Attrsets. The CredQst above will change to (C, ZKP 1 , Att rL, PrivInd, SetsId ) relatively.
r 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 Att rSigns, 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 ZKP 2 {(a I 1 , ..., a I l , w u , W u ) : showing to SP the ownership of the attributes. Finally, the user u gets the ServiceQst = (Addr u , ZKP 2 , CredId, Att rL pub ), where Att rL pub is selected from Att rL with attributes that needs to be public, and sends ServiceQst to the SP via a secure channel.

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 Att rL 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 Att rL 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.

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 2 .
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.
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, 2 https://github.com/BlockchainDID/RPBDMS  which indicates whether the credential is revoked by the issuer.
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.

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 | | 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 3. Execution times of algorithms (milliseconds)
From the result, we can find that in some phases like "Re-vokeCred", "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 | |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. 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.

C. TIMING BENCHMARK
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.

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.
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 "Reg-isterAccount" 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 T PS = Block gaslimit /(T X gas * Block time ), where Block gaslimit represents the gas limit of a single block, T X 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.

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. XINJIE ZHU received the bachelor's degree from the School of Cyber Engineering, Xidian University, Xi'an, China, in 2020. He is currently working toward the master's degree with the Key Laboratory of Aerospace Information Security and Trusted Computing Ministry of Education, School of Cyber Science and Engineering, Wuhan University, Wuhan, China. His research interests include cryptographic protocols and blockchain.