Aisling Connolly
email: aislingmconnolly@gmail.com

Jerome Deschamps
email: jerome.deschamps@etu.uca.fr

Pascal Lafourcade
email: pascal.lafourcade@uca.fr

Octavio Perez -4459-511x]

Kempner

Protego: Efficient, Revocable and Auditable Anonymous Credentials with Applications to Hyperledger Fabric

Keywords: Anonymous Credentials, Auditability, Hyperledger Fabric, Mercurial Signatures, Permissioned Blockchains

Recent works to improve privacy in permissioned blockchains like Hyperledger Fabric rely on Idemix, the only anonymous credential system that has been integrated to date. The current Idemix implementation in Hyperledger Fabric (v2.4) only supports a fixed set of attributes; it does not support revocation features, nor does it support anonymous endorsement of transactions (in Fabric, transactions need to be approved by a subset of peers before consensus). A prototype Idemix extension by Bogatov et al. (CANS, 2021) was proposed to include revocation, auditability, and to gain privacy for users. In this work, we explore how to gain efficiency, functionality, and further privacy, departing from recent works on anonymous credentials based on Structure-Preserving Signatures on Equivalence Classes. As a result, we extend previous works to build a new anonymous credential scheme called Protego. We also present a variant of it (Protego Duo) based on a different approach to hiding the identity of an issuer during showings. We also discuss how both can be integrated into Hyperledger Fabric and provide a prototype implementation. Finally, our results show that Protego and Protego Duo are at least twice as fast as state-of-the-art approaches based on Idemix.

Introduction

When first introduced, the core use of blockchains was in the permissionless setting; anyone could join and participate. Over the years, blockchains have ⋆ Work done while the author was at Wordline Global. also found use within consortiums, where several authorized organizations wish to share information among the group, but not necessarily to the public as a whole. This need gave rise to permissioned blockchains whereby authorities are established to define a set of participants. When a federation of authorities (consortium), each in control of a subset of participants, shares the blockchain's governance, the term federated is also used to describe such blockchains.

The use of federated blockchains increased to address the need to run a common business logic within a closed environment. As an example, one can consider pharmaceutical companies that would like to trade sensitive information about product developments and agree on supplies or prices in a consortium with partial trust. A recurrent problem in such scenarios is that of privacy while being compliant with regulations and Know Your Customer practices. Agreeing with other entities to run a shared business logic should not imply that everything needs be public within the consortium. Privacy still needs to be provided without affecting existing regulations, e.g., when considering bilateral agreements.

The most developed permissioned platform is Hyperledger Fabric (or simply Fabric). In Fabric, users submit transaction proposals to a subset of peers (called endorsers) that vouch for their execution. By default, it provides no privacy features as everything (users and transactions) is public. Reading the blockchain anyone can know (1) who triggered a smart contract using which arguments (transaction proposals are signed by the clients), [START_REF] Androulaki | Privacy-preserving auditable token payments in a permissioned blockchain system[END_REF] who vouched for its execution (endorsers also sign their responses) concerning reading and writing sets; and (3) why a given transaction was marked as invalid (either because of invalid read/write sets or because the endorsement policy check failed). Furthermore, checking access control and endorsement policies links different organizations, users and their attributes to concrete actions on the system.

Such limitations severely restrict the use of Fabric. From the user perspective this impacts the enforcement of different regulations. For organizations, the case is similar. Consider a consortium of pharmaceuticals that run a common business logic to exchange information on medical research. If the entity behind a request is known, other organizations can infer (based on the request) which drug the entity in question is trying to develop. If the endorsers are known, information about who executes what can disclose business relations.

Motivated by the need to protect business interests and to meet regulatory requirements, some privacy features were integrated using the Identity Mixer [START_REF] Camenisch | Design and implementation of the idemix anonymous credential system[END_REF][START_REF] Zurich | Specification of the identity mixer cryptographic library v2[END_REF] (or Idemix for short). This anonymous attribute-based credential (ABC) scheme gave the first glimpse of privacy for users within a consortium. Idemix allows a Membership Service Provider (MSP) to issue credentials enabling users to sign transactions anonymously. In brief, users generate a zero-knowledge proof attesting that the MSP issued them a credential on its attributes to sign a transaction. Fabric's support for Idemix was added in v1.3, providing the first solution to tackle the problem of participant privacy. Unfortunately, as for v2.4 the Idemix implementation still suffers severe limitations:

1. It supports a fixed set of only four attributes. 2. It does not support revocation features.

3. Credentials leak the MSP ID, meaning that anonymity is local to users within an organization. For this reason, current deployments can only use a single MSP for the whole network, introducing a single point of failure. 4. It does not support the issuance of Idemix credentials for the endorsing peers, meaning that the identity of endorsers is always leaked. The most promising effort to extend the functionality of Idemix appeared in [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]. Their aim was to extend the original credential system to support delegatable credentials [START_REF] Camenisch | Practical UC-secure delegatable credentials with attributes and their application to blockchain[END_REF], while integrating revocation and auditability features (solving three of the four limitations). Below we outline the main ideas introduced in [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF].

Delegatable Credentials. In a bid to overcome the issue of Idemix credentials leaking the MSP ID and thus the affiliation of the user, a trusted root authority provides credentials to intermediate authorities. This way users can obtain credentials from intermediate authorities. To sign a transaction, the user must generate a zero-knowledge proof attesting that (1) the signer owns the credential; (2) the signature is valid; (3) all adjacent delegation levels are legitimate; and (4) that the top-level public key belongs to the root authority.

Revocation and Auditability. To generate efficient proofs of non-revocation, the system timeline is divided into epochs. Issued credentials are only valid for a given epoch, and must be reissued as the timeline advances. For each epoch, a user requests a revocation handle that binds their public key to the epoch. When presenting a credential, the user also provides a proof of non-revocation. To enable auditing of a transaction, users verifiably encrypt their public key under an authorized auditor's public key.

To date, some functionalities remain limited. (1) There is still no notion of privacy for endorsers. (2) Delegatable credentials require proving knowledge of a list of keys. (3) The root authority is still a single point of failure. (4) Selective disclosure of attributes requires computation linear in the size of all the attributes encoded in the credential. (5) Many zero-knowledge proofs need to be generated for each transaction. [START_REF] Bobolz | Issuer-Hiding Attribute-Based Credentials[END_REF] Many pairings need to be computed for verification.

Recent results [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF][START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF][START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] introduced newer models based on Structure-Preserving Signatures on Equivalence Classes (SPS-EQ) to build ABC's, providing a host of extra functionalities and more efficient constructions. The main goal of this work is to leverage such results, position them in the blockchain scenario and provide an alternative to Idemix (and its extension) to overcome existing privacy and functional limitations while also improving efficiency.

Contributions.

To build an ABC scheme that overcomes the inherent limitations from Idemix and its extension, we argue that changing some of the underlying building blocks is necessary. Therefore, we take the framework from [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF] as our starting point, incorporate the recent improvements from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF], and include the revocation extension originally proposed in [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF]. From there, we extend the ABC model to support auditability features and adapt it to non-interactive showings. To do so, we rely on the random oracle model (already present in the blockchain setting). We also present and discuss two alternatives to the use of delegatable credentials (as used in [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]) to hide the identity of credential issuers, following the formalizations from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] and [START_REF] Bobolz | Issuer-Hiding Attribute-Based Credentials[END_REF] but using new approaches.

When compared to [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF], the modifications are: (1) we adapt the ABC model to non-interactive showings, (2) we extend the model defining a revocation authority as in [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF], and an auditing authority (not considered in the previous works), [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] we keep the SCDS scheme from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] as it is but replace the signature scheme with the one given in [START_REF] Crites | Delegatable anonymous credentials from mercurial signatures[END_REF], and (4) we build a malleable NIZK argument that can be pre-computed to obtain a more efficient issuer-hiding feature.

