Integrating Threshold Opening With Threshold Issuance of Anonymous Credentials Over Blockchains for a Multi-Certifier Communication Model

Authentication while maintaining anonymity when availing a service over the internet is a significant privacy challenge. Anonymous credentials (AC) address this by providing the user with a credential issued by a trusted entity that convinces the service provider ( $\mathcal {SP}$ ) that the user is authenticated but reveals no other information. The existing AC schemes assume a single trusted authority (certifier) that validates all the user attributes. In practice, however, a user may require different attributes to be attested by different certifiers. This means that the user has to get multiple credentials, increasing the burden on the $\mathcal {SP}$ who has to verify each one of them. Moreover, complete anonymity can be misused. We propose a decentralized threshold revocable anonymous credential (DTRAC) scheme over blockchains that supports – a) attestation of attributes by multiple certifiers, and b) anonymity revocation through a set of distributed openers, by integrating threshold opening to the state-of-the-art threshold anonymous credential issuance scheme, Coconut [35]. DTRAC generates a single credential on attributes that are attested by multiple certifiers, freeing the SP from the hassle of verifying multiple credentials. We analyze the security of DTRAC formally in the universal composability (UC) framework. We also implement a prototype on Ethereum using smart contracts and give a detailed analysis of its performance. We compare the verification time for credentials with attributes attested by multiple certifiers in both DTRAC and Coconut and see that in terms of execution time and gas consumption, DTRAC performs significantly better than Coconut. It also scales better, with the performance gain of DTRAC over Coconut increasing linearly with the number of certifiers.

can be presented several times while remaining unlinkable (or untraceable). Many AC schemes ( [7], [10], [12], [15], [25]) have a centralized credential issuer who verifies the attributes of the user and issues the user with a credential. But the issuer can be compromised or corrupt and is a single point of failure. Garman et al. [20] circumvents this limitation by introducing decentralized anonymous credentials (DAC) where the issuance of credentials happens over a distributed ledger. But presenting a credential in their scheme is expensive due to a double discrete-logarithm proof. CanDID [27], another credential issuance scheme, allows for a decentralized committee to issue credentials and is legacy compatible. But it uses secure multiparty computation (MPC) techniques that are computationally intensive. Coconut [35], an efficient, short and constant size credential scheme, over blockchains, allows for threshold issuance in a decentralized manner. But the security of the scheme was analyzed informally. Alfredo et al. [32] proved the security of Coconut formally but makes a few modifications to the scheme for that. We use this modified version for credential issuance to ensure unforgeability. Versatile ABS [3] is an attribute-based signature scheme that supports threshold opening to revoke the anonymity of the user. But in this scheme every service request needs to contain additional information to trace the user, making it inefficient. However, none of the above support validation of attributes by multiple certifiers in a single credential. Our proposed scheme aims to resolve the following two gaps in existing AC schemes.
1) The existing AC schemes assume that a single trusted authority (certifier) -which itself can be a single entity or a distributed set of entities -certifies/attests all the user attributes. If a service requires different sets of user attributes to be verified by different authorities then the user has to get multiple ACs, one from each authority. The service provider (SP) then must verify all these credentials before providing the service, which increases the burden on the SP. This is the case, for instance, with versatile ABS and Coconut where multiple credentials have to be verified if multiple certifiers attest to different attributes. 2) To bring accountability to anonymity, AC schemes either look at credential revocation [8], [11], [37], [39] or anonymity revocation/opening of a credential [3], [10], [11]. However, all the schemes proposed for the latter either rely on a centralized trusted entity and do not consider the possibility of it being corrupt, i.e. they do not support threshold opening, or they need more information in the credential to trace the user.
We use the following use case to explain the reasoning behind having multiple certifiers, each validating a different subset of user attributes. Suppose Alice wants to apply for a personal loan from a bank, Bob. Bob can provide a loan if the person meets certain eligibility criteria, say, criteria related to age and income. Alice would not want to share her personal information, her actual income details, or where she works,  with Bob. Any identity provider (IdP) can act as a certifier and certify the identity attributes. However, this agency cannot be expected to certify the income attributes for which we need an income certifier. For example, after verifying the supporting documents, an employer can provide Alice with an income certificate that certifies her income details. Alice now has to obtain a credential based on a set of attributes such as DoB from the identity attributes and income from the income certificate. Thus, there are two certificates issued by two different certifiers that Alice needs to present to Bob, and he has to verify both. Also, Bob's task increases with the number of certificates.
In order to address this problem, our scheme proposes a specially constructed digital certificate, referred to as a verifiable certificate (Vcert), to be issued by each certifier that attests to specific user attributes. These Vcerts hide the attributes using cryptographic primitives, but they are still verifiable. A secret master key is associated with all the Vcerts of one particular user, which links all the Vcerts of that user. In the loan application use case, the IdP provides an ID Vcert on the identity attributes and an employer provides an income Vcert on the income-related attributes as depicted in Figures 1 and 2. While requesting for an income Vcert, Alice provides the employer with her identity Vcert as an identity proof after which he validates her income attributes. In our scheme, a set of validators distributed over a blockchain verifies the attributes of the multiple Vcerts during a credential request as depicted in Fig.3. The zero-knowledge proofs of knowledge (ZKPoKs) of attributes are provided to the validators to convince them that the attributes were certified by the appropriate certifiers, but they reveal no other information. Each validator issues a partial credential on those attributes. A threshold number (not necessarily all) of these partial credentials are sufficient to form an anonymous credential and it can be verified using the aggregated public key of the validators. Our scheme, Decentralized Threshold Revocable Anonymous Credentials (DTRAC), enables Alice to obtain a single credential that she may use to prove to Bob that she meets all the eligibility criteria without revealing any private information. She is also free from the hassle of presenting numerous credentials. Note that we can have more than two certifiers, each attesting to their respective user attributes. We refer to this as a multi-certifier communication model. DTRAC extends the Coconut threshold issuance scheme [32] to support this multi-certifier communication model and provides a single anonymous credential for attributes attested by multiple certifiers. We analyzed the efficiency of DTRAC and our evaluations show that DTRAC performs significantly better than running multiple instances of Coconut. Also, this performance gain that DTRAC has over the Coconut scheme increases linearly as the number of certifiers increases making DTRAC more scalable than Coconut.
The revocation of anonymity in DTRAC is broadly based on the threshold opening scheme implemented for dynamic group signatures [9]. However, the threshold opening scheme in [9] works only for a single attribute, whereas credentials typically contain more. Hence, we extend it to support multiple attributes and integrate it into our threshold issuance scheme, allowing a designated set of distributed openers to open an anonymous credential if at least a threshold number of openers agree. We also provide a formal security analysis of DTRAC (Sec. VI).
In the loan application use case, if a law authority wishes to revoke a user's anonymity behind a credential then the authority can direct the distributed openers to open that credential. If a threshold number of openers collaborate, they can find the session in which the credential was issued. The law authority obtains the identity Vcert from that session, which it can then use to request to the identity provider to reveal the identity of the user. This is depicted in Fig.4.
A. OUR CONTRIBUTIONS 1) DTRAC supports a multi-certifier model and it issues a single anonymous credential to a user on a set of attributes where multiple certifiers certify/attest specific subsets of user attributes. 2) DTRAC enables optional revocation of anonymity that does not rely on a centralized opener by integrating a threshold opening scheme, previously designed for group signatures, to the threshold credential issuance scheme. The existing threshold opening scheme was modified in this work to allow for multiple attributes. 3) We provide a formal security analysis of DTRAC in the universal composability (UC) framework. 4) We provide a working PoC on the Ethereum blockchain for the loan application use case and give a detailed evaluation. We demonstrate that our scheme performs significantly better than the state-of-the-art threshold issuance scheme, Coconut in terms of execution time and gas consumption, for credentials with attributes attested by multiple certifiers.

B. PAPER ORGANIZATION
Sec. II introduces preliminaries of techniques used in our scheme. We give an overview of our approach and the building blocks that we construct as part of our scheme in Sec. III. We describe the system architecture in Sec. IV and the details of the actual construction in Sec. V. The formal security analysis is done in Sec. VI. The implementation details and the evaluation of the prototype is provided in Sec. VII and VIII, respectively. Sec. IX describes the related work and Sec. X contains concluding remarks.

II. PRELIMINARIES
We use Z to denote the set of integers, p for a prime number, Z p = Z/pZ for the ring of integers modulo p and 1 k for the security parameter. For an integer n ≥ 1, [n] denotes the set {1, . . . , n}.
We extensively use bilinear pairings in our work and they rely on elliptic curve groups and the hardness of the discrete logarithm problem (DLP) over elliptic curve VOLUME 10, 2022 groups. We give a brief introduction to bilinear groups in Appendix A-A. We use type III bilinear pairing groups [18] to build our scheme. We represent them as (p, G,G, G T , e), where G,G, G T are cyclic groups of prime order p and e : G ×G → G T is an efficiently computable, non-degenerate, bilinear mapping. Let G be an elliptic curve group of prime order p, DLP over elliptic curves is defined as follows: Let P ∈ G be a point on the curve and Q be a point in the subgroup generated by P. DLP is the problem of finding x ∈ Z such that Q = xP. It is assumed to be computationally hard. Note that we use the additive notation for elliptic curve group operations.

