Privacy-preserving auditable token payments in a permissioned system

Elli Androulaki Jan Camenisch Angelo De Caro IBM Research – Zurich DFINITY – Switzerland IBM Research – Zurich [email protected] [email protected] [email protected] Maria Dubovitskaya Kaoutar Elkhiyaoui Björn Tackmann DFINITY – Switzerland IBM Research – Zurich DFINITY – Switzerland [email protected] [email protected] [email protected]

ABSTRACT All of these solutions are however designed for permissionless Token payment systems were the first application of blockchain . Enterprise networks, on the other hand, favor permis- technology and are still the most widely used one. Early implemen- sioned platforms for their higher throughput and built-in gover- tations of such systems, like or , provide virtually nance [31, 32], with the latter being achieved by a combination of no privacy beyond basic pseudonymity: all transactions are written identity management, auditability and non-deniability. Although in plain to the blockchain, which makes them linkable and traceable. existing solutions can be tailored for permissioned networks, they Several more recent blockchain systems, such as or Zero- are not designed with auditability and accountability in mind. This cash, implement improved levels of privacy. Most of these systems paper bridges that gap: it hides the content of transactions without target the permissionless setting, and as such are not suited for en- preventing authorized parties from inspecting them. terprise networks. These require token systems to be permissioned Another goal of this paper is to move away from complex and and to bind tokens to user identities instead of pseudonymous ad- non-falsifiable computational assumptions that underpin zkSNARK- dresses. They also require auditing functionalities in order to satisfy based schemes and instead work with more conservative assump- regulations such as AML/KYC. tions. This is driven by financial use-cases that have a preference We present a privacy-preserving token management system that for well-established primitives with standard security assumptions. is designed for permissioned blockchains and supports fine-grained By restricting ourselves to the permissioned setting we were able auditing. The scheme is secure under computational assumptions to leverage a combination of signatures and standard ZK-proofs to in bilinear groups, in the random-oracle model. We provide perfor- achieve this goal. mance measurements for our prototype implementation built on top of Fabric. 1.2 Results We describe a token management system for permissioned net- works that enjoys the following properties: Privacy: Transactions written on the blockchain conceal both the values that are transferred and the sender-receiver 1 INTRODUCTION relationship. A transaction leaks no information about the 1.1 Motivation tokens being spent beyond that they are valid and unspent. As the blockchain technology matures, public and private compa- Authorization: Users authorize transactions via credentials; i.e., nies alike are exploring the technology to streamline their busi- the authorization for spending a token is bound to the ness [32]. An emerging paradigm to accommodate enterprise use- user’s identity instead of a pseudonym (or address). The cases is tokenization [33]. Tokens provide a natural abstraction to authorization makes use of anonymous credentials and is describe the lifecycle of an asset in terms of simple operations such privacy-preserving. as issue and transfer. However, moving to blockchain-based token Auditability: Each user has an assigned auditor that sees all the systems raises the challenge of preserving privacy. transaction information related to that particular user with- Several approaches already exist to add different levels of privacy out the latter’s explicit consent. to blockchain-based token systems. Tumblers such as CoinJoin [37] Satisfying these three requirements is crucial for implementing combine several transfer operations from different users and ob- a token system that ensures governance, protects user privacy and scure the relation between senders and receivers. In mix-in-based at the same time complies with regulations such as AML/KYC. systems such as CryptoNote [48], token transactions reference mul- The system we propose is based on the unspent transaction out- tiple superfluous senders that do however not actually participate put (UTXO) model pioneered by Bitcoin [39] and supports multi- in the transaction and only serve as a cover-up for the actual sender. input-multi-output transactions. It inherits several ideas from prior Confidential Assets42 [ ] hide the values in a token transfer but work, such as the use of Pedersen commitments from Confiden- leave the sender-receiver relation in the open. Finally, advanced tial Assets [42] and the use of serial numbers to prevent double- systems such as Zerocash [3] both encrypt the values and fully hide spending from Zerocash [3]. These are combined with a blind cer- the sender-receiver relation. tification mechanism that guarantees the validity of tokens via threshold signatures, and with an auditing mechanism that allows Solidus [17] is a privacy-preserving protocol for asset transfer flexible and fine-grained assignment of users to auditors. that is suitable for intermediated bilateral transactions, where banks We use a selection of cryptographic schemes that are based act as mediators. Solidus conceals the transaction graph and values in the discrete-logarithm or pairing settings and are structure- by using banks as proxies. The authors leverage ORAMs to allow preserving, such as Dodis-Yampolskiy VRF [20], ElGamal encryp- banks to update the accounts of their clients without revealing tion [21], Groth signatures [27], Pedersen commitments [41], and exactly which accounts are being updated. The novelty of Solidus Pointcheval-Sanders signatures [43]. This allows us to use the rela- is PVORM, which is an ORAM that comes with zero-knowledge tively efficient Groth-Sahai proofs29 [ ] and achieve security under proofs that show that the ORAM updates are correct with respect standard assumptions, in the random-oracle model. to the transaction triggering them. In Solidus there is no dedicated auditing functionality; however banks could open the content of 1.3 Related work relevant transactions at the behest of authorized auditors. The zkLedger protocol of Narula, Vasquez, and Virza [40] is a Miers et al. [38] introduced Zerocoin, which enables users to anonymize permissioned asset transfer scheme that hides transaction amounts their by converting them into zerocoins using Pedersen com- as well as the sender-receiver relationship and supports auditing. mitments and zero-knowledge proofs. Zerocoins can be changed One main difference with our approach is the end user: zkLedger back to bitcoins without leaking their origin. Zerocoin however aims at a setting where the transacting parties are banks, whereas does not offer any transacting or auditing capabilites. our solution considers the end user to be the client of “a bank.” This Confidential Assets of Poelstra et al. [42] protect privacy (in a is why zkLedger enjoys relatively more efficient proofs and could limited form) by hiding the types and the values of the traded assets. afford a transaction size that grows linearly with the number of total The idea, similarly to Zerocoin, is to use Pedersen commitments to transactors in the platform (i.e. banks), which is inherently small. encode the amount and types of traded assets, and zero-knowledge In our scheme, transaction size does not grow with the number of proofs to show the validity of a transaction. The proposed scheme overall parties; it only depends on the number of parties involved however does not hide the transaction graph or the public keys of in the transaction. Concerning auditability, zkLedger offers richer the transactors. While this allows for some form of public auditabil- and more flexible semantics but requires the participation ofthe ity, it hinders the privacy of the transacting parties. Pretty Good banks for the audit to take place. Confidentiality of Chen et19 al.[ ] follows a similar approach but adds explicit auditing functionality. Centralized e-cash. Our solution uses threshold blind signatures Zerocash [3] is the first fully anonymous decentralized payment to validate tokens and allow them to be transferred. While this scheme. It offers unconditional anonymity, to the extent that users shows similarities with centralized e-cash [10, 11, 18, 45], our solu- can repudiate their participation in a transaction. Thanks to a com- tion, by leveraging the blockchain, differs in the following funda- bination of hash-based commitments and zkSNARKs, Zerocash mental ways:( i) double spending detection is performed in real– validates payments and prevents double-spending relatively effi- time by all the nodes in the network;( ii) and a receiver of a token ciently. On the downside, Zerocash requires a trusted setup and is assured of its validity without contacting the issuing bank. an expensive transaction generation and its security relies on non- Outline. The remainder of the paper is structured as follows. In falsifiable assumptions. Section 2, we provide further background on several important Extensions to Zerocash have been proposed in [23] to support techniques. Section 3 then shows an overview of our protocol. expressive validity rules to provide accountability: notably, the pro- Section 4 describes the types of cryptographic schemes used in the posed solution ensures regulatory closure (i.e. allowing exchanges protocol, before Section 5 specifies the security model. Section 6 of assets of the same type only) and enforcing spending limits. In contains the protocol description and the security statement. In terms of accountability, the proposed scheme allows the tracing of Section 7, we describe the implementation and the performance certain tainted coins, while not really extensively and consistently measurements. Section 8 concludes. allowing transactions to be audited. By building on Zerocash, the proposed scheme inherits the same limitations regarding computa- 2 BACKGROUND tional assumptions and trusted setup. QuisQuis [22] and Zether [4] propose solutions that provide 2.1 Decentralized token systems partial anonymity. On a high level, instead of sending a transaction A decentralized token transfer is performed by appending a transfer that refers only to the accounts of the sender and the recipients of transaction to the blockchain. Such a transaction comprises the a payment, the sender adds accounts of other users, who act as an transfer details (e.g. sender, receivers, type and value) and a proof anonymity set (similar to CryptoNote [48]). Both schemes couple that the author of the transaction possesses enough liquidity to ElGamal encryption with Schnorr zero-knowledge proofs to ensure perform the transfer. The transaction is then validated against the that user accounts reflect the correct payment flows. Contrary to blockchain state (i.e. the ledger). More precisely, the blockchain Zerocash, QuisQuis and Zether rely on falsifiable assumptions and checks that the origin of the transaction has the right to transfer the do not require any trusted setup. Furthermore, both schemes can token and that the overall quantity of tokens is preserved during the be extended to provide auditability in a permissioned setting using transfer. Existing decentralized token systems can be account-based verifiable public-key encryption. However, their privacy guarantees (e.g. [30]) or unspent transaction outputs (UTXO)-based (cf. [39]). A are weaker than ours: namely, the anonymity set in our solution valid transfer in an account-based system results in updating the corresponds to all system participants. accounts of the sender and the receivers. In a UTXO-based token system, a transfer transaction includes a set of inputs—tokens to 2.5 Encryption-based auditability be consumed—and outputs—tokens to be created. A valid transfer In an encryption-based auditable token system, transactions carry in such systems destroys the inputs and adds the outputs to the ciphertexts intended for the authorized auditors, see e.g. [10, 11, 23]. ledger to be later consumed by subsequent transactions. For such a mechanism to be viable, it is important to ensure that (i) the ciphertexts encrypt the correct information;( ii) and they are 2.2 Privacy-preserving token systems computed using the correct keys. This can be achieved through zero- knowledge proofs—computed by the creator of the transaction—that Decentralization of token systems gives rise to serious privacy link the ciphertexts to the transfer details and attest that the two threats: if transactions contain the transfer information in the clear, requirements listed above are not violated. then anyone with access to the ledger is able to learn each party’s transaction history. We call a decentralized token system privacy- 3 OVERVIEW preserving if it partially or fully hides the transfer details. Examples of decentralized and privacy-preserving token systems are Con- 3.1 Design Approach fidential Assets [42], Zether [4], QuisQuis [22] and Zerocash [3], The first component of our solution is token encoding. Each token is with the latter offering the highest level of privacy protection. represented by a hiding commitment (e.g. Pedersen’s) that contains Zerocash. The privacy in Zerocash relies on a combination of com- the identifier of the token owner, the value of the token and itstype. mitments, zkSNARKs and Merkle-tree membership proofs. Namely, The life-cycle of a token is governed by two transactions: issue a token in Zerocash is computed as a hiding commitment to a value, and transfer. An issue transaction creates a token of a given type a type and an owner’s pseudonym. After its creation, a token is and value and assigns it to the issuer (i.e. author of the transaction). added to a public Merkle tree and during a transfer, the origin of For an issue transaction to be valid it should be submitted by the the transaction proves in zero-knowledge that the token is valid authorized issuer. For ease of exposition, we assume that a token (i.e. included in the Merkle tree), that it was not spent before and issuer can issue only one type of token and we conflate the type ofa that she owns it. Thanks to zkSNARKs, transaction validation in token with its issuer. Once a token is created, it changes ownership Zerocash is quite fast. Yet, this comes at the cost of a complex trusted through transfer transaction. Given that we operate within the setup and a very expensive proof generation. To obviate these two UTXO framework, a transfer transaction consists of a set of input limitations, we exploit the properties of permissioned token systems tokens to be consumed and a set of output tokens to be created and to replace Merkle trees with signature-based membership proofs, it is validated against the following rules: and devise a solution that does not use zkSNARKs. • The author of the transaction is the rightful owner of the input tokens; 2.3 Permissioned token systems • the owners of the output tokens are registered; In a permissioned token system such as Hyperledger Fabric [1] • the type and the value of tokens are preserved; or Quorum [34], a user is given a long-term credential that re- • the input tokens can be traced back to valid transactions flects her attributes. Tokens are introduced by special users, called in the ledger; issuers, through issue transactions. These transactions are then • the input tokens were not consumed before (to prevent validated against predefined policies that reflect existing norms double spending). and regulations. For example, issuing policies define which issuers Our solution moves away from zkSNARK and their trusted setup are authorized to create which tokens and under which conditions. assumption and relies only on standard NIZK proofs (e.g. Groth- Similarly to issue transactions, transfer can also be validated Sahai’s [29]). More precisely, it leverages the permissioned setting against policies: the simplest of which is that a transfer can take to use ZK signature-based membership proofs to ascertain that place only between registered users. A fundamental property of a user is registered and that a token belongs to the ledger in a permissioned systems is that transactions are signed using long- privacy-preserving manner. Namely, we assume that there is a term credentials. As a by-product, transactions can be traced back registration authority that provides authorized users with long-term to their origin, enforcing thus the requirements of auditability and credentials (i.e. signatures) with their attributes, and a certifier that accountability. a user contacts with a certification request to vouch for the validity of tokens she owns. A certification request contains a token (i.e. 2.4 Signature-based membership proofs commitment) and upon receiving such a request the certifier checks whether the token is included in a valid transaction in the ledger. If We use signatures to implement zero-knowledge membership proofs so, the certifier blindly signs the token and the resulting signature [5]. Roughly speaking, consider a set S that consists of elements can be used subsequently to prove that the token is legitimate. that are signed using a secret key sk associated with S. Proving To prevent double spending, we leverage serial numbers to iden- knowledge of some element 푒 in S in zero-knowledge amounts tify tokens when they are consumed as in Zerocash. It is important to( i) computing a hiding commitment of 푒;( ii) and then proving that these serial numbers satisfy the following security properties: knowledge of a signature, computed with sk, on the committed (i) collision resistance: two tokens result in two different serial value. In this paper, we use this mechanism for two purposes:( i) to numbers;( ii) determinism: the same token always yields the same prove that a user is in the set of registered users;( ii) and to show serial number;( iii) unforgeability: only the owner of the token can that a token is in the set of valid tokens recorded in the ledger. produce a valid serial number. We use verifiable random functions (e.g. Dodis-Yampolskiy [20]) to generate serial numbers that are a function of the token owner’s secret key and a randomness that is tied to the token at its creation time. To enable auditability, we encrypt the information in transfer transactions (i.e. sender, receivers, types and values) under the pub- lic keys of the sender’s and the receivers’ auditors. To accommodate real-world use-cases, our solution does not assume a single auditor for all users. This means that the encryption scheme must not only be semantically-secure but also key-private, such as ElGamal. 3.2 Architectural Model 3.2.1 Participants. Our solution involves the following parties: Users. They own tokens that represent some real-world assets and wish to exchange their tokens with other users in the network. This is achieved through transfer transactions. Issuers. They are users who are authorized to introduce tokens Figure 1: This figure shows the interactions between the participants in in the system through issue transactions. For simplicity purposes, our system. Users, issuers, auditors and the certifier are granted credentials an issuer is assumed to introduce one type of tokens only and that by interacting with the registration authority. To create new tokens, an issuer submits an issue transaction to the ledger and the ledger automatically adds the type of a token is defined as the identifier of its issuer. the transaction. To transfer a token, a user contacts the certifier with a certifi- cation request that references the token to be signed and the transaction that Auditors. These are entities with the authority to inspect trans- created it. If it is an issue transaction, the certifier checks if the author of the actions. We assume that each user in the system is assigned an transaction is authorized. If it is a transfer transaction, the certifier verifies auditor at registration time and that this assignment is immutable. if the ZK proof is valid. Once the owner of a token receives the corresponding certificate, she can transfer it to registered users. Finally, auditors assigned to Certifier. This is a privileged potentially-distributed party that a user can audit that user’s transactions by obtaining access to the ledger. provides users with certificates that vouch for the validity of their tokens. More specifically, a user who wishes to transfer atoken on, the system is able to accommodate token management requests. contacts the certifier with the token; the certifier in turn inspects More precisely, issuers submit issue transactions to the ledger whether the token appears in a valid transaction in the ledger. If so, to introduce new tokens, and the ledger ensures that all incom- the certifier sends back a certificate (i.e. signature) to that effect. ing transactions are correctly stored. Anyone with access to the Registration authority. This is a privileged party that gener- ledger, in particular the certifier and auditors, can verify whether ates long-term credentials for all the participants in the system, a transaction is valid or not using the information in the genesis including users, issuers, auditors and certifiers. Namely, the creden- block. Subsequently, token transfer operations take place between tials tie the real-world identity of the requestor to her attributes users through transfer transactions. The ledger again stores the and her public keys. An example of an attribute is role (e.g., “user”, transaction to make it available to all participants. For simplicity, “auditor”, “certifier”) that determines the type of credentials tobe we assume that the ledger accepts all transactions without verifica- generated. A user credential is a signature that binds the user’s pub- tion. However to transfer a token, a user contacts the certifier that lic keys to her identifier and the identifier of her auditor; whereas an checks if the transaction including the token is valid. Only then the auditor credential is a signature that links the auditor’s encryption certifier signs the token making it transferable. To inspect auser’s key to her identifier; finally the certifier’s credential is a signature activity, an auditor reads transactions from the ledger, checks their of her public key. validity and tries to decrypt them with her secret key only if they are valid. Ledger. This is a decentralized data store that keeps records of all issue and transfer transactions that have been previously 3.3 Trust Model submitted. It is accessible to all parties to read from and submit Registration authority. We assume that the registration au- transactions to. The ledger has a genesis block that contains( i) the thority is trusted to assign correct credentials to all parties in the system security parameters;( ii) the public information of the regis- system. A participant presents a set of attributes and her public tration authority and the credentials of the certifier; and( iii) the key to the registration authority and receives in return a credential identifiers of the issuers authorized to introduce new tokens. that binds her attributes to her public key. It is incumbent upon the 3.2.2 Interactions. The interactions between system participants registration authority to verify the correctness of the attributes of are shown in Figure 1. At first users, issuers, auditors and certifier a participant prior to sending the credential. For example, it should engage with the registration authority in a registration protocol to verify that the participant knows the secret key underlying the ad- get long-term credentials for their subsequent interactions. vertised public key. In the case of users, it should also verify that the A genesis block is created that announces the system parameters, announced auditors are legitimate. Furthermore, the registration the public information of the registration authority, the credentials authority is trusted to assign one unique credential per participant. of the certifiers and an initial list of authorized issuers. From now However, it is not trusted regarding the privacy of users. Notice that the trust assumption in the registration authority Commitments must be hiding in the sense that, without knowl- can be relaxed via a distributed registration protocol. edge of rcm, they do not reveal information on the committed mes- sages, and they must be binding in the sense that it must be infeasi- Users. Users may collude to compromise the security of the sys- ble to find a different set of messages 푚′, . . . ,푚′ and randomness tem. They may attempt to steal tokens of others, double-spend their 1 ℓ r′ that open the same commitment. own tokens, forge new tokens, transfer tokens to non-registered cm users, encrypt incorrect information in the auditors’ ciphertexts, 4.2 Digital signature schemes etc. They may also attempt to undermine the privacy of honest users by de-anonymizing transactors, linking tokens, learning the A digital signature scheme SIG consists of algorithms skeygen, sign, content of transactions, etc. and verify. The key generation algorithm (sk, pk) ←$ skeygen(휆) takes as input the security parameter 휆 and outputs a pair of Issuers. Issuers are users that are trusted to introduce tokens private (or secret) key sk and public key pk. Signing algorithm of a certain type. However, issuers may collude to surreptitiously s ←$ sign(sk, m) takes as input private key sk and message m, create tokens on behalf of other honest issuers, compromise the and produces a signature s. Deterministic verification algorithm privacy of users and obviate auditing among other things. 푏 ← verify(pk, m, s) takes as input public key pk, message m, and Certifier. To transfer a token, a user contacts the certifier to signature s, and outputs a Boolean 푏 that signifies whether s is a receive a signature that proves the token validity (i.e. inclusion in valid signature on m relative to public key pk. The standard defini- a valid transaction in the ledger). The certifier is hence trusted to tion of signature scheme security, existential unforgeability under generate signatures only for tokens created by valid transactions. chosen-message attack, has been introduced by Goldwasser, Micali, We relax this trust assumption using a threshold signature scheme and Rivest [26]. It states that given an oracle that generates valid that distributes the certification process and guarantees its integrity signatures, it is infeasible for an efficient adversary to output a valid as long as the majority of the signers (i.e. certifiers) is honest. signature on a message that has not been queried to the oracle. The While certifiers may be able to link transfer transactions ref- security of a signature scheme can also be described by an ideal erencing certified tokens to certification requests, they should not functionality Fsig, which can be found in Appendix A.4. be able to derive any further information about the transactions in the ledger or the tokens they certify. 4.3 Threshold signature schemes A non-interactive threshold signature scheme TSIG consists of Auditors. Auditors are authorized to only learn the information four algorithms tkeygen, sign, combine, and verify. Threshold key pertained to their assigned users. That is, colluding users and audi- generation (sk1,..., sk푛, pk ,..., pk , pk) ←$ tkeygen(휆, 푛, 푡) gets tors should not be able to derive any information about the token 1 푛 as input security parameter 휆, total number of parties 푛, and thresh- history of users who are not assigned to the malicious auditors. old 푡. Each party can sign with their own secret key sk푖 as above Ledger. For simplicity purposes, we use the ledger only as a to generate a partial signature s푖 . Any 푡 valid signatures can be time-stamping service. It does not validate transactions, rather combined using combine into a full signature s, which is verified as it stores the full transaction including the proofs of correctness. in the non-threshold case. A signature produced honestly by any 푡 Anyone later can check the transaction, verify the proofs and decide parties verifies correctly, but any signature produced by less than 푡 if the transaction is valid or not. We assume however that the ledger parties will not verify. is live and immutable: a transaction submitted to the ledger will eventually be included and cannot be deleted afterwards. 4.4 Public-key encryption. A public-key encryption scheme PKE consists of algorithms ekeygen, 4 CRYPTOGRAPHIC SCHEMES enc, and dec. Key-generation algorithm (sk, pk) ←$ ekeygen(휆) The section presents the cryptographic schemes that will be used takes as input security parameter 휆 and outputs a pair of pri- to build the protocol. We only present them briefly, and provide vate key sk and public key pk. Probabilistic encryption algorithm more information on concrete instantiations later in the paper. All c ←$ enc(pk, m) takes as input message m and public key pk and cryptographic algorithms are parametrized by a so-called security produces ciphertext c. We also write c ← enc(pk, m;푟) to empha- parameter 휆 ∈ N given (sometimes implicitly) to the algorithms. size that the encryption uses randomness 푟. Deterministic decryp- tion m ← dec(sk, c) takes as input ciphertext c and private key sk 4.1 Commitment schemes and recovers message m. Correctness requires that dec(sk, enc(pk, m)) = A commitment scheme COM consists of three algorithms ccrsgen, m for all (sk, pk) generated by ekeygen. For our work, we require commit, and open. The common reference string (CRS) generator semantic security as first defined by Goldwasser and Micali25 [ ]. ccrsgen is probabilistic and, on input the security parameter 휆, The scheme must additionally satisfy key privacy as defined by Bel- samples a CRS crs ←$ ccrsgen(휆). The commitment algorithm is a lare et al. [2], which ensures that, given a ciphertext c, it is hard to determine the public key under which the ciphertext is computed. probabilistic algorithm that, on input of a vector (푚1, . . . ,푚ℓ ) of messages, outputs a pair (cm, rcm) ←$ commit(crs, (푚1, . . . ,푚ℓ )) 4.5 Verifiable random functions of commitment cm and opening rcm. We also use the notation cm ← commit(crs, (푚1, . . . ,푚ℓ ); rcm) to emphasize that a specific A verifiable random function VRF consists of three algorithms randomness rcm is used. Finally, open(crs, cm, (푚1, . . . ,푚ℓ ), rcm) is vkeygen, eval, and check. Key generation (vsk, vpk) ←$ vkeygen(휆) a deterministic algorithm that outputs either true or false. takes as input the security parameter and outputs a pair of private key vsk and public key vpk. Deterministic evaluation (푦, 휋) ← constant identifiers, and ideal functionalities have party identifier eval(vsk, 푥) takes as input secret key vsk and input value 푥, and ⊥. The understanding here is that all ITIs that share the same code produces as output the value 푦 with proof 휋. Deterministic verifica- and the same sid are considered a session of a protocol. It is natural tion 푏 ← check(vpk, 푥,푦, 휋) takes as input public key vpk, input 푥, to use the same pid for all ITIs that are considered the same party. output 푦, and proof 휋, and outputs a Boolean that signifies whether ITIs can invoke other ITIs by sending them messages, new in- the proof should be accepted. stances are created adaptively during the protocol execution when The scheme satisfies correctness if honest proofs are always ac- they are first invoked by another ITI. To use composition, somead- cepted. Soundness means that it is infeasible to produce a valid proof ditional restrictions on protocols are necessary. In a protocol 휇휙→휋 , for an output value that was not correctly computed. The scheme which means that all calls within 휇 to protocol 휙 are replaced by must satisfy pseudo-randomness which means that, given only vpk, calls to protocol 휋, both protocols 휙 and 휋 must be subroutine re- the output 푦 for a fresh input 푥 is indistinguishable from a random specting. This means, in a nutshell, that while those protocols may output. have further subroutines, all inputs to and outputs from subroutines of 휙 or 휋 must only be given and obtained through 휙 or 휋, never 4.6 Non-interactive zero-knowledge proofs of by directly interacting with their subroutines. (This requirement is knowledge natural, since a higher-level protocol should never directly access Let R be a binary relation. For pairs (푥,푤) ∈ R, 푥 is called state- the internal structure of 휙 or 휋; this would obviously hurt compo- compliant ment (i.e. public input) whereas 푤 is called witness (i.e. private sition.) Also, protocol 휇 must be . This roughly means sid input). L = {푥, ∃ 푤 s.t. (푥,푤) ∈ R} is called the language of re- that 휇 should not be invoking instances of 휋 with the same as R instances of 휙, as otherwise these instances of 휋 would interact lation . A non-interactive ZK proof-of-knowledge system NIZK 휙→휋 for language L comprises three algorithms: zkcrsgen, prove and with the ones obtained by the operation 휇 . In summary, a protocol execution involves the following types verify. CRS generation crs ←$ zkcrsgen(휆, R) takes as input the Z A security parameter 휆 and a relation R and outputs a common ref- of ITIs: the environment , the adversary , instances of the pro- A erence string. On input of (푥,푤) ∈ L and crs, proof generation tocol machines 휋, and (possibly) further ITIs invoked by or any instance of 휋 (or their subroutines). The contents of the environ- 휓 ←$ prove(푥,푤, crs) returns a proof휓. Proof휓 is verified by calling algorithm 푏 ← verify(휓, 푥, crs), which in turn outputs a Boolean ment’s output tape after the execution is denoted by the random ( ) ∈ that indicates whether the proof is valid or not. variable exec휋,A,Z 휆, 푧 , where 휆 N is the security parameter ∈ { }∗ Z Correctness for such a proof system means that honestly-generated and 푧 0, 1 is the input to the environment . The formal proofs are always accepted. Knowledge soundness implies that a details of the execution are specified in14 [ ]. We say that a protocol F prover that produces a valid proof for some 푥 must know a witness 휋 UC-realizes a functionality if ( ) ∈ R 푤 with 푥,푤 , in the sense that 푤 can be extracted. Finally, ∀A ∃S ∀Z : exec휋,A,Z ≈ exec휙,S,Z, zero-knowledge ensures that the verification of correct statements ≈ yields nothing beyond the fact that they are correct. We describe where “ ” denotes indistinguishability of the respective distribution S the security of NIZK proofs of knowledge more formally using an ensembles, refers to the simulator and 휙 is the dummy protocol that simply relays all inputs to and outputs from functionality F. ideal functionality Fnizk deferred to Appendix A.2. In the remainder of the paper, we succinctly represent zero Multi-protocol UC. The standard UC framework does not allow knowledge proofs of knowledge using the common notation intro- to modularly prove protocols in which, e.g., a zero-knowledge proof duced by Camenisch and Stadler [12], namely PK {(푤) : 푥} denotes system is used to prove that a party has performed a certain eval- a proof of knowledge of witness 푤 for statement 푥. uation of a cryptographic scheme correctly. Camenisch et al. [6] recently showed how this can be overcome. In a nutshell, they start 5 SECURITY FORMALIZATION 푅 from the standard Fnizk-functionality which is parametrized by a Notation. We use sans-serif fonts to denote constants such as true relation 푅, and show that if 푅 is described in terms of evaluating a or false, and typewriter fonts to denote string constants. protocol, then the protocol can equivalently be evaluated outside of the functionality, and even used to realize another functionality F. 5.1 Universal composition and MUC This results in a setting where Fnizk validates a pair (푦,푤) of state- In this section, we only recall basic notation and specific parts of the ment 푦 and witness 푤 by “calling out” to the other functionality F. model that we need in this work. Details can be found in [13–15]. We use this proof technique extensively in this work. The UC framework follows the simulation paradigm, and the entities taking part in the protocol execution (protocol machines, 5.2 The privacy-preserving token functionality functionalities, adversary, and environment) are described as in- The functionality Ftoken realized by our privacy-preserving token teractive Turing machines (ITMs). The execution is an interaction system is formalized in Figure 2. To keep the presentation simple, of ITM instances (ITIs) and is initiated by the environment Z that the functionality formalizes the guarantees for the case of a single provides input to and obtains output from the protocol machines, token issuer I. The functionality initially requires registration au- and also communicates with adversary A. The adversary has ac- thority A, certifier C, and issuer I to initialize. (This corresponds cess to the protocols as well as functionalities used by them. Each to the fact that all protocol steps depend on those parties’ keys.) ITI has an identity that consists of a party identifier pid and a ses- Likewise, regular parties 푃 have to generate and register their keys sion identifier sid. The environment and adversary have specific, before they can perform operations. Each party can then read the tokens they own and generate transfer transactions that refer- Privacy-preserving token functionality Ftoken ence those tokens and transfer them to one or more receivers. The Functionality Ftoken stores a list of registered users and an ini- issuer can additionally issue new tokens. In the inputs and out- tially empty map Records. The session identifier is of the form puts of the functionality, v always represents the value of a token, sid = (A, C, I, sid′). and cm serves as a handle identifying the token (it stems from the • Upon input init from 푃 ∈ {A, C, I }, output to A commitment that represents the token on the ledger). Finally, the (initialized, 푃). (This must happen for all three before functionality specifies which information is potentially leaked to anything else.) the adversary, and which operations the adversary can perform in • Upon input register from a party 푃, if 푃 is unregistered, the name of corrupted parties. then mark 푃 as registered and output (registered, 푃) to A. (Otherwise ignore.) 5.3 Set-up functionalities • Upon input read from a registered party 푃, issue Our protocol calls for a number of set-up functionalities; most of (read?, 푃) to A. Upon receiving response (read!, 푃) which are widely used in the literature. This is why we only briefly from A, return to 푃 a list of all records of the type (cm, v) describe them here and defer the details to Appendix A. that belong to 푃. • Upon input (issue, v) from I, output (issue, v) to Common reference string. Functionality Fcrs provides a string A. Receiving from A a response (issue, cm), if that is sampled at random from a given distribution and accessible to Records[cm] ≠ ⊥ then abort, else set Records[cm] ← all participants. All parties can simply query Fcrs for the reference (v, I, alive). Return (issued, cm) to I. string. The functionality is generally used to generate common • Upon receiving an input (issue, v, cm) from A, where public parameters used in a cryptographic scheme. I is corrupt, check and record the commitment as in the previous step. Return to A. Transaction ledger. We describe a simplified transaction ledger  푚 out 푛  • Upon input transfer, (cm푖 ) , (v , R푗 ) from an functionality as F in Figure 3. In a nutshell, every party can 푖=1 푗 푗=1 ledger honest party 푃, where 푃 and all R for 푗 = 1, . . . , 푛 are append bit strings to a globally available ledger, and every party 푗 registered, proceed as follows. can retrieve the current ledger. (1) If, for any 푖 ∈ {1, . . . ,푚}, Records[cm ] = ⊥ then F intentionally idealizes the guarantees achieved by a real- 푖 ledger abort, else set (vin, 푃 ′, st ) ← Records[cm ]. world ledger; transactions are immediately appended, final, and 푖 푖 푖 푖 (2) If, for any 푖 ∈ {1, . . . ,푚}, st ≠ alive or 푃 ′ ≠ 푃, available to all parties. We also use F as a local functionality. 푖 푖 ledger then abort. These simplifications are intended to keep the paper more digestible. Í푚 in Í푛 out (3) If 푖=1 v푖 ≠ 푗=1 v푗 then abort. 퐿 푗 = , . . . , 푛 Secure and private message transfer. Functionality Fsmt provides (4) Let be an empty list. For all 1 , if a message transfer mechanism between parties. The functionality R푗 is corrupt then append to 퐿 the information ( out) ( ) A builds on the ones described by Canetti and Krawczyk [16], but 푗, 푃, R푗 , v푗 . Output transfer,푚, 푛, 퐿 to . additionally hides the sender and receiver of a message, if both are (5) Receiving from A a response ( ( out)푛 ) [ out] ⊥ honest. This is required since our protocol passes information be- transfer, cm푗 푗=1 , if Records cm푗 ≠ tween transacting parties, and leaking the communication pattern for any 푗 ∈ {1, . . . , 푛} then abort, else set [ out] ← ( out ) would revoke the anonymity otherwise provided by our protocol. Records cm푗 v푗 , R푗 , delayed for all 푗 ∈ {1, . . . , 푛} and set Records[cm푖 ] ← Public-key registration. The registration functionality Freg mod- in ′ (v푖 , 푃 , consumed) for all 푖 ∈ {1, . . . ,푚}. els a public-key infrastructure. It allows each party 푃 to input one out 푛 (6) Return (transferred, (cm ) = ) to 푃. value 푥 ∈ {0, 1}∗ and makes the pair (푃, 푥) available to all other 푗 푗 1 • On (transfer, 푃, (cmin)푚 , (R , vout, cmout)푛 ) from parties. This is generally used to publish public keys, binding them 푖 푖=1 푗 푗 푗 푗=1 A to the identity of a party. where 푃 is corrupt, proceed analogously to above. • Upon receiving an input (deliver, cm) from A with Anonymous authentication. As our protocol is in the permis- Records[cm] = (v, 푃, delayed) for some v and 푃, set sioned setting but supposed to provide privacy, we need anony- Records[cm] ← (v, 푃, alive). If C is corrupted, then mous credentials to authorize transactions. Our schemes integrate output 푃 to A. well with the Identity Mixer family of protocols [9]. As these topics are not the core interest of this paper, we abstract the necessary Figure 2: Privacy-preserving token functionality mechanisms in the functionality Fa-auth as depicted in Figure 4. Fa-auth allows parties to first register and then “authorize” com- mitments; the functionality returns “proofs” 휓 assuring that the party’s identity is contained in a certain position of that commit- ment. Fa-auth also allows to bind the proof to a bit string m, which Our description of Fa-auth is simplistic and tailored to an easy intuitively can be understood as “party 푃 (as referenced in the com- treatment in our proofs. For a complete composable model of anony- mitment) signs message m.” The exact reason for this mechanism mous authentication schemes, see for e.g. the work of Camenisch, will become clear in the protocol description in Section 6.5. Dubovitskaya, Haralambiev, and Kohlweiss [7]. ′ Ledger functionality Fledger She generates a first NIZK 휓1 showing that cm contains the cor- Functionality Fledger stores an initially empty list 퐿 of bit strings. rect information and that the receiver is registered, and a sec- • Upon input (append, 푥) from a party 푃, append 푥 to 퐿. ond proof 휓2 of eligibility (i.e. the initiator of the transfer owns F F If 푃 is corrupt then send (append, 푥, 푃) to A, else return cm) using a-auth. The information written to ledger is tx = ( ′ ) to 푃. transfer, cm ,휓1,휓2 . At this point, we cannot yet describe how • Upon input retrieve from a party 푃 or A, return 퐿. 푃 proves that (a) cm is a valid commitment on the ledger—we can- not include cm in the transaction as that would hurt privacy—and (b) that 푃 is not double-spending cm. These aspects will be covered Figure 3: Ledger functionality ′ ′ subsequently. Party 푃 also sends the message (token, cm , rcm, v) to R privately. Extended anonymous authentication functionality So far, we have shown how to transfer a single token from a party 푃 to a receiver R. Following sections show how to( i) make sure Fa-auth that only valid and unspent tokens are transferred; and( ii) support Functionality F is parametrized by a commitment opening a-auth multi-input multi-output transfers. algorithm open. It stores an initially empty set U of registered users, and an initially empty list of records. 6.2 Certification via blind signatures • Upon input register from a party 푃 where 푃 ∉ U, set U ← U ∪ {푃} and output (registered, 푃) to A. • Upon input (lookup, 푃 ′) from a party 푃, return (the re- (TSIG,commit) (Threshold) blind signature functionality Fblindsig sult of) 푃 ′ ∈ U. Functionality F requires that sid = • Upon input (prove, crs, cm, r , 푥,푦, m) from a regis- blindsig cm ((C ,..., C ), 푡, ℓ, sid′), where C ,..., C are the party identifiers tered party 푃, if open(crs, cm, (푥, 푃,푦), r ) then gener- 1 푛 1 푛 cm of the signers and ℓ is the size of the vectors of messages to ate a proof 휓, store the record (transfer, crs, cm,휓, m) be signed. It is parametrized by the (deterministic) commit internally and output 휓 to 푃. algorithm of the commitment as well as the a threshold signature • Upon input (verify, crs,휓, m) from some 푃, look up if scheme TSIG = (tkeygen, sign, verify). The functionality keeps there is a record (transfer, crs, cm,휓, m) and output an initially empty set Σ of signed messages. success (only) if it exists. • Upon init from some C푖 , run (sk1,..., sk푛, pk1,..., pk푛, pk) ←$ tkeygen(휆, 푛, 푡, ℓ), where 휆 is Figure 4: Extended anonymous registration functionality obtained from the security parameter tape, and store (sk1,..., sk푛, pk). Output (init, C푖 ) to A. • Upon input pubkey from party 푃, return (pubkey, pk). 6 PRIVACY-PRESERVING AUDITABLE UTXO • On input (request, crs, rcm, (푚1, . . . ,푚ℓ )) from party 푃: This section describes the complete protocol. We begin by introduc- (1) Compute cm ← commit(crs, (푚1, . . . ,푚ℓ ); rcm) ing the core ideas and mechanisms in Sections 6.1 – 6.3. Section 6.4 and store it internally along with the messages and introduces multi-input multi-output transactions, followed by Sec- randomness. tion 6.5 that assembles all pieces and describes the full protocol. (2) Send delayed output (request, 푃, crs, cm) to each Section 6.6 presents the extension that makes the protocol auditable C푖 , 푖 ∈ {1, . . . , 푛}. and Section 6.7 states the main security result of the paper. • Upon input (sign, cm) from C푖 : (1) If no record with commitment cm exists, then abort. 6.1 Core protocol ideas (2) If there is a record ((푚1, . . . ,푚ℓ ), 푆) ∈ Σ with 푆 ⊆ {C ,..., C푛 }, update the record with 푆 ← 푆 ∪ {C푖 }. The protocol uses commitments (cm, rcm) ←$ commit(crs, (v, 푃)) 1 ← ∪ {(( ) { })} to represent tokens, where v is the value and 푃 is the current owner. Else set Σ Σ 푚1, . . . ,푚ℓ , C푖 . | | ≥ ← ( ( )) Issuers create new tokens in their own name. Transferring tokens (3) If 푆 푡, then compute s sign sk, 푚1, . . . ,푚ℓ (v, 푃) to a party R means replacing the commitment to (v, 푃) with a and output s to requestor 푃. • ( ′ ( ) ) commitment to (v, R). We now describe the protocol steps in more Upon input verify, pk , 푚1, . . . ,푚ℓ , s from 푃, com- ← ( ′ ( ) ) ′ ∧ detail, but still at an informal level. pute 푏 verify pk , 푚1, . . . ,푚ℓ , s . If pk = pk ∧ (( ) ) ∨ | |  To issue a token of value v, the issuer generates a new commit- 푏 푚1, . . . ,푚ℓ , 푆 ∉ Σ 푆 < 푡 then output (result, false) to 푃. Else output (result,푏) to 푃. ment (cm, rcm) ←$ commit(crs, (v, I)), which means a token with • ( ) A value v is created with owner I. The protocol generates a proof Upon input seckey, 푖 from , if C푖 is corrupted, then return sk푖 . 휓0 ← PK {(rcm) : open(crs, cm, rcm, (v, I)) = true} which shows that the commitment contains the expected informa- Figure 5: Blind signature functionality, threshold version. tion. Issuer I also creates a signature s on message (v, cm,휓0). The information written to Fledger is tx = (issue, v, cm,휓0, s). The problem of verification of token validity during transfer A party 푃 transfers a token (i.e. a commitment cm) to a receiver R is resolved by certification. We consider a specific party, called a ′ ′ by computing a new commitment (cm , rcm) ←$ commit(crs, (v, R)). certifier C, which vouches for the validity of a token (v, 푃) stored as a commitment cm on Fledger by issuing a signature s on (v, 푃). indeed belongs to 푃, and the fourth condition checks that the com- In the proof 휓1, 푃 refers to signature s instead of commitment cm. putation of the serial number sn is correct. These two conditions, A naive implementation of the above scheme would require party together with trust in the correctness of A, prevent token (v, 푃, 휌in) 푃 to reveal the content (v, 푃) of cm to certifier C, so that the latter from being double-spent. issues the corresponding signature s: prior to signing, C checks that cm opens to (v, 푃) and that cm is stored on Fledger. Disclosing the pair (v, 푃) to C is both undesired and unnecessary. Instead we rely 6.4 Multi-input multi-output transactions on a blind signature protocol, in which C learns only the value of Multi-input multi-output transactions allow a sender to transfer commitment cm and blindly signs its content. tokens contained in multiple commitments at once, and to split the While C learns cm during the protocol, it will not be able to accumulated value into multiple outputs for potentially different leverage the data on Fledger to trace when 푃 makes use of the receivers. We therefore modify the transaction format to contain corresponding signature s. More precisely, within 휓1, party 푃 only multiple inputs and multiple outputs. We also have to extend the proves knowledge of a signature s and does not reveal it. NIZK: besides the fact that we have to prove consistency of multiple Note that a malicious certifier can essentially generate tokens inputs and multiple outputs, we now have to show that the sum of by providing its signature without checking for existence of the the inputs equals the sum of the outputs. commitment on Fledger. Appendix D describes how to distribute Due to arithmetics in finite algebraic structures, we also have to the certification task, so that no single party is trusted for verifica- prove that no wrap-arounds occur. This is achieved, as in previous tion. Figure 5 shows a threshold blind signature ideal functionality, work, by the use of range proofs. For a given value max ∈ {1, . . . , 푝}, which we will use in the description of our solution in Section 6.5. the condition is that 0 ≤ v ≤ max for any value v that appears in an output commitment. 6.3 Serial numbers prevent double-spending The proof, in more detail, now becomes Double-spending prevention is achieved via a scheme that is in- spired by Zerocash [3] in that it uses a VRF to compute serial  in in 푚 numbers for tokens when they are spent. The VRF key is here, how- 휓1 ← PK (s푖, v푖 , 휌푖 , 휋푖 )푖=1, 푃, sA, ever, bound to a user via a signature from the registration authority. 푗 푗 (R , r , vout, 휌out, vpk , s )푛  : On a very high level, the above protocol is extended as follows. 푗 cm 푗 푗 푗 A 푗=1 ∀푖 ∈ {1, . . . ,푚} : verify(pk , (vin, 푃, 휌in), s ) (1) Each user 푃 creates a VRF key pair (vsk, vpk). They obtain C 푖 푖 푖 out out 푗 a signature sA from registration authority A that binds vpk ∧ ∀푗 ∈ {1, . . . , 푛} : open(crs, cm푗 , (v푗 , R푗 , 휌 푗 ), rcm) to their identity 푃. ∧ verify(pk , (푃, vpk), sA) (2) Each commitment contains an additional value 휌 . A ∧ ∀ ∈ { } ( ( ) 푗 ) (3) During transfer, the value 휌 is used to derive the serial 푗 1, . . . , 푛 : verify pkA, R푗 , vpk푗 , sA number (sn, 휋) ← eval(vsk, 휌 ). The transaction stored in in ∧ ∀푖 ∈ {1, . . . ,푚} : check(vpk, 휌 , sn푖, 휋푖 ) F also contains sn. 푖 ledger 푚 푚 (4) We cannot store the VRF proof 휋 on F , as it is bound ∑︁ ∑︁ ledger ∧ vin = vout to vpk and would deanonymize 푃. Instead, 푃 proves knowl- 푖 푗 푖=1 푗=1 edge of signature sA, which binds vpk to her identity, and ∧ ∀ ∈ { } ≤ out ≤ proves in zero-knowledge that check(vpk, 휌, sn, 휋) = true. 푗 1, . . . , 푛 : 0 v푗 max . (1) We stress that authority A must be trusted to prevent double- spending, otherwise it could register multiple VRF keys for the The processing of the transaction is analogously modified to same user. It is thus recommended to implement A in a distributed check this more complex NIZK. We now argue that the statement fashion. proved in the NIZK indeed guarantees the consistency of the system. in The proof 휓1 made by 푃 during a transfer of token (v, 푃, 휌 ) is The first sub-statement (together with the honesty of C) guaran- tees that all commitments used as inputs indeed exist in the ledger,  ′ in out  휓1 ← PK rcm, sA, sC, R, 푃, 휌 , 휌 , 휋, v : and the fact that the commitment is binding further implies that in ′ out ′ the values (vin, 푃, 휌in) indeed correspond to the expected state of verify(pkC, (v, 푃, 휌 ), sC) ∧ open(crs, cm , (v, R, 휌 ), rcm) 푖 푖 in the system. The next sub-statement shows that the output commit- ∧ verify(pkA, (푃, vpk), sA) ∧ check(vpk, 휌 , sn, 휋) ( out out) ments indeed contain the expected values v푗 , R푗 , 휌 푗 . The two which can be parsed as follows: prior to the transfer, 푃 obtains subsequent statements ensure that all parties are registered users, in in and the statement check(vpk, 휌 , sn푖, 휋푖 ) prevents double-spending signature sC on (v, 푃, 휌 ) under pkC from certifier C. The first 푖 by showing that the serial numbers are computed correctly. condition in the proof statement checks that 푃 knows signature sC on the triplet (v, 푃, 휌in). The second condition checks that the new The final two equations guarantee the global consistency ofthe commitment cm′ contains the same value v. These two conditions, system: the summation equation shows that no tokens have been together with trust in the correctness of C, ensure that the token created or destroyed in this transaction; whereas the range proof corresponding to cm′ is properly derived from a token existing on shows that all outputs contain a value in the valid range, which avoids wrap-arounds. Fledger. The third condition checks that the VRF public key vpk 휋 in 6.5 The protocol token (8) Delete the internal records of cm푖 for 푖 = 1, . . . ,푚 ( ( )푛 ) This section describes the protocol sketched previously more for- and return transferred, cm푗 푗=1 . mally. The protocol has a bit registered ← false and keeps an ini- • Upon receiving (sent, 푆, 푃,푚) from Fsmt, buffer it for later tially empty list of commitments. We begin by describing the pro- processing. Respond ok to sender 푆. tocol for a user 푃 of the system. The protocol machines for parties I, C and A are easier to describe. Issuer I behaves the same as a user 푃 except when introducing new • Upon input register, if registered is set, then return. Else, tokens. More specifically: retrieve the public keys of A, C and I from F . Query reg (1) Upon init, generate a key pair (sk , pk ) ←$ skeygen(휆) F ( ) 퐼 퐼 crs from crs. Generate a VRF key pair vsk, vpk and for the signature scheme and input (register, pk ) to (register ) F 퐼 send a message , vpk to A via smt to obtain F . ( ) reg a signature sA on 푃, vpk . If all steps succeeded, then set (2) Upon (issue, v), choose randomly 휌 and compute commit- registered ← true send register to F . a-auth ment (cm, r ) ←$ commit(crs, (v, I, 휌 )) and proof 휓 ← • cm 0 Process pending messages and retrieve new data from PK {(r , 휌 ) : open(crs, cm, r , (v, I, 휌 )) = true}, where I F cm cm ledger. This is a subroutine called from functions below. and v are publicly known. This is achieved by sending – For transactions tx = (issue, v, cm,휓0, s) from Fledger, (prove, 푥,푤) to Fnizk, where 푥 = (crs, cm, v, I) and 푤 = validate 휓0 by inputting (verify, (crs, cm, v, I),휓0) to (rcm, 휌 ). Next compute a signature s ←$ sign(sk퐼 , (v, cm,휓0)) Fnizk and verify s via verify(pk , (v, cm,휓0), s). If both 퐼 and send (append, tx), with tx = (issue, v, cm,휓0, s), to checks succeed, record cm as a valid commitment. Fledger. Finally, store (cm, rcm, v, 휌 ) internally and return – tx = (transfer, (sn ,휓 )푚 , (cm )푛 ,휓 ) For 푖 2,푖 푖=1 푗 푗=1 1 , check (issued, cm). the serial numbers sn1,..., sn푚 for uniqueness, val- Certifier C signs a commitment if it finds it in a valid transaction idate 휓1 via Fnizk and verify 휓2,1, . . . ,휓2,푛 by call- in the ledger. In more detail: ing Fa-auth with input (verify, crs,휓2,푖, m) for m = (( )푚 ( )푛 ) F F 푠푛푖 푖=1, cm푗 푗=1,휓1 . If all checks succeed, then store (1) Upon init get crs from crs and input init to blindsig. ′ cm1,..., cm푛 as valid. (2) Upon receiving (request, 푃, crs , cm) from Fblindsig, check ′ – For each incoming message (sent, 푆, 푃,푚) buffered that crs = crs . Query Fledger for the entire ledger. For from Fsmt, parse 푚 as (token, cm, rcm, v, 휌 ) and test each yet unprocessed transaction tx on Fledger, validate whether the commitment is correct, i.e. whether it the proofs as described previously. Check whether cm is holds that open(crs, cm, rcm, (v, 푃, 휌 )) = true. Check marked as a valid commitment. whether there is a valid transfer transaction tx that (3) If the above check is successful, send (sign, cm) to Fblindsig. appears in Fledger and contains cm. If all checks are Registration authority A signs VRF public keys of the parties. successful, input (request, rcm, (v, 푃, 휌 )) to Fblindsig init ( ) ←$ ( ) and wait for a response s . Store the complete infor- (1) Upon , generate a key pair skA, pkA skeygen 휆 C (register ) mation in the internal list. for the signature scheme and input , pkA to F • Upon input read, if ¬registered then abort, else first process reg. retrieve F pending messages. Then return a list of all unspent assets (2) When activated, input to smt to obtain the next (cm, v) owned by the party. message. Let it be m from 푃. If no message has been signed ← ( ( ))  in 푚 out 푛  for 푃 yet, then sign sA sign skA, 푃, m and send sA • Upon input transfer, (cm ) , (v , R푗 ) , assuming 푖 푖=1 푗 푗=1 via Fsmt back to 푃. that registered, query (lookup, R푗 ) to Freg for all 푗 = 1, . . . , 푛 in order to make sure that R푗 is registered. Then process 6.6 Auditing pending messages and proceed as follows. Each user U in the system is assigned an auditor 퐴푈 , which can (1) If, for any 푖 ∈ {1, . . . ,푚}, there is no internal record decrypt all transaction information related to U. Notably, the trans- of commitment (cmin, r푖 , vin, 푃, 휌in), then abort. 푖 cm 푖 푖 action outputs owned by U and the full content of transactions (2) If Í푚 vin ≠ Í푚 vout then abort. 푖=1 푖 푗=1 푗 produced by U. We denote the set of auditors by AU. out (3) Choose uniformly a random 휌 푗 for 푗 = 1, . . . , 푛 and We formalize next our security guarantees using functional- 푗 ( ) ←$ ( ( out out)) ity F . F stores a list of registered users and an ini- compute cm푗 , rcm commit crs, v푗 , R푗 , 휌 푗 . atoken atoken = (4) Compute the serial numbers (sn , 휋 ) ← eval(vsk, 휌in), tially empty map Records and has as a session identifier sid 푖 푖 푖 ( ′) for 푖 = 1, . . . ,푚. A, C, I, AU, sid . (5) Generate proof 휓1 as in Equation (1). • Upon input init from 푃 ∈ {A, C, I } ∪ AU, output to A ← (( )푚 ( )푛 ) (initialized ) (6) Set m sn푖 푖=1, cm푗 푗=1,휓1 . For 푖 = 1, . . . ,푚 , 푃 . (This must happen for all before any- in in in thing else.) send (prove, cm , 푟푖, v , 휌 , m) to Fa-auth to obtain 푖 푖 푖 • For inputs register, read, issue and deliver see F . 휓2,푖 . token 푗 out out • Upon input (bind, U, 퐴푈 ) from A, where U is a registered (7) Send (token, cm푗 , r , v , 휌 ) to R푗 via Fsmt for cm 푗 푗 user and 퐴푈 ∈ AU is an initialized auditor, and there is not 푗 = 1, . . . , 푛 and call F with input (append, tx) ledger yet a pair (U, 퐴푈 ′) with 퐴푈 ≠ 퐴푈 ′ ∈ AU, record (U, 퐴푈 ) for tx = (transfer, (sn ,휓 )푚 , (cm )푛 ,휓 ). 푖 2,푖 푖=1 푗 푗=1 1 and output (bound, U, 퐴푈 ) to A.   • ( )푚 ( out )푛 Upon input transfer, cm푖 푖=1, v푗 , R푗 푗=1 from an hon- We then generate a NIZK proof: = est party 푃, where 푃 and all R푗 for 푗 1, . . . , 푛 are regis-  out out  tered, proceed as follows. PK v , R, 푃, 휌 , rcm, pk퐴푈 , sA, 푟1, 푟2, 푟3 : out out (1) If, for any 푖 ∈ {1, . . . ,푚}, Records[cm푖 ] = ⊥ then open(crs, cm, (v , R, 푃, 휌 ), rcm) in ′ abort, else set (v , 푃 , st푖 ) ← Records[cm푖 ]. 푖 푖 ∧ verify(pkA, (푃, pk퐴푈 ), sA) ∧ c1 = enc(pk퐴푈 , 푃;푟1) (2) If, for any 푖 ∈ {1, . . . ,푚}, st ≠ alive or 푃 ′ ≠ 푃, then 푖 푖 out abort. ∧ c2 = enc(pk퐴푈 , R;푟2) ∧ c3 = enc(pk퐴푈 , v ;푟3) Í푚 in Í푛 out (3) If = v ≠ = v then abort. 푖 1 푖 푗 1 푗 with public parameters crs and pkA, as well as cm, c1, c2, and c3 (4) Let 퐿 be an empty list. For all 푗 = 1, . . . , 푛, if R푗 or its taken from the transaction. auditor 퐴푈푗 are corrupt, then append to 퐿 the infor- Appendix C provides details on how to instantiate the above ( out) mation 푃, R푗 , v푗 . If the auditor 퐴푈 of 푃 is corrupt, protocol using well-established primitives that do not require any include the information for all inputs and all outputs. complex setup assumptions. Output (transfer, 퐿) to A. A ( ( out)푛 ) (5) Receiving from a response transfer, cm푗 푗=1 , 6.7 Security analysis [ out] ≠ ⊥ ∈ { } if Records cm푗 for any 푗 1, . . . , 푛 then This section shows that the protocol in Section 6.5 instantiates [ out] ← ( out ) abort, else set Records cm푗 v푗 , R푗 , delayed functionality Ftoken. for all 푗 ∈ {1, . . . , 푛} and for all 푖 ∈ {1, . . . ,푚} set in Theorem 6.1. Assume that COM = (ccrsgen, commit, open) is a Records[cm푖 ] ← (v , 푃, consumed). 푖 perfectly hiding and computationally binding commitment scheme. (6) Return (transferred, (cmout)푛 ) to 푃. 푗 푗=1 Assume that VRF = (vkeygen, eval, check) is a verifiable random • Upon input (audit, cm) from auditor 퐴푈 , if Records[cm] = function. Then 휋 realizes F with static corruption. Corrup- ⊥ then return ⊥. Otherwise, set (v, 푃, st) ← Records[cm]. token token tion is malicious for I and users, and honest-but-curious for C. A is If 푃 is not audited by 퐴푈 , then return ⊥, else return (v, 푃). required to be honest, but is inactive during the main protocol phase. The protocol is adapted as follows. First, each commitment also contains the identity of the previous owner. This is not technically The restriction that C is only honest-but-curious is necessary; necessary but helps prove that the auditable information is correct otherwise C can sign arbitrary commitments, even ones that are while keeping the description here compact. The binding between not stored in Fledger. The proof is deferred to Appendix B. the auditor and the user is achieved through a (structure-preserving) signature from A. A party 푃 that executes a transfer allows auditing 7 IMPLEMENTATION AND PERFORMANCE by first encrypting the following information. To evaluate our protocol, we implemented a prototype using the primitives described in Appendix C. By design, our prototype is • To its own auditor, for each input the value vin and current compatible with Hyperledger Fabric and requires minimal changes owner 푃. For each output the value vout, sender 푃, and 푗 to be integrated. This section elaborates on the integration effort receiver R푗 . • out and measures the overhead incurred by our scheme. For each output to R푗 , to the auditor of R푗 the value v푗 , sender 푃, and receiver R푗 . 7.1 Hyperledger Fabric Then 푃 includes the resulting ciphertexts in the transfer transaction, Hyperledger Fabric is a permissioned blockchain system in which and proves that the encryption is consistent with the information entities exchange messages, called transactions. A transaction is in the commitments. used to introduce either a new (chaincode in Hyper- For concreteness, consider an input described by commitment ledger Fabric terms) into the system or changes to the state of an in ′ in cm = commit(crs, (v , 푃, 푃 , 휌 ); rcm). We encrypt current owner already existing chaincode. The first process is called chaincode in- c1 = enc(pk퐴푈 , 푃;푟1) and value c2 = enc(pk퐴푈 , v;푟2). Then we stantiation, whereas the latter is referred to as chaincode invocation. generate a NIZK proof: A special type of transactions, reconfiguration transactions, is used to introduce changes to the system configuration.  in ′ in  PK v , 푃, 푃 , 휌 , sC, pk퐴푈 , sA, 푟1, 푟2 : In Hyperledger Fabric, we identify three types of participants: in ′ in (i) clients who submit transactions to the network in order to instan- verify(pkC, (v , 푃, 푃 , 휌 ), sC) tiate or invoke chaincodes, or to reconfigure the system;( ii) peers ∧ (pk , (푃, pk ), s ) ∧ c = (pk , 푃 푟 ) verify A 퐴푈 A 1 enc 퐴푈 ; 1 which execute chaincodes, validate transactions and maintain a in ∧ c2 = enc(pk퐴푈 , v ;푟2) (consistent) copy of the ledger; and( iii) orderers which jointly de- cide the order in which transactions would appear in the ledger. where pkC and pkA are public, and c1 and c2 are part of the trans- For the proper operation of the system, each instance of Hyper- action. ledger Fabric considers one or more membership service providers Similarly, for a transfer from 푃 to R and an output commitment (in short, MSPs) that issue long-term identities to parties falling un- out out cm = commit(crs, (v , R, 푃, 휌 ); rcm), we encrypt to the auditor der their authority. These identities allow system entities to securely (here we use the one of 푃) the sender c1 = enc(pk퐴푈 , 푃;푟1), the re- interact with each other; essentially, MSPs provide the required out ceiver c2 = enc(pk퐴푈 , R;푟2), and the value c3 = enc(pk퐴푈 , v ;푟3). abstractions to compute and verify signatures. The configuration of valid MSPs is included in the genesis block of each Hyperledger the prover chaincode to any. We note that we plan to extend our Fabric instance and is updated via reconfiguration transactions. prototype to allow the ledger to also validate token transactions. Hyperledger Fabric follows an execute-order-validate model. Here, More concretely, we intend to exploit the fact that Hyperledger chaincodes are speculatively executed on one or more peers upon Fabric supports pluggable transaction validation [35] that allows a client request, called chaincode proposal, prior to submitting the chaincodes to specify their own custom validation rules, in our case, resulting transaction for ordering. Execution results are signed by the custom validation would consist of verifying the ZK proofs. the peers that generated them in chaincode endorsements and are returned to the client who requested them. Endorsements (i.e. peer 7.3 Performance numbers signatures) are included in the transaction that the client constructs and sends to the ordering service. The latter orders the transac- We installed Hyperledger Fabric client and peer infrastructure on a tions it receives and outputs a first version of the ledger called raw MacBook Pro (15-inch, 2016), with 2.7 GHz Intel Core i7, and 16 GB ledger. Raw ledger is provided to the peers of the network upon of RAM. We implemented our prototype in golang, as this is the demand. Upon receiving the raw ledger, peers validate the ordered core language of Hyperledger Fabric, and used EC groups in BN256 transactions against the endorsement policy of their origin chain- curves. We instantiated both prover and certifier chaincodes on codes. An endorsement policy specifies the endorsements that a all the peers in the network, while disseminating the secret shares transaction should carry to be deemed valid. If validation completes needed for token certification only to the peers reserved for that purpose. For efficiency reasons, we used Schnorr proofs46 [ ] to successfully, then the transaction is committed to the ledger. 2 Notice that although there is a separation in Hyperledger Fabric implement some of the zero-knowledge proofs . transfer between clients and peers, there still is a communication channel We measured the time required to produce and validate a between the two, leveraged by the clients to acquire endorsements transaction as these operations are the most costly. We produced on the chaincodes they wish to invoke, and perform queries on the our results using the measurements of 100 runs of each operation. ledger state. In the following section, we show how to make use of Our results are shown in Table 1 for transfers with two inputs and this channel to extend Hyperledger Fabric with our protocol. two outputs. Although our scheme supports an arbitrary number of inputs and outputs, we opt for this combination as it is the most 7.2 Integration architecture common configuration in existing schemes. We assume that there is one certifier and that the maximum value of a token that canbe We first require that each issuer, user and auditor operates aHy- issued or transferred at anytime is capped at 216. perledger Fabric client. These clients are used to generate an issue In the performance evaluation of transaction generation and vali- or transfer transactions, submit token certification requests and dation, we present separately the overhead resulting from( i) check- read from the ledger. Along these lines, we outsource the crypto- ing that the input and outputs preserve value and type;( ii) hiding graphic operations required to generate token transactions to a the transaction graph, cf. entries token validity and serial numbers; prover chaincode in the aim of alleviating the load at the client. This (iii) and auditability. Our measurements show that the overall trans- setting assumes that each client possesses a peer that she trusts action construction time is little less than 2s, whereas transaction with the computation of the zero-knowledge proofs and serial num- validation takes a little less than 3s. Auditability is the most ex- bers. We contend that this is a reasonable assumption especially pensive operation as it requires the generation and the verification for Hyperledger Fabric that focuses on enterprise applications. of multiple proofs of correct encryption under obfuscated public We also make use of the already-existing communication proto- keys; around 2/3 of the overall computation time. Second comes the col between the clients and the peers to implement what we call, for operations that hide the transaction graph with proof generation convenience, certifier chaincode. This is a chaincode that runs only time of almost 0.5s and verification time of roughly 0.7s. This shows on a selective set of peers chosen at setup time and trusted to jointly that in applications where auditability and full privacy are not a certify valid tokens, following the protocol in Appendix D. Each priority, our solution performs relatively-well, less than 158ms for such a peer is endowed with a share of the certification signing key, transaction generation and 287ms for its verification. Our perfor- and whenever invoked, provides its share to the certifier chaincode. mance figures exclude proofs of ownership as the performance of Finally, we leverage the membership service infrastructure of Hy- those is outweighed by the Identity Mixer overhead. perledger Fabric to grant long-term identities to issuers and users. While these numbers are not yet favorable to a wide adoption, In particular, we integrate the identity mixer MSP of Hyperledger we would like to stress that the AMCL library underlying our imple- Fabric with our solution to allow privacy preserving user authenti- mentation is not optimized. An optimization in the crypto libraries cation. To assign auditors to users, we use an off-band channel to is expected to bring in a speedup of at least one order of magni- bind identity mixer user identities with auditor encryption public tude [36]. We also note that the current implementation did not keys. In a real implementation, this could be accommodated by an investigate possibilities of parallelization. 1 external identity management service, preferably distributed . We also measured the time it takes to get a token certificate. Notice that our protocol uses the ledger only as a time-stamping Table 1 shows that the computation at the user takes around 199ms, service, without any validation functionalities; those are offloaded whereas the overhead at the certifier is 123ms. indirectly to certifiers and auditors. This could be supported in Hyperledger Fabric directly by setting the endorsement policy of