As a result, we build Protego, an ABC suitable for permissioned blockchains. We also present Protego Duo, a variant based on a different approach to hide the identity of credential issuers. Both support revocation and auditing features, which are important to enable a broader variety of use cases for permissioned blockchains. We discuss how to integrate our work with Fabric, compare it with Idemix and its recent extensions, and provide a prototype implementation showing that Protego and Protego Duo are faster than the most recent Idemix extension (see Section 5 for a detailed evaluation and benchmarks). Furthermore, a showing proof in Protego Duo is constant-size (8.3 kB), surpassing [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF] in which the proof size grows linearly with the number of attributes and delegation levels.

Related work. We describe the related work following two main streams; the results addressing privacy concerns in Fabric, and parallel research developments.

Privacy concerns in Fabric. The most closely related work appears with the introduction of Idemix [START_REF] Camenisch | Design and implementation of the idemix anonymous credential system[END_REF][START_REF] Zurich | Specification of the identity mixer cryptographic library v2[END_REF] and its extension to include revocation and auditability [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]. Adding auditability is crucial for permissioned blockchains as they are often used in heavily regulated industries. Privacy-preserving auditing for distributed ledgers was introduced in [START_REF] Narula | Zkledger: Privacy-preserving auditing for distributed ledgers[END_REF] under the guise of zkLedger. This general solution offered great functionality in that it provided confidentiality of transactions, and privacy of the users within the transaction. However, it assumed low transaction volume between few participants and as such is quite limited in scalability. Fabric-friendly auditable token payments were introduced in [START_REF] Androulaki | Privacy-preserving auditable token payments in a permissioned blockchain system[END_REF] and were based on threshold blind signatures. The core idea to achieve auditability was to encrypt the user's public key under the public key of an auditor. This is the same approach in [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF], which we also use in this work. Although the auditing ideas are similar, the construction pertains solely to transaction privacy and offers no identity privacy for a user. Following the approach of gaining auditability of transactions, auditable smart contracts were captured by FabZK [START_REF] Kang | Fabzk: Supporting privacypreserving, auditable smart contracts in hyperledger fabric[END_REF] which is based on Pedersen commitments and zero-knowledge proofs. To achieve auditability, the structure of the ledger is modified, and as such, would need to make considerable changes to existing used permissioned blockchain platforms.

One of the limitations in Idemix and its extension is the lack of privacy or anonymity for endorsing peers. A potential solution to this was proposed in [START_REF] Mazumdar | Design of anonymous endorsement system in hyperledger fabric[END_REF], where the endorsement policy is based on a ring signature scheme such that the endorsement set itself is not revealed, but only that sufficiently many endorsement signatures were obtained. Another approach to obtain privacy-preserving endorsements was described in [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF], leveraging Idemix credentials to gain endorser-privacy, and as such, inherits the limitations (notably leaking the endorser's organization) that come with Idemix.

Attribute-based credentials. Early anonymous credential schemes were built from blind signatures, whereby a user obtained a blind signature from an issuer on the user's commitment to its attributes. When the user later authenticates, they provide the signature, the shown attributes, and a proof of knowledge of all unshown attributes. These schemes are limited as they can only be shown once. Subsequent work like the one underlying Idemix [START_REF] Camenisch | Signature schemes and anonymous credentials from bilinear maps[END_REF] allowed for an arbitrary number of unlinkable showings. A user obtains a signature on a commitment on attributes, randomizes the signature, and proves in zero-knowledge that the randomized signature corresponds to the shown and unshown attributes.

Recent work from [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF] circumvented inefficiencies in the above ideas by coining two new primitives: set-commitment schemes, and SPS-EQ. As a result, authors obtained a scheme allowing to randomize both the signature and the commitment on a set of attributes. Furthermore, a subset-opening of the setcommitment yielded constant-size selective showing of attributes.

New work from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] extended [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF], improving the expressivity, efficiency trade-offs and introducing the notion of signer-hiding (also known as issuerhiding [START_REF] Bobolz | Issuer-Hiding Attribute-Based Credentials[END_REF]) to allow users to easily randomize the public key used to generate a signature to hide the identity of credential issuers. Authors achieve the previous points using a Set-Commitment scheme supporting Disjoint Sets (SCDS) and mercurial signatures [START_REF] Crites | Delegatable anonymous credentials from mercurial signatures[END_REF]. The latter primitive extends SPS-EQ to consider equivalence classes not only on the message space but also on the key space.

We build on top of the above-mentioned works but unlike [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF], we work with the generic group model [START_REF] Shoup | Lower bounds for discrete logarithms and related problems[END_REF] as our main motivation is the proposal of efficient alternatives. For this reason, we use the mercurial signature scheme from [START_REF] Crites | Delegatable anonymous credentials from mercurial signatures[END_REF].

Cryptographic Background

Below, we walk through the different building blocks mentioning how and why these components yield greater functionality and efficiency for a credential system in the permissioned blockchain setting like Fabric. Subsequently, we introduce the necessary notation and syntax for the following sections.

SCDS.

Using commitment schemes that allow to commit to sets of attributes enables constant-size openings of subsets (selective disclosure) of the committed sets. These schemes support commitment randomization without the need to rely on zero-knowledge proofs of correct randomization, as the corresponding witness for openings can be adapted accordingly with respect to the randomization of the committed set. The set-commitment scheme presented in [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] extends [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF] to support openings of attribute sets disjoint from the committed set. This is particularly useful in the permissioned blockchain setting, e.g., to model access control policies. Furthermore, the scheme from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] also supports the use of proof of exponentiations to outsource some of the computational cost from the verifier to the prover. In the case of Fabric, this is a particularly interesting feature to make the endorser's verification faster when validating a transaction proposal.

Mercurial Signatures. The introduction of SPS-EQ in [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF] allowed to adapt a signature on a representative message to a signature on a different representative (in a given equivalence class) without knowledge of the secret key. If the adapted signature is indistinguishable from a fresh signature on a random message, the scheme satisfies the notion of perfect adaption. This, together with the randomizability of the set-commitment scheme, allows to consistently and efficiently update the signature of a credential, bypassing the need to generate and keep account of pseudonyms and NIZK proofs that are required in all previous works based on Idemix. Using mercurial signatures as in [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] allows to easily randomize the corresponding public keys while consistently adapting the signatures.

Issuer-hiding In [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF], since users can consistently randomize the signature on their credential and the issuer's public key (as previously mentioned), a fully adaptive NIZK argument is used to prove that a randomized issuer key belongs to the equivalence class of one of the keys contained in a list of issuers keys. This way, the randomized issuer key can be used to verify the credential while hiding the issuer's identity (like in a ring signature). In permissioned blockchains where there are multiple organizations that issue credentials, such a NIZK allows users holding valid signatures to pick any subset of issuer's public keys to generate a proof. Another approach following the work from [START_REF] Bobolz | Issuer-Hiding Attribute-Based Credentials[END_REF] (briefly discussed in [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF]) is to consider issuer-policies. An issuer-policy is a set {(σ i , opk i ) i∈[n] } of signatures on issuer's public keys generated by some verification secret key vsk. To hide the identity of an issuer j, a user consistently randomizes the pair (σ j , opk j ) to obtain a randomized public key opk ′ j . It then adapts the signature σ on its credential the same way, and presents opk ′ j to the verifier. If the verifier accepts the signature σ j on opk ′ j (using vpk), it proceeds to verify σ using opk ′ j . Issuer-policies can be specified by the entity that created the smart contract and defined within using the entity's verification key pair. Unlike the first approach where users choose the issuer's anonymity set, here it is determined by the policy maker.

Notation

Let BGGen be a p.p.t algorithm that on input 1 λ with λ the security parameter, returns a description BG=(p,G 1 ,G 2 ,G T ,P 1 ,P 2 ,e) of an asymmetric (Type-3) bilinear group where G 1 , G 2 , G T are cyclic groups of prime order p with ⌈log 2 p⌉ = λ, P 1 and P 2 are generators of G 1 and G 2 , and e :