A. ZERO-KNOWLEDGE PROOFS (ZKPs)
Zero-knowledge proof is a two-party protocol that enables a prover to convince a verifier about the validity of a statement without revealing any further information. For a comprehensive introduction to ZKPs and ZKPoKs, one can refer to [21]. Here we outline the basic idea of Schnorr's interactive ZKP for discrete logarithms [33] used in our scheme. Let G be a generator of the elliptic curve group G of prime order p where DLP is assumed to be hard. Let Q and G be the two publicly available elliptic curve points such that Q = xG and x be the user's secret. The protocol starts with the prover (user) sending an elliptic curve point A = rG, where r is a randomly chosen element in Z p , to the verifier. The prover receives a random challenge c ∈ Z p from the verifier. The prover sends z = (r +cx) mod p to the verifier and the verifier is convinced of the user's knowledge of the secret x if zG = A + cQ. Schnorr's protocol can be transformed to the non-interactive ZKP setting using the Fiat-Shamir heuristic [16].

B. GENERALIZED PEDERSEN COMMITMENTS
A commitment scheme is a cryptographic algorithm that enables a prover to commit to a message without revealing it and without being able to modify it later. We use the Pedersen commitment scheme [29] in this work and in its generalized version, a prover can commit to a set of messages m 1 , . . . , m n ∈ Z p using a random value r, C = Commit(m 1 , . . . , m n ; r) which it sends to the verifier. C reveals no information about the messages and it is computationally hard to find another set of messages (m 1 , . . . , m n ) = (m 1 , . . . , m n ) such that Commit(m 1 , . . . , m n ; r) = Commit(m 1 , . . . , m n ; r). The construction relies on the hardness of the DLP problem.
• Setup. Pick an elliptic curve group G of prime order p with generators G, H 1 , . . . , H n where DLP is assumed to be hard.
• Commit(m 1 , . . . , m n ; r) = rG + m 1 H 1 + · · · + m n H n . There are efficient ZKPoK protocols that prove the knowledge of the opening of a commitment that satisfy numerous boolean relations over the commitment's opening [2].

C. PUBLICLY VERIFIABLE SECRET SHARING
A publicly verifiable secret sharing (PVSS) scheme [36] consists of a dealer and n participants. Each participant is associated with a public-private key pair. The dealer splits the secret into n shares and encrypts them with the public keys of the participants and distributes it to the participants. Anyone with access to the public keys of the participants can verify the correctness of the distributed shares, but they cannot view them. PVSS prevents malicious dealers from sending incorrect shares to the participants.

D. THRESHOLD PS SIGNATURES
PS signatures [30] are short signatures based on type III bilinear pairings. They are randomizable in the following way: given a signature σ for a message m, aσ for a scalar a = 0, gives us a fresh signature for m. They are constant in size, unlike say, CL signatures [12] where the signature size is linear in the number of messages to be signed. A (t, n)− threshold credential issuance scheme requires at least t signers out of n to issue an anonymous credential. PS signatures do not support threshold issuance. The Coconut implementation [35] addresses this limitation and introduces threshold PS signatures. But the authors analyze the security informally. Alfredo et al. [32] provides a formal security proof for a modified Coconut scheme and DTRAC uses this version, that provides unforgeability, for credential issuance. For credential verification, however, we use the older version of Coconut but this does not affect the correctness or security of our scheme.

E. THRESHOLD OPENING SCHEME
A (t, n)− threshold opening scheme reveals/opens the user's identity associated with an anonymous credential if at least t openers out of the n work together. In [9], a PVSS scheme (see Sec. II-C) is used to integrate threshold opening with threshold issuance for group signatures. The users send the opening information required for anonymity revocation during credential issuance, encrypted using the public keys of the openers. A zero-knowledge proof is also sent by the user to convince the issuers of the correctness of the encrypted opening information. The issuance happens through a public ledger so that the openers can collect the opening information. Later, while revoking the anonymity, a threshold number of openers work collaboratively to identify the user. Note that the threshold opening scheme for group signatures [9] supports only one attribute and in DTRAC we extend it to multiple attributes since credentials typically contain more than one attribute. Typically, the openers are different entities from the issuers.

F. TAMPER-RESISTANT PUBLIC LEDGER
Blockchains are based on a synchronized distributed ledger technology (DLT), which acts as a decentralized database, maintaining information replication and sharing among several nodes distributed over remote locations, with a consistent view across all the nodes. A blockchain thus offers transparent, verifiable and tamper-proof data storage. Our system uses the blockchain as a publicly distributed append-only ledger. It ensures all the honest validators and openers receive the same data and this enables threshold issuance and threshold opening of a credential. Our PoC is implemented over the Ethereum blockchain as its smart contracts allow for the necessary mathematical operations and enable interaction among distributed stakeholders in a tamper-resistant and verifiable manner.

G. UNIVERSAL COMPOSABILITY FRAMEWORK
The UC framework [14], an ideal-world/real-world paradigm, guarantees the security of protocols that are arbitrarily composed of other instances of the same or different protocols. This is useful in showing the security of our scheme. To show the security of a protocol Π in the real world in the UC framework, we have to first propose an ideal functionality F which captures the desired/ideal properties of the system. All the parties involved send their inputs to F, which locally computes the outputs and hands them back.
We say that the protocol Π in the real world UC-securely realizes an ideal functionality F if the environment Z cannot distinguish between an adversary A interacting with the protocol Π from a simulator S, that we construct to simulate the ideal adversary, interacting with the ideal functionality F. We first design a hybrid model where the real-world protocol Π has access to certain functionalities in the ideal world and show that it UC-securely realizes F. This is enough to show the security of the protocol since the UC paradigm states that if we replace each invocation of the ideal functionalities that Π has access to with its corresponding real-world protocols then Π securely realizes F in the real world. The user is an entity who wishes to remain anonymous while availing of service from a service provider. The service provider needs to verify if the user attributes have been attested by the certifiers and if the attributes satisfy certain conditions before providing a service. The user relies on multiple certifiers to certify several subsets of her attributes. She consents to have her anonymity revoked in certain circumstances by a designated set of openers.

III. DTRAC MODEL AND BUILDING BLOCKS A. STAKEHOLDERS
A certifier (CP) is an organization that certifies specific user attributes. The CP is trusted to certify the attributes correctly. In our scheme, we can have multiple CPs, each attesting to specific user attributes. After certifying the user attributes, each CP issues a specially constructed and privacy-preserving digital certificate called a verifiable certificate (Vcert) (see Sec. III-C1) on those attributes. The actual certification procedure depends on the use case and is outside the scope of this paper.
The distributed validators are an independent set of authorities where each validator issues the user with a partial credential (Pcred) after verifying the Vcerts. At least a threshold number of validators have to issue Pcreds to form an anonymous credential of the user. They do not view the actual attributes but only the ZKPoK that the attributes were verified by the respective certifier.
The distributed openers can open an anonymous credential if deemed necessary. They are typically an independent set of authorities where each opener maintains a private registry to store their opening share corresponding to each user. At least a threshold number of openers have to work collaboratively to open an anonymous credential, i.e., perform an anonymity revocation.
A service provider (SP) provides a service to an authenticated user anonymously. The SP verifies that the attributes are validated by the (distributed) validators but in the process learns nothing about the user attributes unless the user decides to disclose them.

B. THREAT MODEL
Our threat model assumes that the certifiers will do their job of certifying the attributes correctly. We also assume that they will not collude with each other. If they do collude, since the Vcerts issued by multiple certifiers are linkable, the information of each Vcert, and thus all the attributes of the user, will be revealed. But in our scheme even if the certifiers collude with the SP, the credential will remain anonymous. In fact, the SP is not trusted and can collude with all the other entities and the credential will still remain unlinkable. The threat model assumes users to be potentially malicious. Let n V and t V be the total number of validators and the corresponding threshold value, respectively, and n O and t O be the total number of openers and the corresponding threshold value, respectively. Integrity and availability are guaranteed under the corruption of a subset of validators that are less than the min(t V − 1, n V − t V ) and a subset of openers that are less than the min(t O − 1, n O − t O ). That is, forging of a credential is prevented if there are at most t V − 1 corrupt validators. DTRAC also precludes the misuse of anonymity revocation if there are at most t O − 1 corrupt openers. We assume that the number of dishonest validators cannot exceed the value . A similar assumption holds for openers while revoking the anonymity of a user. An opener who participates in the opening protocol is assumed to share the correct opening information with the other openers.
We assume that the blockchain infrastructure is secure and that adversaries do not control enough resources to disrupt the decentralized consensus of the network. The adversary can eavesdrop on all the blockchain transactions, and we assume there exists a secure channel for off-chain communication.

