Anonymous Transactions with Revocation and Auditing in Hyperledger Fabric

Abstract

In permissioned blockchain systems, participants are admitted to the network by receiving a credential from a certification authority. Each transaction processed by the network is required to be authorized by a valid participant who authenticates via her credential. Use case settings where privacy is a concern thus require proper privacy-preserving authentication and authorization mechanisms.

Anonymous credential schemes allow a user to authenticate while showing only those attributes necessary in a given setting. This makes them a great tool for authorizing transactions in permissioned blockchain systems based on the user’s attributes. In most setups, there is one distinct certification authority for each organization in the network. Consequently, the use of plain anonymous credential schemes still leaks the association of a user to the organization that issued her credentials. Camenisch, Drijvers and Dubovitskaya (CCS 2017) therefore suggest the use of a delegatable anonymous credential scheme to also hide that remaining piece of information.

In this paper, we propose the revocation and auditability—two functionalities that are necessary for real-world adoption—and integrate them into the scheme. We present a complete protocol, its security definition and the proof, and provide its open-source implementation. Our distributed-setting performance measurements show that the integration of the scheme with Hyperledger Fabric, while incurring an overhead in comparison to the less privacy-preserving solutions, is practical for settings with stringent privacy requirements.

Appendices

A Security Analysis

Fig. 4.

Extended credentials functionality $\mathcal {F}_{\mathrm {dac+}}$ (restated Fig. 1)

Our theorem proving the security of the extended protocol builds directly on the proof of the core protocol from [14] and extended by [20]. Our extensions that cover revocation and auditability are as follows. (1) We construct the scheme as a combination of standard signatures and NIZK, instead of sibling signatures and NIZK as used in [14, 20]. This is possible as we restrict ourselves to the case where the length of each delegation chain is fixed. (2) We need the NIZK to be non-malleable, as otherwise $\mathcal {F}_{\mathrm {dac+}}$ cannot identify the correct credential owner during an auditing query. This, however, is already implied by simulation-sound extractability. (3) We use a clock functionality [28] to model the advancement of epochs for the revocation scheme. We skip the parts of the description of the protocol $\Pi _{\mathrm {dac+}}$ and the proof that are identical to [14], and only discuss the differences that appear due to the revocation and auditing features (Fig. 4).

Setup. In addition to root authority $\mathcal {R}$, auditor $\mathcal {AU}$ creates a Diffie-Hellman key pair and registers the public key. The auditor also registers a proof-of-knowledge of the private key like root authority $\mathcal {R}$, at functionality $\mathcal {F}_{\mathrm {ca}}$. We use the same scheme for $\mathcal {AU}$ as [14] uses for $\mathcal {R}$, so that we also achieve online extractability.

Advance. Upon input, the epoch counter $\mathcal {T}$ provides an input to $\mathcal {F}_{\mathrm {clock}}$, which advances the epoch.¹

Delegate. Delegation is almost the same, except for the last delegation step (the one to the end user) where the delegator includes as one attribute the current epoch obtained from $\mathcal {F}_{\mathrm {clock}}$. In this step, the delegator also deposits the delegate’s public key with $\mathcal {AU}$.

Present. There are three modifications during presentation. The first is that the user generates a new pseudonym and proves consistency. The second is that a credential proof is only generated if a relevant credential exists for the present epoch, and the attribute that encodes the current epoch is always disclosed. The third one is that, as explained in Sect. 4.3, the user encrypts their public key under the auditor’s public key using AuditEnc and then proves consistent encryption using AuditProve.

Verify. The changes are dual to the above ones. The receiver, in addition to the standard credential validation, checks the consistency of the pseudonym, that the epoch attribute in the credential proof is valid, and the consistency of the auditing proof.

Audit. Given a credential proof, the auditor first checks its validity. If the credential proof is valid, the auditor then extracts the ciphertext that encrypts the user’s key and decrypts it.

Delegatable credentials protocol $\Pi _{\mathrm {dac+}}$ securely realizes $\mathcal {F}_{\mathrm {dac+}}$ in the $(\mathcal {F}_{\mathrm {smt}}, \mathcal {F}_{\mathrm {ca}}, \mathcal {F}_{\mathrm {crs}}, \mathcal {F}_{\mathrm {clock}})$-hybrid model, provided that

• $\textsc {SignNym}$ (Algorithm 2) is a strongly unforgeable signature,

• the auditing encryption is semantically secure,

• NIZK is a simulation-sound extractable non-interactive zero-knowledge proof.

The proof holds for static corruption of $\mathcal {AU}$.

Proof