G 1 × G 2 → G T is an efficiently computable (non-degenerate) bilinear map. For all a ∈ Z p , [a] s = aP s ∈ G s denotes the implicit representation of a in G s for s ∈ {1, 2}. For vectors a, b we extend the pairing notation to e([a] 1 , [b] 2 ) := [ab] T ∈ G T . r $ ← S
denotes sampling r from set S uniformly at random. A(x; y) indicates that y is passed directly to A on input x. Hash functions are denoted by H.

Set-Commitment scheme supporting Disjoint Sets [12]

Syntax. A set-commitment scheme supporting disjoint sets (SCDS) consists of the following p.p.t algorithms:

Setup(1 λ , 1 q ) is a probabilistic algorithm which takes as input a security parameter λ and an upper bound q for the cardinality of committed sets, both in unary form. It outputs public parameters pp (including an evaluation key ek), and discards the trapdoor key s used to generate them. Z * p \ {s} defines the domain of set elements for sets of maximum cardinality q. TSetup(1 λ , 1 q ) is equivalent to Setup but also returns the trapdoor key s. Commit(pp, X ) is a probabilistic algorithm which takes as input pp and a set Security Properties. Correctness requires that (1) for a set X , Open(Commit (pp,X ),X ) = 1, (2) for S a subset of X , VerifySS(S, OpenSS(Commit(pp, X ))) = 1, and (3) for all possible sets D disjoint from X , VerifyDS(D, OpenDS(Commit(pp, X )))=1. The scheme should also be (1) binding whereby each commitment overwhelmingly pertains to one particular set of attributes, (2) hiding whereby an adversary, given access to opening oracles, should not be able to distinguish which of two sets a commitment was generated on, and (3) sound in that sets which are not subsets of the committed set do not verify under VerifySS, and sets that are not disjoint from the committed set do not verify under VerifyDS.

X with 1 ≤ |X | ≤ q. It

Structure-Preserving Signatures on Equivalence Classes [12]

Syntax. A Structure-Preserving Signature on Equivalence Classes (SPS-EQ) consists of the following algorithms:

ParGen(1 λ ) is a p.p.t algorithm that, given a security parameter λ, outputs public parameters pp.

TParGen(1 λ ) is like ParGen but it also returns a trapdoor td (if any). KGen(pp, ℓ) is a p.p.t algorithm that, given pp and a vector length ℓ > 1, outputs a key pair (sk, pk). Sign(pp, sk, m) is a p.p.t algorithm that, given pp, a representative m ∈ (G * i ) ℓ for class [m] R , a secret key sk, outputs a signature σ ′ = (σ, τ ) (potentially including a tag τ ) on the message m. ChgRep(pp, m, (σ, τ ), µ, pk) is a p.p.t algorithm that takes as input pp, a representative message m ∈ (G * i ) ℓ , a signature σ (and potentially a tag τ ), a scalar µ, and a public key pk. It computes an updated signature σ ′ on new representative m * = µm and outputs (m * , σ ′ ). Verify(pp, m, (σ, τ ), pk) is a deterministic algorithm that takes as input pp, a representative message m, a signature σ (potentially including a tag τ ), and public key pk. If σ is a valid signature on m it outputs 1 and 0 otherwise.

For mercurial signatures, the algorithms ConvertPK(pk, ρ) and ConvertSK(sk, ρ) are included to compute new representatives for public and secret keys. ChgRep is extended to adapt signatures with respect to new key representatives as well.

Security Properties. SPS-EQ should be correct, existentially unforgeable against chosen-message attacks and have perfect adaption (in the vein of [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF]).

Our ABC Model

We can rely on the random oracle model and apply the Fiat-Shamir transform to the ABC scheme from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] (the showing protocol is a three move public coin one). However, in the previous ABC, interaction is required in the showing protocol to provide freshness (i.e., to avoid replay attacks). To overcome this issue, we require the user to send the transaction proposal during the first move. Thus, applying the Fiat-Shamir transform to the first move bounds the credential showing to that particular transaction so that it cannot be replayed. Security is defined following the usual properties from [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF][START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF][START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF]. In addition, we also consider the issuer-hiding notion from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] and introduce a new one for auditability. However, we do not consider replay-attacks as in the previous models since they can be trivially detected for the same transaction.

ABC Syntax. An ABC consists of the following p.p.t algorithms:

Setup(1 λ , aux) takes a security parameter λ and some optional auxiliary information aux (which may fix an universe of attributes, attribute values and other parameters) and outputs public parameters pp discarding any trapdoor. TSetup(1 λ , aux) like Setup but returns a trapdoor. OKGen(pp) takes pp and outputs an organization key pair (osk, opk). UKGen(pp) takes pp and outputs a user key pair (usk, upk). AAKGen(pp) takes pp and outputs an auditor key pair (ask, apk). RAKGen(pp) takes pp and outputs a revocation key pair (rsk, rpk).

Obtain(pp, usk, opk, apk, X , nym) and Issue(pp,upk,osk,apk,X ,nym) are run by a user and the organization respectively, who interact during execution. Obtain takes pp, the user's secret key usk, an organization's public key opk, an auditor's public key apk, an attribute set X of size |X | < q, and a pseudonym nym used for revocation. Issue takes pp, a public key upk, a secret key osk, an auditor's public key apk, an attribute set X of size |X | < q, and a pseudonym nym. At the end of this protocol, Obtain outputs a credential cred on X for the user or ⊥ if the execution failed. Show(pp, opk, upk, usk, cred, X , S, D, aux) takes pp, a public key opk, a key pair (usk, upk), a credential cred for the attribute set X , potentially non-empty sets S ⊆ X , D ̸ ⊆ X representing attributes sets being a subset (S) or disjoint (D) to the attribute set (X ) committed in the credential, and auxiliary information aux. It outputs a proof π. Verify(pp, opk, X , S, D, π, aux) takes pp, the (potentially empty) sets S and D, a proof π and auxiliary information aux. It outputs 1 or 0 indicating whether the credential showing proof π was accepted or not. RSetup(pp, (rsk, rpk), NYM, RNYM) takes pp, a revocation key pair (rsk, rpk) and two disjoint lists NYM and RNYM (holding valid and revoked pseudonyms). It outputs auxiliary information aux rev for the revocation authority and revocation information R = (R V , R S ). R V is needed for verifying the revocation status and R S is a list holding the revocation information per nym. Revoke(pp, (rsk, rpk), aux rev , R, b) takes pp, (rsk, rpk), aux rev , R and a bit b indicating revoked/unrevoked. It outputs information R ′ and aux ′ rev . AuditEnc(upk, apk) takes upk and apk. It outputs an encryption enc of upk under apk and auxiliary information α. AuditDec(enc, ask) takes enc and ask. It outputs a decryption of enc using ask. AuditPrv(enc, α, usk, apk) takes enc, α, usk, and apk. It generates a proof for enc being the encryption of upk under apk and outputs a proof π. AuditVerify(apk, π) takes apk and a proof π for the correct encryption of a user's public key under apk and outputs 1 if and only if the proof verifies.

To introduce the formal security model, we consider a single revocation, issuing and auditability authority. Extension to the multi-issuing and multi-auditing setting is straightforward as each key can be generated independently. For multiple revocation authorities, one needs to consider multiple revocation accumulators and thus adapt the scheme accordingly. Issuer-hiding and auditability properties are considered independently as extensions. Let us denote by Tx the universe of transactions tx represented as bitstrings. We also use the following auxiliary lists, sets and global variables in oracles and formal definitions. N represents the set of all pseudonyms nym while the sets NYM and RNYM represent the subsets of unrevoked and revoked pseudonyms respectively. Therefore, we have that NYM ∩ RNYM = ∅ ∧ NYM ∪ RNYM = N. NYM, HU and CU are lists that keep track of which nym is assigned to which user, honest users and corrupt users, respectively. The global variables RI and NYM LoR (initially set to ⊥) store the revocation information (R S , R V ) and the pseudonyms used in O LoR respectively. The oracles are defined as follows:

O HU (i) takes as input a user identity i.