C. BUILDING BLOCKS
DTRAC comprises the following building blocks -verifiable certificates (Vcerts), a multi-certifier model, a threshold issuance scheme and a threshold opening scheme. They are built using pairings-based cryptographic primitives, a publicly verifiable secret sharing scheme (PVSS), threshold PS signatures, Pedersen commitments, and zero-knowledge proofs of knowledge (ZKPoKs), all of which we briefly describe in Sec. II. A PVSS scheme helps integrate threshold opening with the threshold issuance scheme. The opening information is encrypted by the user using the public keys of the openers and is shared with all the openers. The distributed validators verify the correctness of the opening information as part of threshold issuance using the PVSS scheme, which does not happen in the Coconut scheme where opening is not a feature.
As stated before, one of the novel features of DTRAC is that it allows multiple certifiers to attest to specific attributes, and we explain in detail the building blocks specially designed for it below.

1) VERIFIABLE CERTIFICATES
A verifiable certificate (Vcert) is an enhanced version of an attestation certificate. The Vcert hides the user's attributes but still can be used to prove their authenticity. Using Vcerts, the validators can verify that a certifier has attested the user attributes, without actually viewing the attributes.
The user requests for a Vcert on a set of attributes using the Pedersen commitment to her attributes and a ZKPoK, to prove the correctness of the commitment. The binding property of Pedersen commitments ensures that the user cannot modify the attributes that she has committed to. A certifier verifies the user's attributes corresponding to the commitment and signs on it. The Vcert comprises a) the commitment to the user attributes and b) the digital signature of the certifier who verified these attributes. The construction is explained in Section V-A.
A user can have multiple Vcerts, each for a different set of attributes. An identity provider, for example, can be a certifier who verifies the user's identity attributes and provides the user with an identity Vcert. It is trusted to do that job properly. Except for the identity provider (IdP), every other certifier verifies the user's identity based on the identity Vcert provided by the user in zero-knowledge. All the Vcerts of a particular user are linked by a secret master key, generated once by the user. Note that the user has to use the same secret master key for all the certifiers if the Vcerts have to be consolidated into a single credential.
The Vcert issuance design supports all-or-nothing nontransferability -if the user shares any one of her Vcerts with another user, i.e. the user shares her Vcert with the master secret key and the attributes, then it effectively means she is sharing all her Vcerts. This should deter any user from sharing them. To enable this, a public repository is maintained by each certifier where it stores the encrypted user attributes, which can be decrypted using the user's secret master key.

2) MULTI-CERTIFIER COMMUNICATION MODEL
One of the novel features of DTRAC is that it allows multiple certifiers to verify disjoint subsets of user attributes. For instance, we can have an identity provider confirming the user's identity attributes and an employer attesting to, say, the user's income attributes. Each certifier provides a verifiable certificate (Vcert) to the user after verifying the corresponding attributes. The actual process by which the certifier verifies will depend on the application and is beyond the scope of this work.
The multi-certifier model enables a user to obtain Vcerts on different sets of attributes, each verified by the respective certifier in a privacy-preserving manner. The issuance of a Vcert uses a non-interactive ZKP protocol that hides the user's secret master key. The Vcerts are then presented to a set of distributed validators to obtain an anonymous credential.
The multi-certifier model is more efficient than running multiple instances of a single certifier threshold issuance scheme, such as the Coconut scheme, in parallel. This is because our model requires verification of only a single credential by the SP as opposed to multiple credentials in Coconut. For example, consider the loan application use case discussed in Sec. I. On running two instances of the Coconut scheme, the user gets two credentials -one based on her identity attributes and another based on her income attributes. The SP has to verify both credentials. In our proposed scheme, the SP needs to verify only a single credential and it contains all the required attributes. The two certifiers provide attestation on their respective sets of attributes in the form of an ID Vcert and an income Vcert and the user requests an anonymous credential from the distributed validators in a single interaction. Since DTRAC provides a single credential, the size of the credential is constant irrespective of the number of attributes. This is not the case if we have different credentials for each set of attributes. The performance benefit of having only one credential to verify is very significant as we will show in Sec. VIII-C, where we will compare the PoC we develop with the Coconut scheme. In fact, the performance gain increases linearly as the number of certifiers increases.

IV. SYSTEM ARCHITECTURE
Here, we give the system overview of our scheme. The working of DTRAC is divided into four phases as depicted in Fig. 6: Registration, Issuance, Verification and Opening. We describe each phase and its corresponding cryptographic methods below and in Sec. V we provide more details of all these methods.

A. REGISTRATION PHASE
The steps 1.1 and 1.2 in Fig. 6 correspond to the registration phase where a user obtains an attestation on her attribute from a certifier in the form of a Vcert. As depicted in Fig. 7, the user first computes the commitment C to her attribute m and her secret master key sk u using the GenCommitment method. Also, to prove the correctness of the commitment, she generates a ZKPoK using the GenZKPoK method. The user sends the generated information to a certifier and requests for a Vcert which is an off-chain communication. The certifier verifies the ZKPoK using the VerifyZKPoK method. Once the verification is successful, the certifier signs, sign, on the commitment using the SignCommitment method, and sends the Vcert, (C, sign), to the user.
The user can request multiple Vcerts on different sets of attributes from the respective certifiers. If there is no dependency between the Vcerts, the registration phase can be parallelized.

B. ISSUANCE PHASE
In the issuance phase (Steps 2.1 -2.4 in Fig. 6), the user sends a credential request containing a commitment to a set of attributes, Vcerts and the encrypted opening shares to the validators and the openers through the blockchain. Each validator verifies the request and issues a partial credential to the user. The user needs to collect a certain number of partial credentials, the value of which is set by the application, so that they can be aggregated to form a single anonymous credential.
The issuance protocol follows a modified PS threshold issuance scheme, where t V out of n V partial credentials will be aggregated to form an anonymous credential. The credential request is generated using the PrepareCredRequest method and sent to the distributed validators. As depicted in Fig. 8, the credential request contains the following information: 1) Vcerts, 2) commitment to all the attributes (Eq. 1), 3) commitments to individual user attributes (Eq. 2), 4) encrypted opening shares of the attributes, and 5) the ZKPoKs proving that the attributes in the credential request are attested by the certifiers (Eq. 8). The encryption of the opening shares is performed using the public keys of the corresponding openers (Eq. 5) and the proofs of correctness of these ciphertexts in zero-knowledge are also provided (Eq. 7).
On receiving the request, each validator verifies the correctness of the attributes using the signature on the Vcert and the ZKPoK. Once the verification is successful, the validator issues a partial credential by blind-signing the attributes using the BlindSign method. The user uses the Unblind method to obtain the corresponding partial credential. Once the user has the threshold number of partial credentials, she aggregates them to form an anonymous credential using the AggCred method, and stores it in her local storage.
The distributed openers retrieve their respective opening shares from the credential request and store them in their private registry (Step 2.2 in Fig 6).

C. VERIFICATION PHASE
The user requests a service from the service provider (SP) through the blockchain by providing the aggregated credential (Steps 3.1, 3.2, 4 in Fig. 6). In the verification phase, the user has to prove to the SP that certain constraints over her attributes are satisfied. For example, in the loan application use case, she has to prove that her age is in a certain range and her income is above a certain value.
As depicted in Fig. 9, prior to requesting a service, the user randomizes her anonymous credential σ to obtain a fresh credential σ and decides which attributes to disclose. She generates the ZKPoK of the undisclosed attributes (Eq. 13) using the ProveCred method. She then requests the service through the blockchain using σ , the ZKPoK and the disclosed attributes. The SP verifies the ZKPoK and the credential using the aggregated public key of the validators (Eq. 14). Upon successful verification, the SP grants the service.

D. OPENING PHASE
The opening phase is executed by a designated set of distributed openers when it is deemed necessary to open the credential (Steps 5.1-6.3 in Fig. 6). Each opener broadcasts its opening information through the blockchain and upon receiving this information from at least a threshold number of openers, the openers execute the opening protocol to revoke the anonymity of the credential. It does this by linking the randomized credential used for the service request with the session in which the credential was originally issued.
As depicted in Fig. 10, each participating opener computes the opening information (Eq. 15) using the PreOpening method and sends it over the blockchain. They also retrieve the opening information from the other openers through the blockchain. After retrieving a threshold number, an opener calls the OpenCred method that outputs the issuance session identifier reqid associated with the user credential (Eq. 16). Since the Vcerts are linkable, the identity Vcert corresponding to the reqid can be used to identify the user.
Note that the openers cannot block the partial credential being issued by the validators in the issuance phase, as the openers only collect the opening information in this phase. Due to the consensus property of blockchains, all the honest parties -the validators and the openers -receive the same  information. Hence the same information cannot produce different verification results if the parties are honest.
Role of Blockchain. Blockchain, being a distributed and tamper-resistant public ledger, enables the openers to retrieve the appropriate opening shares in the issuance phase, as the roles of issuers and openers are separate. It also enables the openers to communicate during the opening protocol. An opener sends the opening information through the blockchain while opening a credential and this ensures that all the other openers receive the same information. The blockchain's consensus property makes it a stand-in for the public ledger.