2 1The auditor assignment requires structure preserving signatures, which as of now To preserve universal composability one would need to use an online extractable lack single-round distributed instantiations. variant of Schnorr proofs. token certification REFERENCES user 198.90 [1] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstanti- certifier 123.36 nos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady proof generation proof validation Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula overall computation 1992.844 2885.134 Stathakopoulou, Marko Vukolić, Sharon Weed Cocco, and Jason Yellick. Hyper- in-out consistency 157.43 287.21 ledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, EuroSys ’18, pages 30:1–30:15, token validity 263.02 322.34 New York, NY, USA, 2018. ACM. serial number 208.24 452.55 [2] Mihir Bellare, Alexandra Boldyreva, Anand Desai, and David Pointcheval. Key- auditability 1361.99 1823.01 privacy in public-key encryption. In Colin Boyd, editor, Advances in Cryptology – ASIACRYPT, volume 2248 of LNCS, pages 566–582. Springer, 2001. Table 1: Performance numbers of token certification and transfer in mil- [3] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, liseconds (ms). Transaction size is a little over 63KB; this figure however can Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments be further optimized. from bitcoin. In IEEE Symposium on Security and Privacy, pages 459–474. IEEE, 2014. [4] Benedikt Bünz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh. Zether: 8 CONCLUSION Towards privacy in a smart contract world. IACR Cryptology ePrint Archive, 2019. We described a privacy-preserving and auditable token manage- [5] Jan Camenisch, Rafik Chaabouni, and abhi shelat. Efficient protocols forset membership and range proofs. In Josef Pieprzyk, editor, Advances in Cryptology ment scheme for permissioned blockchains, which is instantiated — ASIACRYPT, volume 5350 of LNCS, pages 234–252. Springer, 2008. without complex setup and relies only on falsifiable assumptions. [6] Jan Camenisch, Manu Drijvers, and Björn Tackmann. Multi-protocol UC and its use for building modular and efficient protocols. Cryptology eprint archive, Through the use of structure-preserving primitives, we achieve report 2019/065, January 2019. practical transaction size and near-practical computation times that [7] Jan Camenisch, Maria Dubovitskaya, Kristiyan Haralambiev, and Markulf are expected to become practical once an optimized implementation Kohlweiss. Composable and modular anonymous credentials: Definitions and practical constructions. In Tetsu Iwata and Jung Hee Cheon, editors, Advances in of the underlying schemes is available. Cryptology – ASIACRYPT, volume 9453 of LNCS, pages 262–288. Springer, 2015. [8] Jan Camenisch, Robert R. Enderlein, Stephan Krenn, Ralf Küsters, and Daniel Rausch. Universal composition with responsive environments. In Jung Hee Cheon and Tsuyoshi Takagi, editors, Advances in Cryptology – ASIACRYPT, volume 10032 of LNCS, pages 807–840. Springer, 2016. [9] Jan Camenisch and Els Van Herreweghen. Design and implementation of the idemix anonymous credential system. In ACM CCS, pages 21–30. ACM, 2002. [10] Jan Camenisch, Susan Hohenberger, and Anna Lysyanskaya. Compact e-cash. In Ronald Cramer, editor, Advances in Cryptology – EUROCRYPT 2005, pages 302–321, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg. [11] Jan Camenisch, Susan Hohenberger, and Anna Lysyanskaya. Balancing ac- countability and privacy using e-cash (extended abstract). In Roberto De Prisco and Moti Yung, editors, Security and Cryptography for Networks, pages 141–155, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg. [12] Jan Camenisch and Markus Stadler. Efficient group signature schemes for large groups. In Burton S. Kaliski Jr., editor, Advances in Cryptology — CRYPTO, volume 1294 of LNCS, pages 410–424. Springer, 1997. [13] Ran Canetti. Universally composable security: A new paradigm for cryptographic protocols. In Foundations of Computer Science. IEEE, 2001. [14] Ran Canetti. Universally composable security: A new paradigm for cryptographic protocols. Cryptology eprint archive, report 2000/067, December 2018. [15] Ran Canetti, Yevgeniy Dodis, Rafael Pass, and Shabsi Walfish. Universally com- posable security with global setup. In Salil Vadhan, editor, Theory of Cryptography, volume 4392 of LNCS, pages 61–85. Springer, 2007. [16] Ran Canetti and Hugo Krawczyk. Universally composable notions of key ex- change and secure channels. In Lars R. Knudsen, editor, Advances in Cryptology — EUROCRYPT, volume 2332 of LNCS, pages 337–351. Springer, 2002. [17] Ethan Cecchetti, Fan Zhang, Yan Ji, Ahmed Kosba, Ari Juels, and Elaine Shi. Solidus: Confidential transactions via PVORM. In ACM CCS, pages 701–717. ACM, 2017. [18] David Chaum. Blind signatures for untraceable payments. In David Chaum, Ronald L. Rivest, and Alan T. Sherman, editors, Advances in Cryptology, pages 199–203, Boston, MA, 1983. Springer US. [19] Yu Chen, Xuecheng Ma, Cong Tang, and Man Ho Au. PGC: decentralized confidential payment system with auditability. Cryptology eprint archive, May 2019. [20] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable random function with short proofs and keys. In Serge Vaudenay, editor, Public Key Cryptography — PKC, volume 3386 of LNCS, pages 416–431. Springer, 2005. [21] Taher ElGamal. A public-key cryptosystem and a signature scheme based on discrete logarithms. IEEE Transactions on Information Theory, 31(4):469–472, 1985. [22] Prastudy Fauzi, Sarah Meiklejohn, Rebekah Mercer, and Claudio Orlandi. Quisquis: A new design for anonymous . IACR Cryptology ePrint Archive, 2018. [23] Christina Garman, Matthew Green, and Ian Miers. Accountable privacy for decentralized anonymous payments. In Jens Grossklags and Bart Preneel, editors, Financial Cryptography and Data Security, volume 9603 of LNCS, pages 81–98. Springer, 2016. [24] Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosystems. Journal of Cryptology, 20(1):51–83, 2007. [25] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. Journal of Computer and System Sciences, 28(2):270–299, 1984. [26] Shafi Goldwasser, Silvio Micali, and Ron Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal of Computing, 17(2):281–308, April 1988. [27] Jens Groth. Efficient fully structure-preserving signatures for large messages. In Tetsu Iwata and Jung Hee Cheon, editors, Advances in Cryptology — ASIACRYPT, volume 9452 of LNCS, pages 239–259. Springer, 2015. [28] Jens Groth, Rafail Ostrovsky, and Amit Sahai. New techniques for noninteractive zero-knowledge. Journal of the ACM, 59(3), June 2012. [29] Jens Groth and Amit Sahai. Efficient non-interactive proof systems for bilinear groups. In Nigel Smart, editor, Advances in Cryptology — EUROCRYPT, volume 4965 of LNCS, pages 415–432. Springer, 2008. [30] https://github.com/ethereum/wiki/wiki/White Paper. [31] https://www2.deloitte.com/ch/en/pages/risk/articles/security-controls-for- blockchain applications.html. [32] https://www2.deloitte.com/content/dam/Deloitte/cz/Documents/financial- services/cz-2018-deloitte-global-blockchain survey.pdf, 2018. [33] https://www2.deloitte.com/content/dam/Deloitte/lu/Documents/financial- services/lu-tokenization-of-assets-disrupting-financial industry.pdf. [34] https://www.goquorum.com/. [35] Hyperledger Fabric Maintainers. Hyperledger Fabric pluggable endorse- ment and validation. https://hyperledger-fabric.readthedocs.io/en/release- 1.4/pluggable_endorsement_and_validation.html. [36] Vlad Krasnov. Go crypto: bridging the performance gap. https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/, May 2015. [37] Gregory Maxwell. CoinJoin: Bitcoin privacy for the real world. bitcointalk.org, August 2013. [38] Ian Miers, Christina Garman, Matthew Green, and Aviel D. Rubin. Zerocoin: Anonymous distributed e-cash from bitcoin. In IEEE Symposium on Security and Privacy, pages 397–411. IEEE, 2013. [39] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. http://bitcoin.org/bitcoin.pdf, 2008. [40] Neha Narula, Willy Vasquez, and Madars Virza. zkledger: Privacy-preserving auditing for distributed ledgers. In Symposium on Networked Systems Design and Implementation, pages 65–80. USENIX, 2018. [41] Torben Pryds Pedersen. Non-interactive and information-theoretic secure ver- ifiable secret sharing. In Joan Feigenbaum, editor, Advances in Cryptology — CRYPTO, volume 576 of LNCS, pages 129–140. Springer, 1991. [42] Andrew Poelstra, Adam Back, Mark Friedenbach, Gregory Maxwell, and Pieter Wuille. Confidential assets. In Aviv Zohar, Ittay Eyal, Vanessa Teague, Jeremy Clark, Andrea Bracciali, Federico Pintore, and Massimiliano Sata, editors, Fi- nancial Cryptography and Data Security, volume 10958 of LNCS, pages 43–63. Springer, 2018. [43] David Pointcheval and Olivier Sanders. Short randomizable signatures. In Kazue Sako, editor, Proceedings of the Cryptographers Track at the RSA Conference, volume 9610 of LNCS, pages 111–126. Springer, 2016. [44] David Pointcheval and Olivier Sanders. Reassessing security of randomizable signatures. In Nigel Smart, editor, Topics in Cryptology — CT-RSA, volume 10808 of LNCS, pages 319–338. Springer, 2018. [45] Tomas Sander and Amnon Ta-Shma. Auditable, anonymous electronic cash. In Michael Wiener, editor, Advances in Cryptology — CRYPTO’ 99, pages 555–572, Berlin, Heidelberg, 1999. Springer Berlin Heidelberg. [46] C. P. Schnorr. Efficient signature generation by smart cards. Journal of Cryptology, 4(3):161–174, Jan 1991. [47] Alberto Sonnino, Mustafa Al-Bassam, Sherar Bano, Sarah Meiklejohn, and George Danezis. Coconut: Threshold issuance selective disclosure credentials with applications to distributed ledgers. arXiv:1802.07344, August 2018. [48] Nicolas van Saberhagen. CryptoNote v 2.0. https://cryptonote.org/whitepaper. pdf, October 2013. A FUNCTIONALITIES Secure message transmission functionality Fsmt We describe here in more detail some ideal functionalities that are Functionality Fsmt is for transmitting messages in a secure and commonly used and that we therefore omitted from the preliminar- private manner. ies of the paper. • Upon input (send, R,푚) from a party 푆: – If both 푆 and R are honest, provide a private delayed crsgen (sent, 푆, R,푚) R Functionality F output to . crs – If at least one of 푆 and R is corrupt, provide a public F crs is parametrized by a probabilistic algorithm crsgen. Initially, delayed output (sent, 푆, R,푚) to A’s queue. it sets crs ←$ crsgen(휆). (1) On input read from a party 푃, return crs to 푃. Figure 8: Secure message transmission functionality