$ ← Show(pp, USK[i], UPK[i], opk, ATTR[j], S, D, CRED[j], RI, apk, tx), •) O LoR (j 0 , j 1 , S,

D) is the challenge oracle in the anonymity game where A runs

Verify and must distinguish (multiple) showings of two credentials CRED[j 0 ] and CRED[j 1 ]. The oracle takes two issuance indices j 0 and j 1 and attribute sets S and D. Intuitively, correctness requires that a credential showing with respect to a non-empty sets S and D of attributes always verifies if it was issued honestly on some attribute set X with S ⊂ X and D ∩ X ̸ = ∅.

If J LoR ̸ = ∅ and J LoR ̸ = {j 0 , j 1 }, it returns ⊥. Let i 0 $ ← OWNR[j 0 ] and i 1 $ ← OWNR[j 1 ]. If J LoR ̸ = ∅ then it sets J LoR $ ← {j 0 , j 1 } and I LoR $ ← {i 0 , i 1 }. If i 0 , i 1 ̸ = HU ∨ N[i 0 ] = ⊥ ∨ N[i 1 ] = ⊥ ∨ N[i 0 ] ∈ RNYM ∨ N[i 1 ] ∈ RNYM ∨ S ̸ ⊆ ATTR[j 0 ]∩ATTR[j 1 ] ∨ D∩{ATTR[j 0 ]∪ATTR[j 1 ]} ̸ = ∅,
Definition 1 (Correctness). $ ← (Obtain(pp, usk, opk, apk, X , nym), Issue(pp, upk, osk, apk, X , nym)); (R S , R V ) ← Revoke(pp, R, aux rev , nym ′ , 1); Ω ← Show(pp, usk, upk, opk, cred, S, D, R, apk, tx); 1 ← Verify(pp, S, D, opk, R V , rpk, apk, tx, Ω)