E. PRIVACY PRESERVING LOANS -A USE CASE FOR DTRAC
Let Alice be a salaried employee who wants to avail a personal loan from a bank, Bob. To be eligible for the loan, she has to satisfy certain criteria say, her age should be between 22 to 58 years and her monthly income should be greater than a certain value, 'X'. DTRAC enables her to obtain a single credential that proves she satisfies all the eligibility criteria without revealing any specific details such as her actual age or income and also frees her from the hassle of showing multiple documents. Moreover, Bob has to verify only a single credential to accept or reject the loan. Using DTRAC, Bob processes the loan without knowing the actual age and income of Alice.  Alice obtains an ID Vcert on her identity attributes such as name, age and address from one of the authorized certifiers. She also obtains an income Vcert which is an attestation of her income details from a certifier such as her employer on attributes such as income, designation and company. She also generates her secret master key, sk u . To get a credential for the loan application, Alice has to generate a commitment on the subset of her attributes -name, age and income -and sk u and also generate the corresponding ZKPoKs that indicate that she has indeed committed to the correct attributes. Hence, the actual attributes are hidden from the validators using commitments. She also shares the encrypted opening shares so that the credential can be opened later, if necessary. Alice sends the commitments of her attributes, the Vcerts, and the ZKPoKs as part of a credential request on the blockchain. The Vcerts and the ZKPoKs are verified on the blockchain. On successful verification, each validator blind signs the commitments to form a partial credential, Pcred. Upon receiving a threshold number of partial credentials, the user aggregates them to obtain a credential σ . To apply for the loan, Alice randomizes the credential as σ and also generates the ZKPoKs that prove that her age is in the required range and her income is higher than the required value. Alice presents σ and the ZKPoKs to Bob. Bob verifies σ using the public key of the validators, and on successful verification, starts processing the loan.

V. DTRAC CONSTRUCTION
Here, we describe the phases and the corresponding methods of our scheme, DTRAC, in detail.

A. REGISTRATION PHASE
To request for a Vcert on q attributes a 1 , . . . , a q from a certifier, CP, the following steps are executed. Setup and Key Generation. The certifier, CP, generates all the public parameters for the Pedersen commitment scheme and a public-private key pair (pk CP , sk CP ) ∈ G × Z p , where G is an elliptic curve group of prime order p with G as its generator. The user generates a secret master key, chosen uniformly at random from Z p , and generated once per user. Let pk u = sk u G be the public master key of the user. Request Vcert. In order to request a Vcert, the user generates the commitment to its attributes and a ZKPoK of its correctness as follows.
The user selects a random r ∈ Z p and computes the Pedersen commitment to her attributes and secret key as C = Commit(sk u , a 1 , . . . , a q ; r).
The user constructs a ZKPoK π that convinces the certifier that the corresponding user has knowledge of the opening of the commitment and the public key corresponding to the secret key, sk u .
. . , a q ; r) ∧ pk u = sk u G }. She requests for a Vcert from the CP using π, C, pk u and a 1 , . . . , a q . Issue Vcert. On receiving the request, the CP issues the Vcert as follows. 1) VerifyZKPoK(C, a 1 , . . . , a q , pk u , π, pk id ) → (true/false). The CP verifies the attributes provided to it and the ZKPoK π sent by the user. On successful verification, the CP stores the attributes encrypted using pk u in a public repository and returns true, else false.
The user executes this method to verify the signature on the Vcerts. On successful verification it returns true, else false. Note that anyone with access to the certifier's public key, pk CP , can use this method to verify the signature on the Vcerts. Note that the key generation step is done only once and can be used for all future communication. As stated before, our system supports a multi-certifier communication model where multiple certifiers issue separate Vcerts for multiple disjoint sets of user attributes (Sec. III-C2).

B. ISSUANCE PHASE
To construct the issuance phase, we modify Coconut's threshold PS signature scheme so as to incorporate two additional information: a) Vcerts to allow for multi-certifier communication, and b) encrypted publicly verifiable opening shares of user attributes and proofs of correctness of the shares to enable optional revocation of anonymity. To accommodate this we modify the PrepareBlindSign method of Coconut [35, Sec. III.D] which is itself modified from [32,Sec. 7]. We refer to the modified PrepareBlindSign method as PrepareCre-dRequest method. Setup and Key Generation. The key generation of the validators can be done using a distributed key generation algorithm [23] but here, we rely on a single trusted party.
). Let RO : G → G be a random oracle that generates an element from the user's commitment to act as the common base for all the validators who validate the same credential request.
as the aggregated secret key of the validators and sends the corresponding Shamir secret shares (see Sec. generates a public-private ElGamal key pair (F k , z k ) ∈G × Z p and initializes an empty registry Reg k . Credential Request. The user requests for a credential on attributes (a 1 , . . . , a q ) specific to the service. For a simpler explanation, we assume that the credential request is made using a single Vcert.
• PrepareCredRequest(a 1 , . . . , a q , sk u , Vcert) , π s ). The Vcert has the form (C, sign), where C is the commitment on both the user attributes a 1 , . . . , a q and the master key sk u and sign is the signature of the certifier. The user computes a commitment C a on the attributes, a = (a 1 , . . . , a q ) and hashes C a to a point H on G, a j H j and H = RO(C a ). (1) The user generates random values o 1 , . . . , o q ∈ Z p and computes the commitment to each individual attribute a j , j ∈ {1, . . . , q} as As stated in Sec. I, we modify the threshold opening for group signatures in [9] to allow for multiple, say q, attributes. To achieve this, the user first picks q polynomials of degree t O − 1, where t O is the threshold number of openers needed to open the credential, to generate the Shamir secret shares of the attributes (Eq. 3). These Shamir shares are then used to generate the opening share (Eq. 4) which are encrypted using the public keys of the openers similar to what is done in [9]. The correctness is validated using Eq. 7 as we use a commitment (Eq. 2) to hide the user attributes from the validators.
For every opener O k , k ∈ [n O ], the user generates a Shamir secret share s k = (s k,1 , . . . , s k,q ) of (a 1 , . . . , a q ) and then calculates the k-th opening share as whereβ j is a part of the public key of the validators. The user encrypts µ k with F k , the public key of the opener O k , and a random r k ∈ Z p to obtain U k , the encrypted opening share of the opener O k as These shares are sent to the public ledger along with their ZKPoKs for which the user has to hide the coefficients of the polynomial by constructing The user generates the ZKPoK π k for each encrypted opening share, U k to prove the correctness of the share as follows, The user sends the Vcerts and the request parameters , π s ) over the ledger. Correctness of credential issuance for the multiple attribute extension. As stated before, the threshold opening protocol in [9] works only for a single attribute, whereas credentials typically contain more. We have extended it to allow for multiple attributes and we show below the correctness of this extension w.r.t the issuance phase. That is, we show that the construction of opening shares during the issuance phase is correct and that it can be verified by the pairing check we provide. Expanding the RHS, we see below that we get the same expression. Therefore, this equality check can be used to prove that the k-th opening share is constructed correctly. The user then generates the ZKPoK π s to prove the authenticity of the attributes in zero-knowledge as follows, Commit(a 1 , . . . , a q , sk u ; r) Note that anyone with access to the public keys of the openers can verify the correctness of the opening shares but only the openers can decrypt it. On successful verification of the proofs, each opener decrypts his respective opening share and updates his registry for the user with the session identifier reqid as Partial Credentials Issuance.
issues the blind signatureσ i using the BlindSign method to the user after verifying the Vcerts and ZKPoKs and sends it through the ledger. The user retrieves thisσ i and unblinds it to compute Pcred i (σ i ) as follows.
be the blinding factors used to build the commitment, X j . It parsesσ i as (H ,S i ) and unblinds the signature to obtain the partial credential, Credential Aggregation. Upon receiving a threshold number of Pcreds σ i , i ∈ T , where T is a set of validator indices from which the user receives the Pcred, the user aggregates them locally using the AggCred method (Eq. 11) to form an anonymous credential σ .
• AggCred({σ i } i∈T ) → (σ ). Each σ i is parsed as (H , S i ). The credential σ after aggregation is given by where w i is the Lagrange coefficient, defined as C. VERIFICATION PHASE Before verification, the service provider (SP) collects and aggregates the verification keys of the validators to obtain pk v as (G,α, {β j ,β j } q j=1 ). This process happens only once before any request.
Here, σ is parsed as (H , S) and pk v as (G,α, {β j ,β j } q j=1 ). The user chooses r, r ∈ Z 2 p and does the following: 1. randomizes the credential σ to obtain σ = (H , S ) = (r H , r S), 2. computes κ =α + q j=1 a jβj + rG and ν = rH which are VOLUME 10, 2022 required later to verify σ without disclosing the hidden attributes, and 3. generates the ZKPoK ZKPoK{(a 1 , . . . , a q , r) : κα+ q j=1 a jβj + rG 2) VerifyCred(pk v , σ , κ, ν, π v ) → (true/false). Here, σ is parsed as (H , S ) and the following checks are done: 1. H = 1 G , and 2. verifies π v and the following pairing equation On successful verification it returns true, else false. The verification process is the same as that of the Coconut scheme and therefore we omit the proof of correctness of the pairing check.