Figure 6: Common reference string

Canetti and Krawczyk [16], our functionality additionally provides A.1 Common reference string privacy and hides the parties that are involved in the transmission. Functionality Fcrs is parametrized by a CRS generator crsgen, which on input of security parameter 휆 samples a fresh random ( ) crs ←$ (휆) skeygen,sign,verify string crsgen . Functionality Fsig ′ Functionality Fsig requires that sid = (푆, sid ), where 푆 is the 푅 C Functionality Fnizk party identifier of the signer. Set , initially empty, specifies the set of currently corrupted parties. The functionality keeps a set Fnizk is parametrized by a relation 푅 for which we can efficiently check membership. It keeps an initially empty list 퐿 of proven Σ of properly signed messages. statements and a list 퐿0 of proofs that do not verify. (0) Upon the first activation from 푆, run (1) On input (prove,푦,푤) from a party 푃, such that (푦,푤) ∈ (sk, pk) ←$ skeygen(휆), where 휆 is obtained from 푅a, send (prove,푦) to A. the security parameter tape, and store (sk, pk). (2) Upon receiving a message (done,휓) from A, with 휓 ∈ (1) Upon input pubkey from party 푃, output (pubkey, pk) { }∗ ( ) (done ) to 푃. 0, 1 , record 푦,휓 in 퐿 and send ,휓 to 푃. ∗ (3) Upon receiving (verify,푦,휓) from some party 푃, check (2) Upon input (sign,푚) from party 푆 with 푚 ∈ {0, 1} , whether (푦,휓) ∈ 퐿, then return 1 to 푃, or whether compute s ←$ sign(sk,푚). Set Σ ← Σ ∪ {푚} and output ( ) ∈ 푠 to 푆. 푦,휓 퐿0, then return 0 to 푃. If neither, then out- ′ ′ ′ (verify ) A (3) Upon input (verify, pk ,푚 , 푠 ) from party 푃, compute put ,푦,휓 to and wait for receiving answer ′ ′ ′ ′ ′ (witness,푤). Check (푦,푤) ∈ 푅 and if so, store (푦,휓) in 푏 ← verify(pk ,푚 , 푠 ). If 푆 ∉ C ∧ pk = pk ∧푏 ∧푚 ∉ Σ then output (result, 0) to 푃. Else output (result,푏) to 퐿, else store it in 퐿0. If (푦,휓) is valid, then output 1 to 푃, else output 0. 푃. (4) Upon input (corrupt, 푃) from the adversary, set C ← a Inputs that do not satisfy the respective relation are ignored. C ∪ {푃}. If 푃 = 푆, then additionally output sk to A.