An ABC system is correct if ∀ λ > 0, ∀ q, q ′ > 0, ∀ X : 0 < |X | ≤ q, ∀ ∅ ̸ = S ⊂ X , ∀ ∅ ̸ = D ̸ ⊆ X : 0 < |D| ≤ q, ∀ NYM, RNYM ⊆ N : 0 < |N| ≤ q ′ ∧ NYM ∩ RNYM = ∅, ∀ nym ∈ NYM, ∀ nym ′ ∈ RNYM it holds that: pp $ ← Setup(1 λ , (1 q , 1 q ′ )); (rsk,
We now provide a formal definition for unforgeablility. Given at least one non-empty set S ⊂ X or D ̸ ⊆ X , a user in possession of a credential for the attribute set X cannot perform a valid showing for D ⊂ X nor for S ̸ ⊆ X . Moreover, revocated users cannot perform valid showings and no coalition of malicious users can combine their credentials and prove possession of a set of attributes which no single member has. This holds even after seeing showings of arbitrary credentials by honest users.

Definition 2 (Unforgeability). An ABC system is unforgeable, if ∀ λ, q, q ′ > 0 and p.p.

* = 1 ∧ ∀ j : OWNR[j] ∈ CU =⇒ (N[j] = ⊥ ∨ (N[j] ̸ = ⊥ ∧ (S ̸ ⊆ ATTR[j] ∨ D ⊆ ATTR[j] ∨ N[j] ∈ RNYM))      
For anonymity, during a showing, no verifier and no (malicious) organization (even if they collude) should be able to identify the user or learn anything about the user, except that she owns a valid credential for the shown attributes. Furthermore, different showings of the same credential are unlinkable. Definition 3 (Anonymity). An ABC system is anonymous, if ∀ λ, q, q ′ > 0 and all p.p.t adversaries A having oracle access to

O := {O HU , O CU , O RN , O Obtain , O Show , O LoR } the following probability is negligible. Pr pp $ ← Setup(1 λ , (1 q , 1 q ′ )); (ask, apk) $ ← AAKGen(pp); b $ ← {0, 1}; (opk, rpk, st) $ ← A(pp); b * $ ← A O (st) : b * = b - 1 2
Issuer-hiding states that no adversary (i.e., a malicious verifier) cannot tell with high probability who is the issuer of a credential issued to an honest user.

Definition 4 (Issuer-hiding). An ABC system supports issuer-hiding if for all λ > 0, all q > 0, all n > 0, all t > 0, all X with 0 < |X | ≤ t, all ∅ ̸ = S ⊂ X and ∅ ̸ = D ̸ ⊆ X with 0 < |D| ≤ t, and p.p.t adversaries A, the following holds.

Pr      pp $ ← Setup(1 λ , 1 q ); ∀ i ∈ [n] : (osk i , opk i ) $ ← OKGen(pp); (usk, upk) $ ← UKGen(pp); j $ ← [n]; (cred, ⊤) $ ← (Obtain(usk, opk j , X ), Issue(upk, osk j , X )); j * $ ← A O Show (pp, S, D, (opk i ) i∈[n] ) : j * = j      ≤ 1 n
Finally, auditability requires that showings correctly encrypt users' keys.

Definition 5 (Auditability). An ABC scheme is auditable, if ∀ λ, q, q ′ > 0, tx, nym ∈ NYM, R, R V and all p.p.t adversaries A having oracle access to O Issue , the following probability is negligible.

Pr          pp $ ← Setup(1 λ , (1 q , 1 q ′ )); (rsk, rpk) $ ← RAKGen(pp); (ask, apk) $ ← AAKGen(pp); (osk, opk) $ ← OKGen(pp); (usk, upk) $ ← UKGen(pp); (S, D, enc, Ω, st) $ ← A O (pp, opk, rpk, apk, usk, upk, nym); (•, b * ) $ ← (A(st), Verify(pp, S, D, opk, R V , rpk, apk, RI, tx, Ω)) : b * = 1 ∧ upk ̸ = AuditDec(enc, ask)         

Protego

We elaborate on the decisions that led to the design of our ABC scheme Protego. Subsequently, we discuss our construction and the integration with Fabric.

Revocation. We opt to integrate the work from [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] as pointed out in [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF]. The revocation system from [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] defines a revocation authority responsible for managing an allow and deny list of revocation handlers. The authority publishes an accumulator RevAcc representing the deny list, and maintains a public list of non-membership witnesses for unrevoked users. During the issuing protocol, users are given a revocation handle that is encoded in the credential. To prove that they are not revoked during a showing, the user consistently randomizes its credential with the accumulator and the corresponding non-membership witness. Then the verifier checks that the (randomized) witness is valid for the revocation handle (encoded in the user credential), and with respect to the (randomized) accumulator. To work, the user must compute a Zero-Knowledge Proof of Knowledge (ZKPoK) on the correct randomization of the non-membership witness and the accumulator. As explained in [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF], the revocation handle encoded in the user's credential is of the form usk 2 (b + nym)P 1 , where usk 2 is an additional user secret key required for anonymity and nym is the pseudonym used for revocation. For this reason, users are required to manage augmented keys of the form upk = (upk 1 , upk 2 ), usk = (usk 1 , usk 2 ). Furthermore, for technical reasons, another component usk 2 Q, where Q is a random element in G 1 with unknown discrete logarithm, must be included in the credential.

Auditability. A credential in [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF][START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] and [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] contains a tuple (C, rC, P 1 ) where C is the set commitment on the user attributes, r is a random value used for technical purposes and P 1 is used to compute a ZKPoK of the randomizer µ in (µC, µrC, µP 1 ) during a showing. We borrow the idea of using a verifiable variant of ElGamal from [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF] to prove the well-formedness of a ciphertext (encrypting the user's public key) with respect to the auditor's key. Therefore, we add the user's public key upk 1 and the auditor's public key apk as the sixth and seventh components to the credential. Thus, we now have revocable credentials of the form (C, rC, P 1 , usk 2 (b + nym)P 1 , usk 2 Q, upk 1 , apk), which can be randomized to obtain a tuple (µC, µrC, µP 1 , µusk 2 (b + nym)P 1 , µusk 2 Q, µusk 1 P 1 , µapk). We exploit this fact to allow the user to generate an audit proof that can be publicly verified without leaking information about the user's public key. This way, verifiers can check a proof using the sixth and seventh component in the credential to be sure that (1) the user encrypted a public key for which it has the corresponding secret key, and (2) using the correct one. Since the issuing authority signs the credential, the randomization needs to be consistent. Modifications required to implement our auditability approach are as follows:

1. The user randomizes its credential as usual to obtain a new one of the form

(C ′ 1 , C ′ 2 , C ′ 3 , C ′ 4 , C ′ 5 , C ′ 6 , C ′ 7 )=(µC 1 , µC 2 , µP 1 , µC 4 , µC 5 , µupk 1 , µapk).
Since only the user knows the randomizer µ, its public key remains hidden. 2. The user picks α ∈ Z p and encrypts its own public key using ElGamal encryption with auditor's public key apk and randomness α to obtain a ciphertext enc = (enc 1 , enc 2 ) = (upk 1 + αapk, αP 1 ). 3. The user runs the algorithm AuditPrv (Figure 1) with input (enc, α, usk 1 , apk) to obtain c, z 1 and z 2 . 4. Then, the user picks β ← Z p , computes t 1 = βP 2 , t 2 = βµP 2 , t 3 = αβP 2 and sends (enc, c, z 1 , z 2 , t 1 , t 2 , t 3 ) to the verifier alongside the randomized credential from step 1. 5. The verifier checks the well-formedness of the ElGamal encryption pair running the algorithm AuditVerify (Figure 1) with input (c, enc, z 1 , z 2 ). If the check succeeds, it checks the following pairing equations to verify that the encrypted public key is the one in the credential: e(enc 2 , t 2 )=e(C ′ 3 , t 3 ) ∧ e(enc 2 , t 1 )=e(P 1 , t 3 ) ∧ e(enc 1 , t 2 )=e(C ′ 6 , t 1 )+e(C ′ 7 , t 3 ) Observe that the verifier knows

µP 1 = C ′ 3 , µusk 1 P 1 = C ′ 6 , µaskP 1 = C ′ 7 , (usk 1 + αask)P 1 = enc 1 , αP 1 = enc 2 , βP 2 = t 1 , βµP 2 = t 2 and αβP 2 = t 3 .
With β the user is able to randomize the other values so that the pairing equation can be checked to verify the relation between the ElGamal ciphertext and the randomized public key in C ′ 6 , without leaking information about the user's public key. Furthermore, the first two pairing equations verify the well-formedness of t 1 , t 2 and t 3 with respect to the user's credential and the ciphertext. Hence, the verifier will not be able to recover the user's public key nor the user cheat.

The proposed solution only adds two elements to the credential, while requiring the user to send two more elements in G 1 , three in Z p and three in G 2 , for a total of eight. Computational cost remains low as it just involves the computation of seven pairings, the ElGamal encryption and two Schnorr proofs [START_REF] Schnorr | Efficient identification and signatures for smart cards[END_REF].

Issuer-hiding. We incorporate the issuer-hiding approaches discussed in Section 2. The work from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] relies on a NIZK argument to prove that a randomized public key belongs to the equivalence class of one of the public keys contained in a list of issuer keys. We adapt the proof system to the signature used in this work, and extend it to make it malleable (see Appendix A) so that users can compute the proof once and then adapt it during showings with little computational cost (instead of having to compute it from scratch). This efficiency improvement is very useful in permissioned blockchains as the set of authorities tends to stay the same over time. For both approaches we observe that the mercurial signature used in this work only provides a weak form of issuer-hiding. Given a signature that has been adapted to verify under a randomized public key pk ′ in the equivalence class of pk, the owner of pk can recognize it. Thus, issuers can know which transactions belong to users from their organizations (but not to which particular user) and which ones don't by reading the non-interactive showing proof (it contains the issuer's randomized public key). However, we argue that in the permissioned blockchain setting this provides a fair trade-off as a minimum traceability level is important for compliance and auditability purposes.

Our construction. Compared to [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF], we make use of a hash function to apply the (strong) Fiat-Shamir transform while adding the previously discussed auditability and revocation features. Therefore we implement the ZKPoK's as Schnorr proofs (unlike [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] which followed Remark 1 from [START_REF] Fuchsbauer | Structure-preserving signatures on equivalence classes and constant-size anonymous credentials[END_REF]).

In Figure 1 we present the setup, key generation, revocation and auditing algorithms. The setup algorithm also takes a bound q ′ on the maximun number of revocated pseudonyms for the revocation accumulator. The revocation authority is responsible for running the Revoke algorithm and updating the accumulator.

Obtain and Issue have constant-size communication and are given in Figure 2. For Show and Verify we present Protego and Protego Duo, depending on the issuer-hiding approach. Protego is given in Figure 3 and produces a variablelength proof as it relies on the (mallable) NIZK proof. Protego Duo produces a constant-size proof and is depicted in Figure 4. The differences are highlighted with grey. For both, after the credential is updated, the user randomizes the revocation accumulator, witnesses, and generates the Schnorr proofs. Following the auditing proof, the Fiat-Shamir transform is applied, the ZKPoK's and PoE's are computed, returning the showing proof. Verify takes a proof (depending on the case), computes the challenge and verifies each of the statements.

Integration with Fabric. A multi-party computation ceremony can be run for the CRS generation of the Setup algorithm to ensure that no organization knows the trapdoors of the different components. As we are in the permissioned setting it is plausible to assume that at least one of the organizations is honest. By allowing users and endorsers to obtain credentials, both can produce showing proofs. Users can generate showing proofs to prove that they satisfy the access policy for the execution of a particular transaction proposal. Furthermore, by computing the PoE's, the verification time for endorsers improves substantially. Similarly, endorsers can prove that they satisfy a given endorsement policy attaching a showing proof to their endorements. Even if the endorsement policies Setup(1 λ , aux):

(q, q ′ ) ← aux; pick H : {0, 1} * → Z * p ; Q $ ← G1; (revpp, rev td ) $ ← RevAcc.
Setup(1 λ , q ′ ) (BG, scdspp, scds td ) $ ← SCDS.Setup(1 λ , q); (spspp, sps td ) $ ← SPS-EQ.ParGen(1 λ ; BG) return (H, BG, revpp, Q, scdspp, spspp) TSetup(1 λ , aux):

(q, q ′ ) ← aux; pick H : {0, 1} * → Z * p ; Q $ ← G1; (revpp, rev td ) $ ← RevAcc.
Setup(1 λ , q ′ ) (BG, scdspp, scds td ) $ ← SCDS.Setup(1 λ , q); (spspp, sps td ) $ ← SPS-EQ.ParGen(1 λ ; BG) td = (rev td , scds td , sps td ); return (H, BG, revpp, Q, scdspp, spspp, td) RevAcc.Setup(1 λ , 1 q ): BG Obtain(pp, usk, opk, apk, X , nym) Issue(pp, upk, osk, apk, X , nym) are defined in a privacy-preserving way as suggested in [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF], endorsers can still compute selective AND and NAND clauses for the respective pseudonyms defined by the policy using their credentials. Endorsers should also use the read and write sets to from the transaction proposals to generate showing proofs.

$ ← BGGen(1 λ ); b $ ← Z * p ; return (BG, (b i P1, b i P2) i∈[q] ) AAKGen(
check |X | ≤ q ∧ ̸ ∃ b ′ ∈ X : b ′ P1 = bP1; Πrev ← rsk -1 • ChX (s)P1; auxrev ← X return (Πrev, auxrev) Revoke(pp, R, auxrev, nym, b): parse R = (Πrev, WIT); parse auxrev = RNYM if b = 1 NYM ← NYM \ {nym}; RNYM ← RNYM ∪ {nym} (Π ′ rev ,
: (enc1, enc2) ← enc; return (enc1 -ask • enc2) AuditPrv(enc, α, usk, apk): r1, r2 ← Zp; com1 ← r1P1 + r2apk; com2 ← r2P1; c ← H(com1, com2, enc) z1 ← r1 + c • usk; z2 ← r2 + c • α; return (c, z1, z2) AuditVerify(apk, c, enc, z1, z2): com1 ← z1P1 + z2apk -cenc1; com2 ← z2P1 -cenc2; c ′ ← H(com1, com2, enc) return c ′ = c
r1, r2, r3 $ ← Z * p ; a1 ← r1P1; a2 ← r2P1 a3 ← r3Q; C4 ← usk2(b + nym)P1 C5 ← usk2Q; e ← H(upk 1 , upk 2 , C5, a1, a2, a3) z1 ← r1 + e • usk1 z2 ← r2 + e • usk2; z3 ← r3 + e • usk2 (C1, O) ← SCDS.Commit(scdspp, X ; usk1) r4 $ ← Z * p ; C2 ← r4 • C1 Σ ← (C1, C2, C4, C5, (ai, zi) i∈[3] ) Σ ----→ e ← H(upk 1 , upk 2 , C5, a1, a2, a3) check z1P1 = a1 + e • upk 1 z2P1 = a2 + e • upk 2 ; z3Q = a3 + e • C5 e(C1, P2) ̸ = e(upk 1 , ChX (s)P2) ∀ x ∈ X : xP1 ̸ = ek 0 1 check e(C4 ,
Security Proofs. We present the main theorems and proofs for Protego (which are analogous for Protego Duo). Correctness and issuer-hiding follow from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF].

Theorem 1. If the q-co-DL assumption holds, the ZKPoK's have perfect ZK, SCDS is sound, SPS-EQ is EUF-CMA secure, and RevAcc is collision-free then Protego is unforgeable.

Proof Sketch. The proof follows from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] (Th. 6) and [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] (Th. 3) whereby we assume there is an efficient adversary A winning the unforgeability game with non-negligible probability. We use A considering the following types of attacks: Type 1. Adversary A conducts a valid showing so that nym * =⊥. Then we construct an adversary B that uses A to break the EUF-CMA security. Type 2. Adversary A manages to conduct a showing accepted by the verifier using the credential of user i * under nym * with respect to S * such that S * ̸ ⊆ ATTR[nym] or with respect to D * such that D * ⊆ ATTR[nym] holds. Then we construct an adversary B that uses A to break the soundness of the set-commitment scheme SCDS. Type 3. Adversary A manages to conduct a showing accepted by the verifier reusing a showing based on the credential of a user i * under nym * with i * ∈ HU, whose secret usk i * and credentials it does not know. Type 4. Adversary A manages to conduct a showing accepted by the verifier using some credential corresponding to a revoked pseudonym nym * ∈ RNYM.

Show(pp, usk, upk, opk j , cred, S, D, (opk i ) i∈[n] , (opk i j , w i j ) i∈ [START_REF] Androulaki | Privacy-preserving auditable token payments in a permissioned blockchain system[END_REF] , Ω ,R, apk, tx) ) Verify(pp, S, D, Πrev, rpk, apk,tx, Ω) (enc, (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , opk ′ , (opk i ) i∈ [n] , Ω ′ ,cred ′ , wss, wds, wss ′ rev , Π ′ rev , Π, π1, π2, (ai, zi) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] ) ← Ω (C1, C2, C3, C4, C5, C6, C7, σ) ← cred ′ e ← H(S, D, apk, tx, enc, Π, opk ′ , (opk i ) i∈ [n] , Ω ′ ,(ai) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] , (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , cred ′ , wss, wds, tx, C2, C3, Π ′ rev , C5, wss ′ rev ) check z1C1 = a1 + eC2; z2P1 = a2 + eC3; z3Πrev = a3 + eΠ ′ rev ; z4Q = a4 + eC5 z5P1 = a5 + ewss ′ rev ; RevAcc.VerifyWit(Π ′ rev , C4, wss ′ rev ); AuditVerify(enc, Π2) e(enc1, t2) = e(C6, t1) + e(C7, t3); e(enc2, t2) = e(C3, t3); e(enc2, t1) = e(P1, t3) SCDS.VerifySS(C1, S, wss; π1, e); SCDS.VerifyDS(C1, D, wds; π2, e) SH.Verify((opk i ) i∈[n] , opk ′ , Ω ′ ) ; SPS-EQ.Verify(cred ′ , opk ′ ) Fig. 3: Protego: show and verify algorithms.

(C1, C4, C5, σ, r, nym, O) ← cred; (Πrev, WIT) ← R; β, µ, ρ, γ, τ, (ri) i∈[5] $ ← Z * p if O = (1, (o1, o2)) then O ′ = (1, (µ • o1, o2)) else O ′ = µ • O opk ′ j ← ConvertPK(opk j , ρw 1 j + γw 2 j ); Ω ′ ← SH.ZKEval(opk 1 j , opk 2 j , Ω; ρ, γ) σ ′ $ ← SPS-EQ.ChgRep(spspp, (C1, rC1, P1, C4, C5, upk 1 , apk), σ, µ, ρw 1 j + γw 2 j , opk j ) cred ′ ← ((Ci) i∈[7] = µ • (C1,
Then, we construct an adversary B that uses A to break the binding property of the revocation accumulator RevAcc. Types 1 and 2 follow the proofs of [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] (Th. 6) as the underlying primitives remain unchanged. For Type 3, we leverage the fact that reusing a showing would only allow the adversary to generate a valid showing for the same original transaction tx (that is timestamped), and hence, we do not consider it as an attack. Observe that any modification done to the original tx will lead to a different challenge and thus the rest of the proofs (showing, revocation and auditing) will not pass. Finally, Type 4 follows from [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] (Th. 3). □ Theorem 2. If the DDH assumption holds, the SPS-EQ perfectly adapts signatures, and H is assumed to be a random oracle, then Protego is anonymous.

Proof Sketch. The proof follows from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] (Th. 7) and [START_REF] Derler | A new approach to efficient revocable attribute-based anonymous credentials[END_REF] (Th. 4). However, we must also to take into account the RO model and the addition of the auditing features. The extra credential components for the auditing are randomized during every credential showing like the rest of the components. Similarly, the user generates a new encryption of the auditor's public key with a fresh α, while a fresh β 5 using the same hardware (exact times are also given in Table 2). For [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF], we consider a delegation level L = 2 , which corresponds to a user level given that the root authority is at L = 0 and organizations start at L = 1. Regarding the attributes, [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF] we could only retrieve information considering proofs for credential possesion below ten attributes (assuming a minimal overhead when all attributes are shown as authors suggest). Therefore, we report credential possesions for [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF] considering up to 8 attributes, and selective disclosures of k-out-of-10 attributes in ours. For Protego, we consider five authorities for the NIZK proof, which would suffice for practical scenarios like a consortium of pharmaceuticals.

Conclusions & Future Work

We presented here the first SPS-EQ credential scheme modified to work with permissioned blockchains. The versatility of Protego alongside the efficiency gains (at least twice as fast as the most recent Idemix extension), enables a broader scope of applications in such a setting. Depending on the context, the PoE's can be computed or not, the credential issuer can be hidden or not, and one can select only subsets or disjoint sets to generate the proofs. Similarly, auditability and revocation features can be considered as optional, showing its flexibility.

As future directions to explore, we consider the following points: (1) adding confidentiality of transactions to a Protego-like credential scheme, (2) adding more power to the users (i.e., how to define precise notions of user-invoked regulatory measures), and (3) extend our results to the multi-authority setting, where users can get attributes from multiple authorities instead of a single one.

  it returns ⊥. Else, it adds N[i b ] to NYM LoR and runs (S, •) $ ← (Show(pp, USK[j b ], UPK[j b ], opk, ATTR[j b ], S, D, CRED[j b ], RI, apk, tx), •) (with b set by the experiment)

←

  rpk) $ RAKGen(pp); (ask, apk) $ ← AAKGen(pp); (R, aux rev ) ← RSetup(pp, rpk, NYM, RNYM); (osk, opk) $ ← OKGen(pp); (usk, upk) $ ← UKGen(pp); (cred, ⊤)

←

  t adversaries A having oracle access to O := {O HU , O CU , O RN , O ObtIss , O Issue , O Show } the following probability is negligible. Setup(1 λ , (1 q , 1 q ′ )); (rsk, rpk) $ ← RAKGen(pp); (ask, apk) $ ← AAKGen(pp); (osk, opk) $ ← OKGen(pp); (S, D, st) $ ← A O (pp, opk, rpk, apk); (•, b * ) $ ← (A(st), Verify(pp, S, D, opk, rpk, apk, RI, tx, Ω)) : b

Fig. 1 :

 1 Fig. 1: Protego: setup, key generation, revocation and auditing algorithms.

Fig. 2 :

 2 Fig. 2: Protego: obtain and issue algorithms.

Fig. 5 :

 5 Fig. 5: From left to right, showing and verification times (in seconds) for the different schemes considering credential showings for 2, 4, 6 and 8 attributes.

  k

  outputs a commitment C on set X and opening information O. Open(pp, C, X , O) is a deterministic algorithm which takes as input pp, a commitment C, a set X , and opening information O. It outputs 1 if and only if O is a valid opening of C on X . OpenSS(pp, C, X , O, S) is a deterministic algorithm which takes as input pp, a

commitment C, a set X , opening information O, and a non-empty set S. If S is a subset of X committed to in C, OpenSS outputs a witness wss that attests to it. Otherwise, outputs ⊥. OpenDS(pp, C, X , O, D) is a deterministic algorithm which takes as input pp, a commitment C, a set X , opening information O, and a non-empty set D.

If D is disjoint from X committed to in C, OpenDS outputs a witness wds that attests to it. Otherwise, outputs ⊥. VerifySS(pp, C, S, wss) is a deterministic algorithm which takes as input pp, a commitment C, a non-empty set S, and a witness wss. If wss is a valid witness for S a subset of the set committed to in C, it outputs 1 and otherwise ⊥. VerifyDS(pp, C, D, wds) takes as input pp, a commitment C, a non-empty set D, and a witness wss. If wds is a valid witness for D being disjoint from the set committed to in C, it outputs 1 and otherwise ⊥. PoE(pp, X , α) takes as input pp, a non-empty set X , and a randomly-chosen value α. It computes a proof of exponentiation for the characteristic polynomial of X and outputs a proof π Q and a witness Q.

  If i ∈ HU ∪ CU, it returns ⊥. Otherwise, it creates a new honest user i by running (USK[i], UPK[i]) UKGen(opk), adding i to the honest user list HU and returning UPK[i]. O CU (i, upk) takes as input a user identity i and (optionally) upk; if user i does not exist, a new corrupt user with public key upk is registered, while if i is honest, its secret key and all credentials are leaked. If i ∈ CU, i ∈ I LoR (that is, i is a challenge user in the anonymity game) or if NYM LoR ∩ N[i] ̸ = ∅ then the oracle returns ⊥. If i ∈ HU then the oracle removes i from HU and adds it to CU; it returns USK[i] and CRED[j] for all j with OWNR[j] = i. Otherwise (i.e., i / ∈ HU ∪ CU), it adds i to CU and sets UPK[i] ← upk. O RN (rsk, rpk, REV) takes as input the revocation secret key rsk, the revocation public key rpk and a list REV of pseudonyms to be revoked. If REV∩RNYM ̸ = ∅ or REV ̸ ⊆ N return ⊥. Otherwise, set RNYM ← RNYM ∪ REV and RI ← Revoke(pp, (rsk, rpk), RNYM, RI, 1). O ObtIss (i, X ) takes as input a user identity i, a pseudonym nym and a set of Obtain(pp, USK[i], opk, apk, X , nym), Issue(pp, UPK[i], osk, apk, X , nym). If cred = ⊥, it returns ⊥. Else, it appends (i, cred, X , nym) to (OWNR, CRED, ATTR, NYM) and returns ⊤.

$ ← attributes X . If i / ∈ HU or ∃ j : NYM[j] = nym, it returns ⊥. Otherwise, it issues a credential to i by running (cred, ⊤) $ ← O Obtain (i, X ) lets the adversary A, who impersonates a malicious organization, issue a credential to an honest user. It takes as input a user identity i, a pseudonym nym and a set of attributes

X . If i / ∈ HU, it returns ⊥. Otherwise, it runs (cred, •) $ ← Obtain(pp, USK[i], opk, apk, X , nym), •),