D. OPENING PHASE
In the opening phase, the openers are asked to revoke the anonymity of a randomized credential σ . The protocol is run between all the openers, and the output is the issuance session-id, reqid, corresponding to the session when the user was originally issued the credential.
The opening of a credential is essentially the verification of a signature. Camenisch et al. [9] uses the latest version of PS signatures [31] in his opening scheme while the Coconut scheme uses an earlier version [30].
where w j = l∈O\{j} l (l−j) is the j-th Lagrange coefficient. The reqid for which the above equation is successful is the user corresponding to σ .  We also provide a detailed security analysis in the UC framework in Sec. VI to ensure that the integration of threshold opening with threshold issuance does not affect the security and privacy of the anonymous credential scheme.

VI. SECURITY ANALYSIS IN THE UC FRAMEWORK A. IDEAL FUNCTIONALITY F AC
We first describe the ideal functionality F AC of our scheme that supports threshold issuance and threshold opening. For the former , F AC interacts with the validators {V 1 , . . . , V n V } and for the latter , F AC interacts with the openers {O 1 , . . . , O n O }. The threshold values of the validators and openers are t V and t O , respectively , i.e. , F AC assumes that at most t V − 1 validators and at most t O − 1 openers are corrupt. The other entities that F AC interacts with include a user U j , from the set of all users U , and a service provider SP. The user takes a pseudonym from the universe of pseudonyms , U p to present a credential to SP , presents authenticated Vcerts from the universe of Vcert validations , U φ during credential issuance , and shows a truth statement relating to attributes during credential show from the universe of statements relating to attributes , U ϕ . F AC stores and initializes three sets: L REQ for credential requests , L ISS for credential issuances and L VER for credential presentations. Each instance of F AC is identified by a session identifier sid = (P, sid ) where P = (V 1 , . . . , V n V , O 1 , . . . , O n O ) and sid is a random value that changes with each instantiation of F AC . The value qid is used to identify messages that are being communicated between entities. These messages are stored temporarily and deleted soon after the simulator responds so as to avoid replay attacks by the simulator. Since they are only temporarily stored we do not specify exactly where these messages will be stored. Note that when we say a fresh id is generated we mean that the value is unique across sid , reqid , qid and vid , where reqid and vid are session ids that uniquely identify credential request and credential show , respectively.

Setup:
1) The validators and openers inform F AC that their initialization is done. Each entity executes its initialization as part of setup and a flag is set to indicate its successful completion. 2) F AC verifies n V ≥ t V and n O ≥ t O . Credential request: 1) When F AC receives the request (sid, a = (a 1 , . . . , a q ), φ) from a user U j , it creates a fresh qid and saves (qid, U j , a, φ). 2) F AC sends (sid, qid) to the simulator S and S sends it back to F AC to simulate the real-world communication between the user and the validators and the openers. 3) If φ ∈ U φ and φ(a) = 1, i.e. if the attributes (a 1 , . . . , a q ) have been authenticated by the respective certifiers, F AC creates and stores a new record (reqid, U j , a, φ) in L REQ with a fresh reqid. This tuple ensures that the validators and the openers can later request the F AC to issue and open the credential, respectively, if the attributes of U j were authenticated by the certifiers. 4) F AC outputs (sid, reqid, φ, U j ) to all the parties in P. Note that a is always kept secret from the validators and the openers. 5) F AC deletes the record (qid, U j , a, φ) after all the validators and the openers have received the credential request. Credential issuance: 1) Each validator now has (sid, reqid, φ, U j ) of the user, U j . It sends (sid, reqid) to F AC . If a request with reqid is not present in L REQ , F AC aborts. 2) F AC creates a fresh qid and stores (qid, U j , a, φ, V i , reqid) to indicate that V i wishes to issue a partial credential to U j on attribute a. 3) F AC sends (sid, qid) to the simulator S and S sends it back to F AC to simulate the real-world communication between the validator V i and the user U j . 4) F AC stores (reqid, U j , a, V ∪ V i , O) in L ISS which indicates that the user now has partial credentials from the set of validators, V ∪ V i . 5) F AC outputs (sid, a, φ, V i ) to U j . 6) F AC deletes the record (qid, U j , a, φ, V i , reqid) to indicate that V i has issued the credential request.

Update information of openers:
1) Each opener now has (sid, reqid, φ, U j ) of the user, U j . It sends (sid, reqid) to F AC . If a request with reqid is not present in L REQ , F AC aborts.
which indicates that the opener O k has now updated its private registry corresponding to reqid. Presenting the credential (Credential Show) to SP: 1) When F AC receives the service request (sid, a = (a 1 , . . . , a q ), ϕ, P, SP) from a user U j with a pseudonym P, it creates a fresh qid and saves (qid, ϕ, SP, a, P). 2) F AC sends (sid, qid) to the simulator S and S sends it back to F AC to simulate the real-world communication between the user U j and the SP. 1) Unforgeability. F AC ensures that the attributes a = a 1 , . . . , a q that satisfy ϕ have to be validated by at least t V validators, i.e. at most one honest validator has to issue a partial credential. 2) Authenticity and Blindness. A validator never gets to see the attributes a = a 1 , . . . , a q and only learns that the attributes satisfy φ ensuring authenticity and blindness. 3) Optional Unlinkability. F AC does not impose any restriction on the value of the pseudonym when the user presents the credential to the SP which allows for optional unlinkability. If different pseudonyms are used then it provides unlinkability, else no. 4) Accountability and Unanimity. When at least a threshold number of openers agree, then the reqid is revealed by the F AC , thus providing accountability.
All the openers open to the same reqid which ensures unanimity.

B. REAL-WORLD PROTOCOL Π AC
We define the real-world protocol Π AC corresponding to the ideal functionality F AC . Π AC makes use of the following ideal functionalities: F KG for key generation of validators and key registration of openers, F BC for broadcasting messages, F AUT H for transmitting authenticated messages, F N YM for pseudonymous communication and F RO for random oracle functionality, to securely realize F AC in the hybrid-world. These ideal functionalities are described in more detail in Appendix B. We assume that every entity in the system implicitly queries F KG to retrieve the public keys of the validators and the openers. Π AC uses five types of storages: L U j ,REQ for each user U j to store the information in the credential request which is to be used later by U j after receiving the blind signatures from the validators, L V i ,REQ and L O k ,REQ for each validator V i and each opener O k , respectively, to store the successful credential requests, L ISS for each user to store the credentials, and L VER for the SP to store the service requests.

Setup:
1) A validator V i obtains their signing key pair (sk i , pk i ) and the public key pk for credential verification from F AC . 2) An opener O k generates its public-private key pair (opk k , osk k ) and requests F AC to register its public key.
3) The setup flag is set to true to indicate that all the validators and the openers have executed their setup initialization.

Credential request:
1) A user U j with attributes a = (a 1 , . . . , a q ) computes a commitment on the attributes, C a (Eq. 1). 2) The user U j then sends C a to F RO and receives H (Eq. 1), where F RO ensures that the validators agree on a common randomness H . 3) U j computes the commitment X j on the individual attribute a j (Eq. 2) which is used by the validators to blind sign the user attributes. 4) U j also computes the opening shares for the openers and encrypts the k-th opening share for each O k using the public key of the k-th opener(Eq. 5). 5) U j computes {H j,l }j ∈ [q], l ∈ [t O − 1] and π k to help verify the validity of the k-th encrypted opening share, U k (Eqs. 6, 7). 6) U j picks reqid where q is the number of attributes, o j is a blinding factor (Eq. 2) used in the commitment X j and is a tuple that contains the commitments and H .
, φ, reqid , P), a credential request, to F BC that sends the request to all the validators and openers.

8) Each validator V i and opener
where the set P convinces the validators that all the openers were sent the credential request. 9) They send C a to F RO and receives H .
REQ to indicate that the credential request has been successfully verified.

Credential issuance:
1) Each validator V i now has (sid, U j , reqid, C a , and unblindsσ i to σ i (Eq. 10). U j updates the entry (reqid, a, V ∪ (V i , σ i ), σ ) in L ISS , where V is initialized to ∅ and σ is initialized with ⊥. 5) If |V| ≥ t V , U j computes the credential σ using the AggCred method and σ i 's as input (Eq. 11) and updates the above entry to (reqid, a, V, σ ).

Update information of openers:
1) Each opener O k now has (sid, U j , reqid, H , 2) O k decrypts the k-th opening ciphertext U k to obtain µ k and appends its local registry as follows: Reg k [reqid] = µ k (see Eq. 9).

Presenting the credential (Credential Show) to SP:
1) U j now has a record (reqid, a, V, σ ) that contains the credential, σ . 2) U j randomizes the credential σ as σ and computes κ and ν (see ProveCred method in Sec. V-C). 3) U j generates the ZKPoK π v ( Eq. 13) that convinces the verifier of U j 's knowledge of the attributes a = (a 1 , . . . , a q ). 4) U j picks a pseudonym P and sends the service request ( σ , ϕ, κ, ν, π v , P, SP) to F N YM that sends the request to SP. 5) SP on receiving ( σ , ϕ, κ, ν, π v , P) from F N YM verifies σ using κ, ν and the public key of the validators, pk (Eq. 14). 6) If the ZKPoK π v is valid, SP picks a fresh vid to uniquely identify the credential presentation and records (vid, σ ) in L VER . Opening the credential: 1) Each opener O k is asked to revoke the anonymity of the user corresponding to the session given by vid.