Figure 7: Non-interactive zero-knowledge functionality Figure 9: Signature functionality based on the one described by Groth et al. [28].

A.2 Non-interactive zero-knowledge A.4 Digital signatures Our functionality F is adapted from the work of Groth et al. [28], nizk We use the variant of the signature functionality F that was with a few modifications, most of which are mainly stylistic. The sig introduced by Camenisch et al. [6]. This version of the functionality most relevant difference is that we store aset 퐿 of false statements 0 is compatible with the modular NIZK proof technique introduced that have been verified. We need this to ensure that a statement that in the same paper. was evaluated as false by one honest party will also be evaluated as false by all other honest parties. Otherwise Fnizk has the two expected types of inputs prove and verify, and the adversary is A.5 Distributed key generation allowed to delay proof generation unless Fnizk is used in the context Functionality Fdkg idealizes a distributed key-generation proto- of responsive environments [8]. col such as, for discrete-log based schemes, the one of Gennaro et al. [24]. The simplified functionality given in Figure 10 isnot A.3 Secure message transmission directly realizable since it does not model for example that the Functionality Fsmt models a secure channel between a sender 푆 communication may be delayed or prevented by the adversary. We and a receiver R. In comparison to the functionality introduced by decided to still use this version to simplify the overall treatment. tkeygen – For all valid transactions tx where in the meantime the Functionality Fdkg corresponding private message (request, 푃, crs, cm푗 ) F dkg is parameterized by a PPT algorithm tkeygen. The session is delivered to Fblindsig, input (deliver, cm푗 ) to Ftoken. identifier sid specifies the total number of parties 푛 and the thresh- 푗 out out • When A instructs S to deliver a message (token, cm푗 , r , v , 휌 ) old bound 푡. cm 푗 푗 anonymously to its receiver, simulate the corresponding • Upon input init from a party C푖 : private delayed message (request, 푃, crs, cm푗 ) from Fblindsig. – If no keys (sk ,..., sk푛, pk) are stored yet, generate 1 • Upon receiving (read?, 푃) from Ftoken, process pending (sk ,..., sk푛, pk) ←$ tkeygen(휆, 푛, 푡). 1 messages and return (read!, 푃) to Ftoken. – Return (sk푖, pk) to C푖 . • On receiving (issue, v) from Ftoken, first process pend- ing messages. Then, generate a new all-zero commitment ∗ ∗ Figure 10: Distributed key generation functionality (cm , rcm) ←$ commit(crs, (0, 0, 0)). Next, emulate an out- ∗ put (prove,푦) from Fnizk for the statement푦 = (crs, cm , v, I) ( ∗) and proceed upon an input done,휓0 for the same instance ∗ B SECURITY PROOF of Fnizk. Emulate the signature s as in Fsig, storing the re- ( ∗ ∗ ∗) This section proves Theorem 6.1. We use the composition result spective instance as a record. Append issue, v, cm ,휓0 , s ∗ of [6] to prove this, since we want to prove correctness of the to the internal ledger. Input (issue, cm ) to Ftoken. evaluation of the verification algorithm. • Upon receiving (transfer,푚, 푛, 퐿) from Ftoken, first pro- cess pending messages. For each 푖 = 1, . . . ,푚 generate a Proof. We use the proof technique of Camenisch et al. [6] in ∗ random serial number sn푖 . Then proceed as follows for instantiating the functionalities Fnizk, Fsig, and Fblindsig in a way 푗 = 1, . . . , 푛. If there is no entry for 푗 in 퐿, then generate a that F can call out to F and F for the verification of ∗ 푗 nizk sig blindsig commitment (cm , r ) ←$ commit(crs, (0, 0, 0)). If there signatures. This has the advantage that the respective clauses in 푗 cm is an entry (푗, 푃, R , vout), then randomly sample 휌out and the statement are ideally verified. 푗 푗 푗 ∗ 푗 ( ) ←$ ( ( out out)) We then need to describe a simulator. Simulator S emulates compute cm푗 , rcm commit crs, v푗 , R푗 , 휌 푗 . Next, functionalities Fledger, Freg, Fa-auth, Fnizk, Fsig, and Fsmt. To emulate the output (prove,푦) from Fnizk for instance 푦 = F S ( ( ∗)푛 ( ∗)푚 ) ∗ emulate ledger, manages an initially empty internal ledger and pkC, crs, cm푗 푗=1, pkA, sn푖 푖=1 and record the proof 휓1 allows A to read it via retrieve or append messages as described A ∗ ∗ returned by . Emulate the proofs 휓2,1, . . . ,휓2,푚 as in below. S initially sets initialized ← false. We start by describing F ( ( ∗ )푚 ( ∗)푛 ∗) a-auth. Append transfer, sn푖 ,휓2,푖 푖=1, cm푗 푗=1,휓1 to the behavior of S upon outputs provided by Fledger. the internal ledger and emulate transmission of 푛 messages • Upon receiving (initialized, 푃) for 푃 ∈ {A, C, I }, gen- ( ∗ 푗 out) F of the same length as token, cm푗 , rcm, v푗 , 휌 푗 on smt erate a signature key pair for the respective party and (i.e., append the length to the internal queue). Respond with simulate the public key of the respective party being reg- ( ( ∗)푛 ) F A transfer, cm푗 푗=1 to token. When delivers a mes- istered at Freg. After receiving this for A, C and I, set ∗ sage on Fsmt, input (deliver, cm ) for the corresponding initialized ← true. 푗 푗 to F . • Upon receiving (registered, 푃) from F , mark 푃 as token token • Upon input (append, 푥, 푃 ′) from A for a corrupt 푃’, append registered and generate output (registered, 푃) as a mes- 푥 to the ledger and mark for delayed processing. Return to sage from F to A. a-auth A. • Processing of pending messages (on several occasions as depicted below) for party 푃: for every record tx marked for If S obtains from A a query to Fa-auth in the name of a corrupt delayed processing, proceed as follows. party 푃 that is marked as registered, then S internally handles the prove verify F A – If I is corrupt and tx = (issue, I, v, cm0,휓0, s), then inputs and just like a-auth. If provides an input 푥 F 푃 issue (verify,푦,휓0) to A as an output of Fnizk, with message to smt on behalf of a corrupted party , then the mes- 푥 = (token, cm, r , v, 휌 ) 푦 = (crs, cm0, v, I), and expect as response a witness sage is ignored unless it is of the format cm . in If it has the right format, then S checks whether the corresponding 푤. If 푤 = (rcm, 휌 ) is valid for cm0, and signature s transaction tx exists on F ; if it does, then input the respective is valid according to the simulated instance of Fsig, ledger deliver message to F . If such a transaction does not exist, then provide the input (issue, v, cm0) to Ftoken. token ( ( )푚 ( )푛 ) then store the message 푥 for later. – If tx = transfer, sn푖,휓2,푖 푖= , cm푗 푗= ,휓1 , issue 1 1 Our goal is now to prove that if the commitment and the VRF are (verify,푦,휓1) to A as an output of Fnizk, with 푦 = ( ( )푛 ( )푚 ) secure, then the ideal and real experiments are indistinguishable. pkC, crs, cm푗 푗=1, pkA, sn푖 푖=1 . Expect as response in in 푚 We prove this by describing a sequence of experiments, where from adversary A a witness 푤 = ((s푖, v , 휌 , 휋푖 ) , 푖 푖 푖=1 exec0 is the real experiment and we transform it step-by-step into ( 푗 out out)푛 ) ( ) 푃, sA, R푗 , rcm, v푗 , 휌 푗 푗=1 . If 푤 and 휓2,1, . . . ,휓2,푛 the ideal experiment, showing for each adjacent pair of steps that are valid according to the simulated instance of Fa-auth, they are indistinguishable. The overall statement then follows via and corresponding messages have been sent to re- the triangle inequality. spective receivers, then mark tx as valid. Send a re- Experiment exec1 is almost the same as exec0 but commitments ( ( )푚 ( out out)푛 ) quest transfer, 푃, cm푖 푖=1, R푗 , v푗 , cm푗 푗=1 to generated during (issue, v) at an honest party 푃 as well as com- Ftoken. mitments generated during (transfer,... ) at an honest party 푃, where receiver R is also honest, are replaced by commitments gen- identity and emulates the behavior in the real protocol erated via (cm, rcm) ←$ commit(crs, (0, 0, 0)). Functionality Fnizk where C also learns both the commitment and the identity is changed so that it does not actually check the input of honest of the receiver. parties. For adversarial transfers sent to the party via Fsmt, it Experiments exec0 and exec1 are equivalent since the commit- may mean that the message sent on Fsmt is not proper ment is perfectly hiding and therefore the distribution of the output (so it is ignored by both 휋token and S), or that it parses to the adversary is unchanged. As all inputs of the honest parties’ correctly but it does not have a corresponding transaction ∗ protocols to Fnizk are correct, omitting the checks has no effect. in Fledger (in the sense that the commitment cm in the Experiment exec2 is almost the same as exec1 but serial num- message does not exist there—then it is also ignored), or bers output by honest parties are replaced by uniformly random that both message and transaction can be found, in which values from the same set. Experiments exec2 and exec1 are indis- case the view of the party changes when the tokens are tinguishable because of the pseudorandomness of VRF, which is found. easily proved by reduction. Note that the environment never sees The only difference between the two above executions is when honestly generated proofs. the adversary fabricates a transaction in the name of a corrupt party In the following, we describe the response to environment queries that makes a state transition that is different from the one that is in both exec and the ideal experiment and point out the differ- 2 done in Ftoken. Let us first consider issue transactions, where the ences. We assume that the state in terms of valid commitments statement is 푦 = (crs, cm∗, v, I). When an honest party verifies the is the same prior to the environment’s query, and show that the ∗ ∗ proof with Fnizk, then A has to provide a proper witness (rcm, 휌 ) output to the query is the same and the state in terms of valid com- ∗ ∗ ∗ such that open(crs, cm , (v, I, 휌 ), rcm) = true. mitments remains consistent. The consistency of the input-output ( ( ∗ )푚 ( ∗)푛 ∗) Consider transaction tx = transfer, sn푖 ,휓2,푖 푖=1, cm푗 푗=1,휓1 behavior is relatively straightforward to check for most inputs. We ∗ input by the adversary. When휓1 is verified by the honest party, then focus here on the ones used in transfer. A ( ( ∗)푛 ( ∗)푚 ) is given the statement푦 = pkC, crs, cm푗 푗=1, pkA, sn푖 푖=1 and • On input (transfer,... ) from an honest user 푃, if not (( in in )푚 ( 푗 out out)푛 ) sends a witness푤 = s푖, v푖 , 휌푖 , 휋푖 푖=1, 푃, sA, R푗 , rcm, v푗 , 휌 푗 푗=1 both of 푃 and all R1,..., R푛 are registered, then the request as a response, that satisfies the following PK-statement is ignored in both cases. Also if not all transferable com- mitments cm1,..., cm푚 exist and are associated to user 푃,  in in 푚 푗 out out 푛  PK (s푖, v푖 , 휌푖 , 휋푖 )푖=1, 푃, sA, (R푗 , rcm, v푗 , 휌 푗 )푗=1 : both invocations abort. The protocol 휋 then gener- token in in ′ ′ ∀푖 ∈ {1, . . . ,푚} : verify(pk , (v , 푃, 휌 ), s푖 ) ates new commitments cm1,..., cm푛 and send them for the C 푖 푖 proof to Fnizk, which requests a proof 휓1 from A. Upon re- ∗ out out 푗 ∧ ∀푗 ∈ {1, . . . , 푛} : open(crs, cm푗 , (v푗 , R푗 , 휌 푗 ), rcm) turn, 휋token generates an additional proof 휓2 via Fa-auth, ∧ verify(pk , (푃, vpk), sA) sends the transaction (transfer,... ) to Fledger and the A F in token messages to smt. If any R푗 is corrupt, this latter ∧ ∀푖 ∈ {1, . . . ,푚} : check(vpk, 휌푖 , sn푖, 휋푖 ) 푗 out out invocation means that A learns (rcm, v , 휌 ) as well as 푚 푚 푗 푗 ∑︁ in ∑︁ out the sender 푃 via Fsmt in addition. ∧ v푖 = v푗 = = The functionality Ftoken provides either just푚, 푛—if all 푖 1 푗 1 ( out) out R1,..., R푗 are honest—or the values 푗, 푃, R푗 , v푗 for each ∧ ∀푗 ∈ {1, . . . , 푛} : 0 ≤ v푗 ≤ max . corrupt R푗 . In the first case, S generates a commitment As verify(pk , (vin, 푃, 휌in), s ) are evaluated via F , and C to all-zero messages and requests the proof 휓1 from A C 푗 푖 푖 blindsig via Fnizk-interaction, in the second case S has all the data checks the correctness of crs, we also know that s1,..., s푚 were 푖 in in available to perform the same computations as the protocol. generated for inputs (request, crs, rcm, (v푖 , 푃, 휌푖 )), and the com- in in 푖 The output distribution is the same since in both cases mitment cm푖 = commit(crs, (v푖 , 푃, 휌푖 ); rcm) indeed exists on the the commitment is an all-zero commitment and the serial ledger. Then either cm푖 was created during a previous transaction in in number is uniformly random. with the same input (v푖 , 푃, 휌푖 ) or we can turn Z into an adversary • Processing of pending transactions. For all new (possibly that breaks the binding property of COM. adversarial) transactions on Fledger, the honest parties first As verify(pkA, (푃, vpk), sA) is evaluated via a call to Fsig, and attempt to verify the proofs via Fnizk. For adversarially- the correctness of both Fsig and the honesty of A implies that vpk is generated proofs, the first attempt for each such proof may the unique VRF public key associated to 푃. So at this point we know in in ∗ lead to a message from Fnizk requesting the witness from that vpk and 휌푖 are correct. As check(vpk, 휌푖 , sn푖 , 휋푖 ) = true, A. The same messages are generated by S, which then ∗ in either (sn푖 , _) ← eval(vsk, 휌푖 ) or we can turn Z into an adversary records the messages and issues the proper requests to ∗ against the soundness of VRF. This means that sn푖 is also correct, Ftoken. (Note that this processing in Ftoken takes place at no double-spending occurred. The last two lines mean that the sum this point in time, but the timing is indistinguishable from of all output values and the sum of all input values are the same, that in the protocol as each honest user input leads to that so the overall value is preserved (and the input provided by the user processing the pending transactions in the protocol.) simulator is accepted by Ftoken). For (passively) corrupt C, if a commitment cm is de- The construction has negligible correctness error due to collision livered to the receiver, the simulator learns the receiver’s of serial numbers. □ C INSTANTIATION on input (prove,푦,푤) at Fnizk with 푦 = (cm, ℎ,푢, 푎1, ) (( )ℓ ) . . . , 푎ℓ,푏1, . . . ,푏ℓ and 푤 = 푚푖, 푟푖 푖=1, rcm . C.1 Pedersen commitments ℓ (4) Call Fsmt with (send, C, (휁, crs, cm,푢, (푎푖,푏푖 ) )). The commitment scheme is instantiated with Pedersen commit- 푖=1 • Upon receiving (sent, 푃, (휁, crs, cm,푢, (푎 ,푏 )ℓ )) from F , ments [41] on multiple values. Consider a group G and generators 푖 푖 푖=1 smt signer C proceeds as follows: g , g ,..., g ∈ G such that the relative discrete logarithms between 0 1 ℓ (1) Verify 휁 via F and compute ℎ ← 퐻 (cm). If veri- the g are not known. A commitment to a vector (푥 , . . . , 푥 ) ∈ nizk G 푖 1 ℓ fication fails, input (send, 푃, ⊥) to F and stop. {1,..., |G|}ℓ of inputs is computed by choosing a uniformly ran- smt (2) Store (휁, crs, cm,푢, (푎 ,푏 )ℓ , ℎ) internally and output dom 푟 ∈ {1,..., |G|} and computing (cm, r ) ← (g푟 g푥1 ··· g푥ℓ , 푟). 푖 푖 푖=1 cm 0 1 ℓ message (request, 푃, crs, cm). Pedersen commitments are perfectly hiding and computationally • Upon input (sign, cm): binding under the discrete-logarithm assumption in group G. 푦 ¯ ← 푥 Îℓ 푖 푟¯ 푥 Îℓ m푖 푦푖 (1) Compute 푏 ℎ 푖=1 푏푖 = g ℎ 푖=1 ℎ and ← Îℓ 푦푖 = 푟¯ C.2 Pointcheval-Sanders (PS) signatures 푎¯ 푖=1 푎푖 푢 . (2) Call F with (send, 푃, (푎,¯ 푏¯)). We use the signature scheme of Pointcheval and Sanders [43] to smt • Upon receiving (sent, C,푚¯) from F , receiver 푃 pro- implement the blind signature used for token certification. The smt ceeds as follows: scheme operates in an asymmetric pairing setting with groups (1) If푚¯ cannot be parsed as (푎,¯ 푏¯) ∈ G2 output (result, ⊥) G1 and G2 of order 푝, with target group GT and bilinear map 1 G × G → G ∈ G and stop. 푒 : 1 2 T. Key generation skeygen chooses 푔˜ 2 ? ℓ+1 ′ ← ¯ −푧 ( ˜ Îℓ ˜ m푖 ) and (푥,푦1, . . . ,푦ℓ ) ∈ Z and sets sk ← (푥,푦1, . . . ,푦ℓ ) and pk ← (2) Compute ℎ 푏푎¯ and check 푒 ℎ, 푋 푖=1 푌푖 = 푝 ′ 푥 푦1 푦ℓ ˜ ˜ ˜ 푒(ℎ , g˜). If the check fails, output (result, ⊥) and stop. (푔,˜ 푔˜ ,푔˜ ,...,푔˜ ) = (푔,˜ 푋, 푌1,..., 푌ℓ ). A signature s on message ′ ℓ Else output (result, (ℎ, ℎ )). vector (푚1, . . . ,푚ℓ ) ∈ Z푝 is computed as sign(sk, (푚1, . . . ,푚ℓ )) ← 푥+Í 푦 푚 As in Coconut [47], we use a deterministic variant of Pointcheval- 푠 = (ℎ, ℎ 푗 푗 푗 ) with ℎ randomly-chosen in G1. Verification ( ) Sanders signatures. Namely, generator ℎ is not selected randomly of signature s = s1, s2 is performed by checking s1 ≠ 1G1 and 푚 in G , rather it is computed as the hash of commitment cm. The 푒(s , 푋˜ Î 푌˜ 푗 ) = 푒(s ,푔˜). 1 1 푗 푗 2 reason behind this slight modification is to enable a non-interactive PS signatures are CMA-secure under an interactive computa- distributed signature (i.e. signers do not need to interact), see Ap- tional assumption. In follow-up work, Pointcheval and Sanders [44] pendix D for further details. It is easy to show that the security of showed that the scheme can be modified to be secure under a this variant holds in the random-oracle model, cf. [47]. non-interactive assumption, by adding and signing another ran- dom element m0. For simplicity, we use the original version in this C.4 Groth signatures instantiation. We use Groth’s structure preserving signatures [27] to bind a user C.3 Certification through blind signatures public key to an auditor public key. The signature scheme oper- ates in a pairing setting with groups G , G and G , and mes- F 1 2 T The functionality blindsig is instantiated with the following pro- sages in G . Let g and g˜ be random generators of G and G {F F F } 1 1 2 tocol 휋blindsig, which operates in the nizk, reg, smt -hybrid respectively. Key generation skeygen(휆, ℓ) selects a vector sk = model. 휋blindsig is based on the Coconut system proposed by Son- ℓ (푥,푦1, . . . ,푦ℓ−1) ←$ Z and a random generator ℎ ←$ G1, and com- nino et al. [47], with the only difference that we sign a vector of 푝 putes pk ← (ℎ, 푋,˜ 푌˜ ,..., 푌˜ ) = (ℎ, g˜푥, g˜ 푦1 ,..., g˜ 푦ℓ−1 ). Signature messages instead of a single message. 1 ℓ−1 sign(sk, (m1,..., mℓ )) selects uniformly at random 푟 ←$ Z푝 , com- Let 퐻G : G1 → G1 denote a cryptographic hash function mod- ← 1/푟 ← ( 푥 )푟 ← ( 푥 Îℓ−1 푦푖 )푟 eled as a random oracle. putes 푎˜ g˜ , 푏 ℎg , and 푐 ℎ mℓ 푖=1 m푖 , and sets s ← (푎,푏,˜ 푐). Verification of signature s = (푎,푏,˜ 푐) for messages • Upon input init, signer C generates a new key pair (sk, pk) (m ,..., m ) checks two pairing equations 푒(푏, 푎˜) = 푒(ℎ, g˜)푒(g, 푋˜ ) with sk = (푥,푦 , . . . ,푦 ) and pk = (푔,˜ 푋,˜ 푌˜ ,..., 푌˜ ), and 1 ℓ 1 ℓ 1 ℓ and sends (register, pk) to Freg. ℓ−1 • pubkey (query ) F Ö Upon input , party 푃 sends , C to reg and 푒(푐, 푎˜) = 푒(ℎ, 푋˜ )푒(mℓ, g˜) 푒(m푖, 푌˜푖 ). outputs the result. 푖=1 • Upon input (request, crs, r , (m ,..., m )), 푃 proceed as cm 1 ℓ C.4.1 Dodis-Yampolskiy VRF. We use the VRF of Dodis and follows. 푧 Yampolskiy [20] that operates in the pairing setting. Key genera- (1) Pick 푧 ←$ Z푝 and compute 푢 ← g . Compute cm ← sk tion vkeygen(휆) chooses a random sk ←$ Z and sets pk ← g . rcm Îℓ m푖 ← ( ) 푝 g 푖=1 g푖 and ℎ 퐻G cm . × 0 Evaluation eval(sk, 푥) aborts if sk + 푥 ∉ Z푝 . It computes output = ←$ Z ← 푟푖 (2) For each 푖 1, . . . , ℓ, choose 푟푖 푝 , 푎푖 푢 , and /(sk+푥) /(sk+푥) 푚 푟 푦 ← 푒(g, g˜)1 ∈ G and proof 휋 ← 푔˜1 ∈ G . Veri- 푏푖 ← ℎ 푖 g 푖 . T 2 ( ) ( ) ( · (3) Obtain the proof fication check pk, 푥,푦, 휋 checks whether 푒 g, 휋 = 푦 and 푒 pk g푥, 휋) = 푒(푔,푔˜); if so it outputs 푏 = 1.  ℓ  휁 ← PK (푚푖, 푟푖 )푖=1, rcm : ℓ ℓ C.5 Groth-Sahai NIZK Û Ö ( 푟푖 ∧ 푚푖 푟푖 ) ∧ rcm m푖 푎푖 = 푢 푏푖 = ℎ g cm = g0 g푖 Since all equations we have to verify — for the Pointcheval-Sanders 푖=1 푖=1 signatures, the Pedersen commitments, the Groth signatures, and Î 푖 the Dodis Yampolskiy VRF — are defined in terms of bilinear groups, • Compute Lagrange coefficients 휆푗 = 푖 ∈푆\푗 푖−푗 for all we propose to use Groth-Sahai proofs [29] to instantiate Fnizk in 푗 ∈ 푆. our solution. ′ Î ′ 휆푗 • Compute and output (ℎ, ℎ = 푗 ∈푆 ℎ푗 ). Protocol 휋 from Appendix C.3 has to be modified as follows: C.6 ElGamal public-key encryption blindsig • Instead of generating a key locally at C, all signers C1,..., C푛 We use ElGamal encryption [21]. Key generation ekeygen(휆) chooses together use Fdkg to generate the set of keys. Signer C1 a uniformly random exponent sk ←$ {1,..., |G|} and computes registers the public key pk at Freg. ← sk ( ) pk g . Encryption enc pk, m chooses a uniformly random • Requestor 푃 sends the request message to parties C1,..., C푛 푟 푟 푟 ←$ {1,..., |G|} and computes c ← (g , pk m). Decryption dec(sk, c) until it has collected 푡 signatures that verify. It then uses ( ) ← −sk with c = c1, c2 computes m c2c1 . The encryption scheme is combine to combine that into a single signature that veri- semantically secure3 and key private under the decisional Diffie- fies relatively to pk. Hellman assumption. Theorem D.1. Let 푛 ∈ N and 푡 < 푛. The above-described variant C.7 Range proofs of the protocol realizes the threshold variant of Fblindsig. Our protocol requires range proofs to ensure that no field wrap- No further adaptations to the users’ protocol beyond the use arounds are exploited to increase the quantity of tokens in a trans- of the threshold functionality are necessary, as the verification fer. The range proof we use is based on the work of Camenisch, equation for the signatures remains the same. Chaabouni, and shelat [5], instantiated with Pointcheval-Sanders signatures.