where the Issue part is executed by A. If cred = ⊥, it returns ⊥. Else, it appends (i, cred, X , nym) to (OWNR, CRED, ATTR, NYM) and returns ⊤. O Issue (i, X ) lets the adversary A, who impersonates a malicious user, obtain a credential from an honest organization. It takes as input a user identity i, a pseudonym nym and a set of attributes X . If i / ∈ CU, it returns ⊥. Otherwise, it runs (•, I) $ ← (•, Issue(pp, UPK[i], osk, apk, X , nym)), where the Obtain part is executed by A. If I = ⊥, it returns ⊥. Else, it appends (i, ⊥, X , nym) to (OWNR, CRED, ATTR, NYM) and returns ⊤. O Show (j, S, D) lets the adversary A play a dishonest verifier during a showing by an honest user. It takes as input an index of an issuance j and attributes sets S and D. Let i $ ← OWNR[j]. If i / ∈ HU, it returns ⊥. Otherwise, it runs (S, •)

  * p ; (upk 1 , upk 2 ) ← (usk1P1, usk2P1) return ((usk1, usk2), (upk 1 , upk 2 )) RSetup(pp, (rsk, rpk), NYM, RNYM): (Πrev, auxrev) ← RevAcc.Commit(revpp, RNYM) foreach nym ∈ NYM do WIT[nym] ← RevAcc.NonMemWit(pp, Πrev, auxrev, nym) return ((Πrev, WIT), auxrev) RevAcc.Commit(pp, X ; rsk):

	pp): ask	$ ← Z * p ; apk ← askP1; return (ask, apk)
	RAKGen(pp): rsk	$ ← Z * p ; rpk ← rskP2; return (rpk, rsk)
	OKGen(pp): return SPS-EQ.KGen(BG, spspp, 7)
	UKGen(pp): usk1, usk2