C. SIMULATOR DESIGN
We design a simulator S which interacts with an adversary A that controls t O − 1 openers and t V − 1 validators. The simulator, S is an algorithm that simulates both the honest parties that interact with a real-world adversary, A and the ideal world adversary that interacts with the ideal functionality, F AC . We go on to show that the real-world adversary's view can be simulated by S. The honest entity interaction with other honest entities is captured by the ideal functionality F AC . We now describe the interaction between an honest entity and a corrupt entity. A simulator S does the setup by receiving the signing keys of the validators from F KG and generates the keys of the openers and registers the public keys of the openers with F KG . The corrupt entities (adversaries) collect their respective keys from the simulator S.
Honest U j requests a credential from a corrupt V i . When F AC sends (sid, qid) to S in the credential request, S sends (m, U j , P) to A, where m is the credential request message that the honest U j sends to the validators and the openers. When F AC sends (sid, reqid, φ, U j ) to a corrupt validator V i , S runs a copy of U j with the input (sid, a , φ) where a is either set to a, if U j stores a tuple (sid, a, o 1 , a 1 , . . . , a q , o , o 1 , . . . , o q ) stored such that C a = C a but (a 1 , . . . , a q ) = (a 1 , . . . , a q ), S outputs failure. 4) Otherwise, S stores the tuple (sid, reqid , a 1 , . . . , a q , o, o 1 , . . . , o q ) and sets  a ← (a 1 , . . . , a q ). 5) S sends (sid, a, φ) to F AC . When F AC sends (sid, qid), S sends (sid, qid) back to F AC .
Honest V i issues a credential to a corrupt U j . When F AC sends (sid, qid) during the credential issuance phase, S sends (m, U j ) to A, where m is the blind signature message that the honest V i sends VOLUME 10, 2022 to the user, U j . When F AC sends (sid, a, φ, V i ) to U j , S finds the stored tuple (sid, reqid , a 1 , . . . , a q , o, o 1 , . . . , o q ) with a = (a 1 , . . . , a q ). S computes the blind signatureσ i , stores the tuple (sid, a 1 , . . . , a q , φ, V i ) and sends the message reqid,σ i to A. Corrupt V i issues a credential to an honest U j . When an adversary A sends the message ( reqid,σ i , U j ), S runs F AUT H with that message. When F AU T H sends ( reqid,σ i , V i , U j )), S runs the copy of U j with reqid. When the copy of U j outputs (sid, a, φ, V i ), S sends (sid, U j , reqid) to F AC . When F AC sends (sid, qid), S forwards it to F AC . Honest U j shows a credential to a corrupt SP. When F AC sends (sid, qid), S leaks the length of m to A, where m = σ , ϕ, κ, ν, π v is the message sent by an honest U j to SP. When F AC sends (sid, ϕ, vid, P) to a corrupt SP, S sets the message to be sent to A as follows.
When an adversary A sends the message ( σ , ϕ, κ, ν, π v , P, SP), S runs F N YM on that message. When F N YM leaks the length of the tuple, l( σ , ϕ, κ, ν, π v ), S forwards it to A. When F N YM sends ( σ , ϕ, κ, ν, π v , P, SP), S verifies σ and the proof π v and proceeds as follows.
1) S runs the extractor algorithm to extract the witness (a 1 , . . . , a q , r) from the proof π v . 2) S parses σ as (H , S ) and runs the verification equation e(H ,α + q j=1 a jβj ) = e(S ,G). If the verification fails, S outputs failure.  Proof: We show through a series of hybrid games that the environment Z cannot distinguish the real world from the ideal world. We denote the probability that Z distinguishes Game i from the real-world protocol as Pr[Game i].
Game 1: This game proceeds as Game 0, except that Game 1 runs the extractors for the non-interactive proofs of knowledge π s , {π k } k∈[n O ] and π v . Under the weak simulation extractability property of NIZK proof system, we have that |Pr[Game 1] − Pr[Game 0]| ≤ Adv ext A , where Adv ext A represents the adversary's advantage of breaking the weak simulation extractability property. Weak simulation extractability [1] implies that if an adversary generates a new NIZK proof which it has not seen previously then the extractor, an efficient algorithm, can extract the witness. That is, an adversary cannot generate new proof unless he knows a witness.
Game 2: This game proceeds as Game 1, except that Game 2 outputs failure if two request messages were received with commitments C a and C a , and proofs π s and π s such that C a = C a but after extraction of the witnesses from π s and π s , (a 1 , . . . , a q ) = (a 1 , . . . , a q ). Under the binding property of the commitment scheme, we have that |Pr[Game 2] − Pr[Game 1]| ≤ Adv bin A , where Adv bin A represents the adversary's advantage of breaking the binding property.
Game 3: This game proceeds as Game 2, except that, after extracting the witness (a 1 , . . . , a q , r) from the proof π v , Game 3 outputs failure if σ is not a valid signature. But σ is always a valid PS signature on (a 1 , . . . , a q ) and thus where Adv unf A represents the adversary's advantage of forging the PS signatures in the RO model (see [32,Th. 4]).
These values follow the same distribution as the ones computed by the honest user in the real-world protocol. Therefore, we have that |Pr[Game 8] − Pr[Game 7]| = 0.
Game 9: This game proceeds as Game 8, except that Game 9 outputs failure if the openers either do not output a reqid or output more than one reqid.
Case 1: If the openers do not open the credential to any reqid, it implies the openers do not have the corresponding shares to open the credential. As every genuine credential request is issued by honest validators and the corresponding opening information is stored by the openers, the user must have used a credential that was not issued by honest validators.
Case 2: If the openers open a credential to multiple reqid's, it implies the opening shares satisfy attributes of multiple sessions. As every credential is identified by a unique set of attributes, the adversary to succeed should generate a new signature (m , σ ), given the message-signature pair (m, σ ). Therefore, in both cases, the distinguishable probability of Game 9 from Game 8 is the advantage of the adversary winning a forgery game. Under the unforgeability property of PS signatures in the random oracle model, we have that A represents the adversary's advantage of forging the PS signatures in the RO model.

VII. IMPLEMENTATION
DTRAC uses the Ethereum blockchain for a tamper-resistant ledger. Table 1 shows the details of the experimental setup of our PoC implementation using Ganache, a private blockchain node for Ethereum application development. The smart contract library is implemented using Solidity v0.5.16. The client uses web3.py as the Python interface to interact with the blockchain. The underlying cryptographic elliptic curve library used is py_ecc due to its support of alt_bn128, a type III pairing curve available on Ethereum through a precompiled contract.

A. SMART CONTRACT DEPLOYMENT
The smart contracts in Ethereum have a limitation that their maximum size has to be 24KB, beyond which it runs out of gas. DTRAC, therefore, uses five smart contracts -Params, Request, Issue, Verify, and Opening -to support all the required functionalities. The smart contracts Params, Request, and Issue are deployed by the validators, Verify is deployed by the SP, and Opening is deployed by the openers. The Params smart contract stores the public keys of the validators, certifiers, and openers, and can be accessed by other smart contracts. A credential request is made by the user through the Request smart contract using the RequestCred method that verifies the credential request. As the credential request is verified using a smart contract method and not done off-chain, only genuine credential requests are sent to the validators and the BlindSign method need not verify the ZKPoK of the credential request. The validators send the blind signature to the user through the Issue smart contract using the SendBlindSign method. The Verify smart contract allows all the blockchain nodes to verify the service request of the user using the VerifyCred method. In the opening phase, each opener sends the opening information to the other openers through the SendOpeningInfo method of the Opening smart contract.

B. OPTIMIZATIONS
The precompiled smart contract in EVM 1 that performs pairing checks and elliptic curve operations on alt_bn128, does not support addition and scalar multiplications inG, where (p, G,G, G T , e) is the bilinear group that we use in our scheme. Coconut has implemented a smart contract library for these operations, but it is computationally expensive and impractical on Ethereum due to the block gas limit. In our scheme, a scalar multiplication inG is replaced with a scalar multiplication in G and a pairing check, all of which consume less gas. For instance, let G ∈ G,G ∈G and r be randomly chosen from Z p . Instead of calculating rG on the smart contract, R = rG and r are given as inputs to the smart contract so that it can verify e(G, R) = e(rG,G) to confirm whether R = rG or not. This reduces the gas cost at the expense of increasing the input size.

C. MITIGATING POTENTIAL ATTACKS
Ethereum transactions are vulnerable to replay attacks and an adversary can access the service by replaying the transaction. To mitigate this we use a timestamp as a public input in the ZKPoK generation as part of the ProveCred method. Our scheme is secure against Sybil attacks because the Vcerts are linkable. A man-in-the-middle attack will not succeed because it is almost impossible for an eavesdropper to generate a valid ZKPoK for a fresh randomized signature. DDoS attacks are possible but expensive because of the Ethereum transaction fee. Impersonation attacks are possible if the certifier is malicious but difficult in the multi-certifier model with honest certifiers. We describe these attacks in detail in Appendix C.