We extend the proof of [14] to the functionality we added to the scheme. In Setup, the additional setup phase of auditor $\mathcal {AU}$ is proved analogously to that of the root authority. This includes the extraction of the private key if $\mathcal {AU}$ is corrupt; in that case the simulator sets $pp$ to include the auditor’s public key as well as public keys for all parties. If $\mathcal {AU}$ is honest, algorithm $\mathsf {Param}$ provides a fresh random key. Advance in $\mathcal {F}_{\mathrm {dac+}}$ means that all issued credential proofs become invalid, and that the last-level delegations are deleted from $\mathcal {L}_{\mathrm {de}}$. The same effect appears in the protocol, where the epoch advanced and inputs with old credential proofs to $\mathsf {VERIFY}$ will fail, as will the presentation of credentials that have been issued in an earlier epoch. Delegate behaves the same as before.

In the presentation phase, the credential proof $\mathfrak {p}$ returned by the functionality contains multiple additional elements (which in $\mathcal {F}_{\mathrm {dac+}}$ are generated by the algorithm $\mathsf {Present}$). The first two are $\mathsf {pk}_{\mathsf {nym}}$ and $\sigma _{\mathsf {nym}}$, the pseudonym generated for this presentation and the signature on m. The next two are $\mathsf {enc}$ and $\mathfrak {P}_{\mathsf {audit}}$, the encryption of the user’s public key $\mathsf {pk}$ under the auditor’s public key $\mathsf {apk}$, and the NIZK proving the correctness of this encryption. Algorithm $\mathsf {Present}$ generates the credential proof by building a fresh delegation chain with fresh keys and only the specified attributes; the only exception is that if $\mathcal {AU}$ is corrupt, then the correct user’s public key, as indicated by the additional argument to $\mathsf {Present}$, is chosen from $pp$ and encrypted under the auditor’s key. If $\mathcal {AU}$ is honest, then $\mathsf {Present}$ includes an encryption of a random message under the simulated auditor’s public key in $\mathfrak {p}$. $\mathsf {Present}$ sets the additional values as follows: $\mathsf {pk}_{\mathsf {nym}}$ and $\sigma _{\mathsf {nym}}$ are set to a fresh pseudonym and a signature relative to $\mathsf {pk}_{\mathsf {nym}}$ and the also fresh user public key. If $\mathcal {AU}$ is corrupt then the encryption of the user public key under $\mathsf {apk}$ and the corresponding zero-knowledge proof are computed as in the scheme using the values from $pp$. If $\mathcal {AU}$ is honest, then (as discussed) a random encryption is chosen and the proof is simulated. This simulation requires that the encryption scheme is semantically secure and the NIZK is zero-knowledge to ensure that the consistency proof for the encryption is indistinguishable from a real proof, and that as in [14] fresh delegations are indistinguishable from the real world where the same delegations are used for multiple presentations.

In the verification phase, in both the real and the ideal cases, the verification algorithm is used to verify $\mathfrak {p}$. While in the ideal case with honest auditor the auditing proof is simulated, this will also successfully verify in $\mathsf {Verify}$. The main difference is that $\mathcal {F}_{\mathrm {dac+}}$ prevents forgeries ideally whereas the protocol merely relies on the verification of the zero-knowledge proofs. The functionality also ensures that, for credential proofs that are accepted, their holders are known, therefore auditing will succeed. In the ideal world, the simulator knows the private key of $\mathcal {AU}$ (since it is chosen by the simulator if $\mathcal {AU}$ is honest, or extracted if $\mathcal {AU}$ is corrupt), and can therefore obtain the public key of the credential holder. This difference is indistinguishable by the simulation-sound extractability of the zero-knowledge proofs and the unforgeability of the signature scheme. Note that, in contrast with [14], we allow verification to succeed only for credential proofs $\mathfrak {p}$ that have either been generated by $\mathcal {F}_{\mathrm {dac+}}$ or are valid for corrupt parties. This in particular means that credential proofs are non-malleable, but non-malleability is already implied by simulation-sound extractability.

When honest $\mathcal {AU}$ inputs a credential proof $\mathfrak {p}$, the embedded ciphertext is decrypted. For credential proofs generated by an honest $\mathcal {P}_{i}$ this will always succeed. For those not generated by an honest $\mathcal {P}_{i}$, the functionality lets the adversary decide on the identity of the holder; the adversary can choose any corrupted party. The simulator can decrypt the auditing field of the credential proofs using the secret key of the auditor (which in case of a dishonest auditor has been extracted during setup). Indistinguishability again follows by the zero-knowledge property of the NIZK.

B Algorithms