$

← Z

  rC1, P1, C4, C5, upk 1 , apk), σ ′ ) wss ← SCDS.OpenSS(scdspp, C1, S, O ′ ); wds ← SCDS.OpenDS(scdspp, C1, D, O ′ ) AuditEnc(apk, upk 1 ); t1 = βP2; t2= βµP2; t3 = αβP2 Π ← AuditPrv(enc, α, usk, apk) e ← H(S, D, apk, tx, enc, Π, opk ′ j , (opk i ) i∈[n], Ω ′ ,(ai) i∈[START_REF] Bellare | Key-privacy in public-key encryption[END_REF] , (ti) i∈[START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , cred ′ , wss, wds, tx,C2, C3, Π ′ rev , C5, wss ′ rev ) z1 ← r1 + e • r; z2 ← r2 + e • µ; z3 ← r3 + e • (usk2µτ ); z4 ← r4 + e • (usk2µ) z5 ← r5 + e • (usk2µτ wss 2rev ) π1 ← SCDS.PoE(scdspp, S, e); π2 ← SCDS.PoE(scdspp, D, e) return (enc, (ti) i∈[START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , opk ′ , (opk i ) i∈[n] , Ω ′ ,cred ′ , wss, wds, wss ′ rev , Π ′ rev , Π, π1, π2, (ai, zi) i∈[START_REF] Bellare | Key-privacy in public-key encryption[END_REF]

	wssrev ← WIT[nym]; wss ′ rev ← (τ wss 1 rev , usk2µτ wss 2 rev P1)
	a1 ← r1C1; a2 ← r2P1; a3 ← r3Πrev; a4 ← r4Q; a5 ← r5P1; Π ′ rev ← (usk2µτ )Πrev
	(enc, α) ←

Table 2 :

 2 Protocols' comparison showing the running times in milliseconds. is much better. Verification cost in Protego and Protego Duo is almost constant (or O(k) if the PoE is disabled). The two works are compared in Figure

			= 2	k = 4	k = 6	k = 8	k = 10
	Scheme	Show Verify Show Verify Show Verify Show Verify Show Verify
	[7]	141	106	220	170	309	266	388	356	-	-
	Protego	86	142	89	140	92	141	93	145	96	145
	Protego Duo 29	35	32	35	34	36	37	36	39	38

Asymptotic complexity is O(1) (considering exponentiations and pairings) but some multiplications depending on the shown attributes are required, hence the difference.

Acknowledgements. We thank the anonymous reviewers for their valuable feedback. The European Commission partially supported Octavio Perez Kemp-

Show(pp, usk, upk, opk j , cred, S, D, opk j , σj ,R, apk, tx) (C1, C4, C5, σ, r, nym, O) ← cred; (Πrev, WIT) ← R; β, µ, ρ, γ, τ, (ri) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF]

← SPS-EQ.ChgRep(spspp, opk j , σj, ρ) σ ′ $ ← SPS-EQ.ChgRep(spspp, (C1, rC1, P1, C4, C5, upk 1 , apk), σ, µ, ρ, opk j ) cred ′ ← ((Ci) i∈ [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF] = µ • (C1, rC1, P1, C4, C5, upk 1 , apk), σ ′ ) wss ← SCDS.OpenSS(scdspp, C1, S, O ′ ); wds ← SCDS.OpenDS(scdspp, C1, D, O ′ ) wssrev ← WIT[nym]; wss ′ rev ← (τ wss 1 rev , usk2µτ wss 2 rev P1) a1 ← r1C1; a2 ← r2P1; a3 ← r3Πrev; a4 ← r4Q; a5 ← r5P1; Π ′ rev ← (usk2µτ )Πrev (enc, α) ← AuditEnc(apk, upk 1 ); t1 = βP2; t2 = βµP2; t3 = αβP2 Π ← AuditPrv(enc, α, usk, apk) e ← H(S, D, apk, tx, enc, Π, opk ′ j , σ ′ j ,(ai) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] , (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , cred ′ , wss, wds, tx,

rev ) π1 ← SCDS.PoE(scdspp, S, e); π2 ← SCDS.PoE(scdspp, D, e) return (enc, (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , opk ′ j , σ ′ j ,cred ′ , wss, wds, wss ′ rev , Π ′ rev , Π, π1, π2, (ai, zi) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] ) Verify(pp, S, D, Πrev, rpk, apk, vpk ,tx, Ω) (enc, (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , opk ′ , σ ′ ,cred ′ , wss, wds, wss ′ rev , Π ′ rev , Π, π1, π2, (ai, zi) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] ) ← Ω (C1, C2, C3, C4, C5, C6, C7, σ) ← cred ′ e ← H(S, D, apk, tx, enc, Π, opk ′ , σ ′ ,(ai) i∈ [START_REF] Bellare | Key-privacy in public-key encryption[END_REF] , (ti) i∈ [START_REF] Androulaki | Endorsement in hyperledger fabric[END_REF] , cred ′ , wss, wds, tx, C2, C3, Π ′ rev , C5, wss ′ rev ) check z1C1 = a1 + eC2; z2P1 = a2 + eC3; z3Πrev = a3 + eΠ ′ rev ; z4Q = a4 + eC5 z5P1 = a5 + ewss ′ rev ; RevAcc.VerifyWit(Π ′ rev , C4, wss ′ rev ); AuditVerify(enc, Π2) e(enc1, t2) = e(C6, t1) + e(C7, t3); e(enc2, t2) = e(C3, t3); e(enc2, t1) = e(P1, t3) SCDS.VerifySS(C1, S, wss; π1, e); SCDS.VerifyDS(C1, D, wds; π2, e) SPS-EQ.Verify(opk ′ , vpk) ; SPS-EQ.Verify(cred ′ , opk ′ ) Fig. 4: Protego Duo: show and verify algorithms. is used to randomize the values t i . Since ElGamal encryption is IND-CPA secure and key-private [START_REF] Bellare | Key-privacy in public-key encryption[END_REF], the ciphertexts produced by the user are indistinguishable and do not leak information about the user's public key nor the auditor's. □ Theorem 3. If the algorithms AuditPrv and AuditVerify are a NIZK proof system and the SPS-EQ is EUF-CMA secure then Protego is auditable.

Proof. If the verification returns true, we have that ∃ (enc * 1 , enc * 2 ) = ((δ * + α * ask)P 1 , α * P 1 ) for some δ * and α * chosen by the adversary. Moreover, because of the unforgeability of the signature scheme, the verification implies that C 3 = µ * P 1 , C 6 = µ * usk 1 P 1 and C 7 = µ * askP 1 for some µ * chosen by the adversary. As a result, we can re-write the pairing equations for the audit proof as:

We implemented a prototype of Protego and Protego Duo (available in [1]), using Rust with the bls12-381 curve and the BLAKE3 hash function. Our signature implementation is based on the one from [START_REF] Burkhart | Mercurial signatures implementation[END_REF] but using the bls12-381 curve instead of BN curves [START_REF] Barreto | Pairing-friendly elliptic curves of prime order[END_REF]. As a result, we obtain times up to 67% faster when compared to [START_REF] Burkhart | Mercurial signatures implementation[END_REF]. To run the benchmarks a Macbook Air (Chip M2 & 16GB RAM) was used with no extra optimizations, using the nightly compiler, and the Criterion library. For all values, the standard deviation was at most 1 millisecond.

Issue and Obtain take roughly 20 ms each when issuing a credential for 10 attributes. Both scale linearly on the number of attributes. To evaluate showing and verification, we considered the PoE in the showing protocol. Therefore, verification running time remains (almost) constant 5 regardless the number of shown attributes, credential size, and issuer-hiding approach. If the PoE is disabled, showing running time would be smaller while verification would increase linearly with the number of shown attributes. An auditing proof in Protego takes roughly 1 and 1.5 ms for proof generation and verification, surpassing the values from [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]. In Table 1 we report the revocation and signing algorithms, including our issuer-hiding NIZK with n = 5. For Protego, we consider a signature for vectors of length seven (the size of a credential). In our case, the revocation witnesses are computed by the authority (in linear time) and then randomized by the users (in constant time). For this reason we consider the generation of a single witness for a revocation lists of 10 and a hundred elements (although in practice one would expect it to be closer to 10). For [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF], we consider the total time to generate and verify a signature in a user level L = 2 (involving two delegations), with revocation times in G 2 .

Comparison with the Idemix extension from [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]. The computational cost for the prover and verifier grows linearly with the number of attributes in the credential and delegation levels for [START_REF] Bogatov | Anonymous transactions with revocation and auditing in hyperledger fabric[END_REF]. In Protego Duo, the prover computational cost is O(n -k) for showings involving k-attributes out of n, which in practice ner's work as part of the CUREX project (H2020-SC1-FA-DTS-2018-1 under grant agreement No 826404).

A Our NIZK Argument for Issuer-hiding

We refer the reader to [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF] (Section 3.1) for the basic syntax and security properties of malleable NIZK proof systems. In Figure 6 we build a fully adaptive malleable NIZK argument following the construction from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF]. The main idea is that given two proofs π 1 and π 2 for statements x 1 = w 1 v i and x 2 = w 2 v i , one can compute a valid proof π for the statement x = (αw 1 + βw 2 )v i with fresh α and β. The derivation privacy property of the proof system ensures that π looks like a freshly computed proof. Security follows from theorems 2 and 8 from [START_REF] Connolly | Improved Constructions of Anonymous Credentials from Structure-Preserving Signatures on Equivalence Classes[END_REF].

SH.TPGen(1 λ ):