D. PoC IMPLEMENTATION
The feasibility of DTRAC is validated by considering the loan use case described in Sec. IV-E. Table 2 depicts the parameters configured for the loan use case. The certifiers, IdP and the employer provide an ID Vcert and an income Vcert, respectively. The user has to obtain the credential on a subset of attributes such as name and DoB from the set of identity attributes and income from the income Vcert. We consider four distributed validators and four distributed openers over the Ethereum blockchain with the threshold parameter set to three for both.

VIII. EVALUATION
The experiments were performed on Ubuntu Linux LTS 20.04 desktop computer with an Intel Xeon W-2133 CPU@3.60 GHz processor having 6 cores, 12 threads and 32GB RAM. We use the following two metrics to measure the performance overhead. 1) Gas refers to the fee to be paid by a user when executing a transaction on the Ethereum blockchain and it depends on the complexity of the operations involved. Every block in Ethereum has a gas limit (30M as of May 2022) which determines the number of transactions in a block. 2) Execution time refers to the time required to run each off-chain method in our system. We evaluated our system for the loan application use case and bench-marked a) the deployment gas costs for the five smart contracts, b) the average gas costs for the execution  of the smart contract methods, and c) the average execution times of the cryptographic primitives of all the four phases. Table 3 depicts the deployment gas consumption of Params, Request, Issue, Verify and Opening smart contract, deployed on a Ganache private node and also gives details of who pays for the deployment gas cost. This deployment is done only once for the loan application use case. Ideally, all the validators should collectively pay the gas fee for deploying the Params, Request and Issue smart contracts and all the openers should collectively pay for deploying the Opening smart contract, but the current implementation allows only one of the validators and one of the openers to pay the fee.

B. EXECUTION OVERHEAD OF CRYPTOGRAPHIC PRIMITIVES
Tables 4, 5, 6 and 7 depict the average execution time of the cryptographic primitives involved in various phases of the system over 20 iterations. Table 4 depicts the execution times of cryptographic primitives in the registration phase for the ID Vcert and income Vcert requests. One can see that there is a large gap between the execution times of GenZKPoK and VerifyZKPoK of the ID Vcert and income Vcert. This is due to the additional overhead for the employer in verifying the ID Vcert in zero-knowledge. Tables 5 and 6 measure the excecution times for the issuance and verification phase, respectively. In Table 5, the aggregation time measures the time to aggregate three partial credentials. For the opening phase, Table 7 shows the average execution time of comparing a credential against each record in the opener's registry. The execution time grows linearly with the number of users as the opener has to check the credential against all the reqid's in the system until he finds the correct user. Table 8 depicts the average gas consumption for the execution of smart contract methods over 20 iterations. For measuring the average gas consumption of the SendOpeningInfo method we consider the broadcasting of opening information of a single user/record in the opener's registry and this increases linearly with the number of users/records.   We have evaluated how the gas consumption of the RequestCred method varies with the number of openers, certifiers and attributes and how that of the VerifyCred method varies with the number of disclosed attributes. This evaluation is based on a set of random attributes and we give our observations below.
• Number of openers vs Gas consumption. Fig. 11 depicts how the gas consumption of the RequestCred method increases linearly with the increase in the number of openers. Here we consider 2 certifiers, 4 validators and 4 openers with the threshold value set to 3 for both, 3 attributes in the credential and 3 attributes to be verified by each certifier. We observe that the mean is greater than the median and is close to the minimum gas consumption. i.e., for most of the transactions, the gas costs lie close to the minimum value.
• Number of attributes vs Gas consumption. Fig. 12 depicts how the gas consumption of the RequestCred method increases linearly with the increase in the number of attributes on which the credential is requested.
In this setup, we consider 2 certifiers, 4 validators and 4 openers each with the threshold value set to 3 for both and 3 attributes to be verified by each certifier. We observe that the mean is greater than the median and is close to the minimum gas consumption. i.e., for most transactions, the gas costs lie close to the minimum value.
• Number of certifiers vs Gas consumption. Fig. 13 depicts how the gas consumption of the RequestCred method increases with the increase in the number of certifiers.
In this setup, we consider 4 validators and 4 openers each with the threshold value set to 3 for both, 6 attributes for the credential request and 3 attributes to be verified by each certifier. We observe that the mean is greater than the median and close to the minimum gas consumption inferring that in most of the transactions the gas costs lie close to the minimum value.
• Number of disclosed attributes vs Gas consumption.     in the number of disclosed attributes. In this setup, we vary the number of disclosed attributes from 1 to 5 by keeping the number of attributes in a credential fixed, equal to 5. We observe that the standard deviation of the distribution of the gas consumption is very low. i.e., for most of the transactions the gas costs lie close to the mean.

C. COMPARISON WITH MULTIPLE COCONUT INSTANCES
We consider a service request that requires the user to present a credential, with multiple attributes certified by different certifiers, to a service provider. To achieve this functionality using the Coconut scheme, the user has to present multiple credentials, one corresponding to each certifier, to the service provider, which implies running multiple instances of the Coconut scheme. However, in DTRAC, the user has to present only one credential to the SP. Note that within the same instance, the verification process is the same for both DTRAC and the Coconut scheme. We present a detailed evaluation and comparison of the gas costs and execution times of the verification process of running one instance of DTRAC versus running multiple instances of Coconut for a) the loan application use case described in Sec. IV-E, and b) three scenarios we custom build: Scenario 1: two certifiers each attesting three randomly generated attributes, Scenario 2: three certifiers each attesting three random attributes, and Scenario 3: four certifiers each attesting three random attributes. The gas costs are compared when the service request is verified on-chain using smart contracts and the execution times are compared when the SP verifies the service request off-chain. For any service request, credential verification typically involves verifying 1) the signature of the validators on the credential (Eq. 14), and 2) the ZKPoK of the correctness of the undisclosed attributes (Eq. 13). From Fig. 15, it is clear that DTRAC consumes significantly less gas to verify the service request compared to multiple instances of Coconut on the Ethereum blockchain. To understand why, we need to first understand how the verification of a service request happens over Ethereum. For a type III bilinear pairing group, (p, G,G, G T , e), as explained in Sec. VII-B, the precompiled contracts in Ethereum do not support operations inG, and we have to replace them with operations in G followed by a pairing check. This occurs in both the steps -signature verification and ZKPoK verification -of the service request verification. When we run multiple instances of Coconut, the two steps of verification, with the corresponding G operations and pairing checks, are performed for every instance, whereas in DTRAC, they are done only once. If we increase the number of instances by keeping the total number of attributes constant (which means we have more certifiers attesting the attributes), then the number of pairing operations and, accordingly, the ratio of the gas costs increase linearly. Fig. 16 depicts that off-chain too the situation is similar -DTRAC takes significantly less execution time than Coconut to verify a service request of a credential that has attributes attested by multiple certifiers. This is again due to the pairing check operation, which is computationally intensive. Since DTRAC always has to verify only one credential, irrespective of the number of certifiers that attest to the attributes, it executes much faster than Coconut, which has to verify multiple credentials. Both the results show that DTRAC is more scalable as opposed to having multiple instances of Coconut and the performance gain increases linearly with the number of instances. Note that during the issuance phase when we have multiple certifiers attesting to multiple sets  of attributes, the execution time of DTRAC is more since multiple Vcerts corresponding to each certifier have to be issued. But credential issuance typically happens only once per application while verification of a credential happens more frequently.

D. LIMITATIONS
The main limitation with implementing DTRAC on Ethereum using smart contracts is that it is very expensive in terms of gas costs mainly because DTRAC requires several cryptographic operations in an elliptic curve pairing group. Even though there are pre-compiled smart contracts for elliptic curve pairing groups, they do not support operations in G 2 which are needed for asymmetric pairings used in DTRAC, and this is the main bottleneck.

IX. RELATED WORK
'Anonymous credentials' was first coined by D.Chaum [15]. Idemix [4], based on CL signatures [12], is a well-known AC scheme but its size increases linearly with the number of attributes. PS signatures [30] resolves this issue with credentials that are constant and short-sized irrespective of the number of attributes involved. Garman et al. [20] addresses the limitation of a single trusted credential issuer by introducing decentralized anonymous credentials (DAC) where the issuance of credentials happens through a distributed ledger. It is computationally expensive due to its large proof size. Crypto-Book [26] provides threshold issuance of credentials but requires verification of t signatures, where t is the threshold parameter, by the service provider. Also, Crypto-Book is limited to identity authentication. The Coconut scheme [35]  has a short-sized credential scheme and also supports threshold PS signatures over blockchains. But in the multi-certifier model, Coconut resorts to issuing multiple credentials and as we saw before that makes credential verification expensive. Versatile ABS scheme [3] supports multiple attribute providers, but, just like Coconut, provides multiple credentials on user attributes attested by different providers making credential verification expensive. CanDID [27] has the same goal as this work but uses a different approach -the user is given a master credential using a decentralized mechanism from legacy credential systems, such as government identity providers, banks, etc. But it does not support threshold issuance.
There are several AC works [8], [11], [27], [37], [39], [40] that focus on credential revocation as opposed to anonymity revocation which is what DTRAC does. For example, CanDID refers to and matches the credential with a public revocation list using secure MPC techniques with fuzzy matching which are computationally intensive. An identity escrow scheme [24] allows the identity to be revealed by a trusted opener, but not all AC schemes support this, and typically the openers in such schemes are not distributed [10], [11]. Versatile ABS scheme [3] supports threshold opening of an anonymous credential, but in this scheme, every service request needs to contain additional opening information which makes credential verification inefficient. DTRAC enables anonymity revocation through a distributed set of openers in which less than a threshold number of openers can be corrupt. Table 9 gives a comparison of DTRAC with other anonymous credentials w.r.t. key features such as blindness, unlinkability, threshold issuance of credentials, threshold opening of credentials, multi-certifier communication model and support for multiple attributes in a credential.