D DISTRIBUTING CERTIFICATION The Pointcheval-Sanders signature scheme can be extended into a non-interactive 푡-out-of-푛 threshold signature scheme. Consider 푛 signers C1,..., C푛 from which a party 푃 collects at least 푡 signa- ture shares that can be combined into a complete signature. We describe the process with a trusted key generation, however, no- tice that it is straightforward to convert the key generation mech- anism into a multiparty computation between the signers (see e.g. [24]). We describe the key generation algorithm tkeygen and the reconstruction algorithm combine. The algorithm to produce a signature share is identical to original signing algorithm (tak- ing secret key share as input instead of the overall secret key). That is, to sign a message (m1,..., mℓ ), signer C푗 calls algorithm ′ (ℎ, ℎ ) ←$ sign(sk푗 , (m1,..., mℓ )) with sk푗 = (푥 푗 ,푦1푗 , . . . ,푦ℓ 푗 ). The resulting signature share is a valid Pointcheval-Sanders signature ˜ ˜ ˜ for public key pk푗 = (푋푗 , 푌1푗 ,..., 푌ℓ 푗 ). ( ) ( )푛 Algorithm tkeygen 휆, 푛, 푡, ℓ computes sk푗 , pk푗 푗=1, pk as fol- lows:

• Pick ℓ + 1 random polynomials 푝푥 , 푝푦1 , . . . 푝푦ℓ of degree 푡 − 1 with coefficients from Z푝 . 푝 (0) 푝 (0) 푝 (0) • Compute 푋˜ ← g 푥 , 푌˜1 ← g 푦1 ,..., 푌˜ℓ ← g 푦ℓ .