X. CONCLUSION
We propose a decentralized threshold revocable anonymous credential scheme (DTRAC) that enables threshold credential issuance to support a multi-certifier communication model, i.e. having multiple certifiers validate disjoint sets of user attributes. To this threshold issuance scheme we integrate, for the first time, a threshold opening scheme that allows for the opening of a credential with multiple user attributes. We give a formal security analysis of this integration in the UC framework. We also provide a PoC implementation of our scheme over the Ethereum blockchain, making it the first threshold issuance scheme over Ethereum. We also present a detailed evaluation of the performance to show the feasibility of our scheme. We show that DTRAC significantly reduces the credential verification cost for the service provider and is more scalable than the state-of-the-art threshold issuance scheme, Coconut.
The limitation of DTRAC implementation discussed in Sec. VIII-D can be mitigated by moving some of the computations involving elliptic curve operations from smart contracts to off-chain. This will need changes to the architecture of DTRAC and we will also need to show that this does not weaken the security guarantees. We are, currently, exploring this direction. We defer some important features to the future such as restricting credential usage to support applications where a credential cannot be used indefinitely, credential revocation to mitigate anonymous abuse, integration of anonymous payments to DTRAC, and dynamic inclusion and exclusion of validators or openers into the system.

APPENDIX A BACKGROUND
Here we review the necessary background information for the protocols described in Sec II-D and II-E.

A. BILINEAR GROUPS
The advent of pairings-based cryptography (PBC) [5], [22] led to short, efficient signatures with many versatile features. The randomizable signatures mentioned in Sec. II-D -PS signatures -rely on bilinear pairings, and we give an overview of the concept here.
Definition 1 (Bilinear Group): Let G,G and G T be cyclic groups of prime order p. A bilinear map e is a function e : G ×G → G T , satisfying the following properties. 1) Bilinearity. For all P ∈ G, Q ∈G and a, b ∈ Z p , e(aP, bQ) = e(P, Q) ab . 2) Non-degeneracy. For all P ∈ G, Q ∈G such that P = 1 G , Q = 1G and e(P, Q) = 1 G T . 3) Computability. The map e is efficiently computable. A bilinear group is the set comprising of G,G, G T along with e that satisfies the above properties.
There are three types of pairings, and they differ in the structure of the underlying groups [18]. They are namely, type I where G =G; type II where G =G but there exists an efficiently computable homomorphism, φ between G andG; and type III where G =G and there is no efficiently computable homomorphism between G andG in either direction. Type I pairings were used in the older PBC schemes and have now been mostly replaced by type III pairings because they are more efficient and are compatible with several computational hardness assumptions such as the decisional Diffie-Hellman assumption in G orG called the XDH assumption [6].
There are two versions of PS signatures. The security of the earlier version relies on the PS assumption to prove the EUF-CMA security of the scheme, which is an interactive assumption [30]. Due to rising concerns about interactive assumptions in the cryptographic community, the authors reassessed the security assumptions and slightly modified the signature scheme so that the security relies on q-type (q-MSDH) assumptions [31]. The earlier version of PS signatures is EUF-wCMA under the q-MSDH assumption, but the later version is EUF-CMA secure under the q-MSDH assumption. The Coconut threshold issuance scheme uses the earlier version of PS signatures.

B. SHAMIR SECRET SHARING
A secret sharing scheme, introduced by Shamir [34], is used to secure a secret in a distributed manner. In (t, n)-Shamir secret sharing, the original secret is split into n shares, out of which t or more shares are needed to reconstruct the secret. It is based on polynomial interpolation over finite fields. It satisfies the following two properties.

1)
Recoverability. The secret can be reconstructed efficiently with the knowledge of at least t shares. 2) Secrecy. The secret is completely undetermined without the knowledge of at least t shares.
To generate the Shamir shares of a secret m ∈ Z p , we first generate a polynomial P of degree t − 1 whose coefficients are chosen randomly from Z p (see Eq. 3). The n shares, called Shamir shares, are generated by evaluating the polynomial at values 1 to n as s i = P(i), i ∈ [n]. Later any t of those shares can be used to reconstruct the original secret m using Lagrange coefficients. Let T be the set of indices of the shares which are used in the reconstruction protocol. Then the original secret can be reconstructed using j∈T w j s j , where w j is the j-th Lagrange coefficient (see Eq. 12). The Shamir secret sharing scheme is used twice in our proposed scheme: 1) the key generation phase of the threshold PS signature scheme (Sec. II-D) and 2) the generation of opening information (Sec. V-D).

APPENDIX B IDEAL FUNCTIONALITIES
In this section we present a brief overview of the ideal functionalities that are required to analyze the security of our scheme. ) to the simulator S and the party P.
The F KG described above is different from F KG in [32] in one way -here, along with the key generation of the validators, the openers register their public keys as well.
2) Ideal Functionality, F BC : The ideal functionality F BC supports an ideal authenticated broadcast message transmission. When a sender T sends (sid, m, R), where m is the message and R is a set of receivers, to F BC , it sends (sid, m, T , R) to the simulator S and all the entities in the set R. F BC is different from the F BC in [19] in the following way: here, along with the message m, the information regarding who are the receivers, i.e. elements of R, are also sent to all the receivers. 3) Ideal Functionality, F N YM : The ideal functionality F N YM [32] supports a secure idealized pseudonymous communication.

Sending a message:
When a sender T sends (sid, m, P, R), where m is the message, P is a pseudonym, and R is a receiver to F N YM , it leaks the message length to S to capture the information that is leaked during the communication between T and R, and sends (sid, m, P) to R. F N YM hides the sender T from the receiver R. Replying with a message: When R replies with (sid, m, R, P) to F N YM , it leaks the message length to the simulator S for the same reason and sends (sid, m, P) to T .

4) Ideal Functionality, F AU T H :
The ideal functionality F AU T H [14] supports an ideal authenticated message transmission. When a sender T sends (m, R), where m is the message and R is a receiver, to F AU T H , it sends (m, T ) to the simulator S and the receiver R.

APPENDIX C ATTACK MODEL
In order to demonstrate the security of the proposed scheme, we determine the capabilities and possible actions of an adversary. We consider the following attacks that lead to privacy leakage, credential misuse, service unavailability, etc. 1) Impersonation Attack. A certifier receives all the user attributes in the registration phase. A malicious certifier can make a new Vcert using these attributes and impersonate a user, and this cannot be prevented in our scheme. But if more than one certifier is required to issue an anonymous credential, this attack is unlikely as the malicious certifier will have to obtain valid Vcerts from all the other certifiers to be able to impersonate the user. Thus impersonation attacks can be mitigated in the proposed multi-certifier model. 2) Man in the Middle Attack. An adversary can eavesdrop on service requests over a blockchain which means the adversary has access to the randomized credential and the ZKPoK of the user's private data. Although an adversary can succeed in creating a new randomized signature from this information, he cannot generate a new ZKPoK corresponding to the fresh signature. 3) Sybil Attack. A user can request multiple credentials in an attempt to construct fake credentials. But as the certifier verifies each user before providing a Vcert and the Vcerts are linkable, such fake credential requests will be detected by the scheme. 4) Denial of Service Attack. Our scheme allows a user to request service as many times as she wants and this can be used by an adversary to cause a system shutdown. But Ethereum's transaction fees ensure that such an attack will be expensive. 5) Replay Attack. Since the requests to the SP are through the blockchain, the transaction data can be replayed and an adversary can gain access to the service. This attack can be prevented by adding a timestamp to the ZKPoK associated with the service request. This timestamp expires after a certain window and this window is determined by the SP [17]. The smart contract performs the proof execution only if the request is within this time period.

APPENDIX D ASYMPTOTIC ANALYSIS OF PHASES
We provide an asymptotic analysis of our scheme, with respect to the number of attributes, number of validators and number of openers. Table 9 depicts an analysis of the registration phase as a function of the number of attributes verified  by each certifier, given by attr. Note that the analysis of the GenZKPoK and VerifyZKPoK methods are done assuming that the certifiers are independent. If a certifier requires that the ZKPoK of attributes of other Vcerts have to be verified then the complexity increases linearly with the number of attributes in the corresponding Vcerts. Table 10 depicts the complexity analysis of the other phases as a function of the number of openers n O , the number of validators n V and the total number of attributes verified by all the certifiers, say total attr . The complexity of the PreOpening and OpenCred methods are for a single credential and it increases linearly with the number of users.