• Compute all 푥 푗 = 푝푥 (푗) and 푦푖 푗 = 푝푦푖 (푗). 푥 푦 • Compute all 푋˜ 푗 = g 푗 and 푌˜푖 푗 ← g 푖 푗 . • Set pk = (푋,˜ 푌˜1,..., 푌˜ℓ ). Set sk푗 = (푥 푗 ,푦1푗 , . . . ,푦ℓ 푗 ) and ˜ ˜ ˜ pk푗 = (푋푗 , 푌1푗 ,..., 푌ℓ 푗 ). • Output (sk1,..., sk푛, pk1,..., pk푛, pk). Algorithm combine, on input {(s푗 , pk푗 )}푗 ∈푆, (m1,..., mℓ ), for a set 푆 ⊆ {1, . . . , 푛} with |푆| = 푡, proceeds as follows. ′ • Output ⊥ if not all {(s푗 , pk푗 )}푗 ∈푆 with s푗 = (ℎ푗 , ℎ푗 ) have ˜ ˜ ˜ ′ the sameℎ and if verify((푋푗 , 푌1푗 ,..., 푌ℓ 푗 ), (m1,..., mℓ ), (ℎ, ℎ푗 )) does not hold for all 푗 ∈ 푆.

3Our protocol only requires a semantically secure encryption thanks to transaction authentication via Fa-auth. The latter ensures that the content of the transaction cannot be tampered with without detection.