Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Protocols for Provable Solvency

In this presentation we introduce a way to provide privacy to the Maxwell-Todd's construction by using commiments and zero-knowledge proofs.

  • Login to see the comments

  • Be the first to like this

Protocols for Provable Solvency

  1. 1. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Secure Protocols for Provable Solvency v0.5 Philippe Camacho (philippe.camacho@gmail.com) Coin4ce.com June 16th, 2014 Philippe Camacho Secure Protocols for Provable Solvency
  2. 2. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Who am I? PhD en Cryptology, University of Chile, Chile. Worked on cryptographic hash functions with special properties, in particular cryptographic accumulators. Phd Thesis : http://users.dcc.uchile.cl/˜pcamacho/papers/phdthesis.pdf List of publications http://www.informatik.uni-trier.de/˜ley/pers/hd/c/Camacho:Philippe Slideshare presentations: http://www.slideshare.net/philippecamacho/presentations CTO of Coin4ce.com since mid 2013. Philippe Camacho Secure Protocols for Provable Solvency
  3. 3. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Acknowledgements This work has been made while being at Coin4ce.com / Comprabitcoin.com. I owe many thanks to Darren Camas, Austin Delonge and Adam Stradling for their support and feedback. Philippe Camacho Secure Protocols for Provable Solvency
  4. 4. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Motivation Catastrophic events like the MtGox bankruptcy have raised the need for an automated, fully transparent and externally verifiable way to check the solvency of financial institutions. This presentation introduces an overview of previously proposed protocols that can help to automate part of the process of auditing the solvency of financial institutions. We show that it is possible in practice to maintain the business data (amounts owed/owned) private while still allowing to verify the solvency of some financial institution. For this purpose we use two main cryptographic tools: commitments and zero-knowledge proofs. Feedback and questions welcome at philippe.camacho@gmail.com. Philippe Camacho Secure Protocols for Provable Solvency
  5. 5. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion The Problem A Financial Institution (FI) usually keeps its database private. Its database might not reflect the reality of its assets anyway. In this situation, manual auditing is the only option. However it’s slow and implies trusting the entity performing the audit. Philippe Camacho Secure Protocols for Provable Solvency
  6. 6. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Why Bitcoin changes the Scenario With Bitcoin it’s simple to prove you own a given amount of coins: 1 Pick the address you claim to own. 2 Get a random (not controlled by you) message: data from the blockchain can serve this purpose. 3 Sign this message with the private key corresponding to your bitcoin address. 4 The amount of BTC for this address is available in the blockchain. Philippe Camacho Secure Protocols for Provable Solvency
  7. 7. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Building Blocks Merkle Trees Secure Broadcast Channel Commitments and Zero-Knowledge Proofs Philippe Camacho Secure Protocols for Provable Solvency
  8. 8. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Merkle Trees [9] g = H(e||f ) e = H(a||b) a b f = H(c||d) c d Figure 1 : Merkle tree for sequence (a, b, c, d). The hash function induced by the tree and a collision-resistant hash function H takes the set (a, b, c, d) as input and returns the root hash value g as output. A proof that a belongs to the sequence is composed by the nodes containing values (b, f ) (underlined) which are the siblings of the nodes on the path from a to the root g. Checking the proof consists of computing e′ = H(a||b), then computing g′ = H(e′||f ) and finally checking that g = g′. A Merkle Tree [9] is a cryptographic data-structure that enables to Hash a sequence of values. Prove that a specific value belongs to this sequence by giving the hash of this sequence and a short cryptographic proof. It works as follows: Put the values of the sequence at the leaves of a balanced binary tree. Compute each internal node value by hashing the value of the left child concatenated with the right child. The value at the root is the hash of the sequence. To prove that an element at a leaf belongs to the sequence: Provide the siblings of the nodes on the path from this leaf to the root. Using these nodes recompute the hash value at the root and check it is the same as the one provided initially (see Figure 1). Efficiency: The size and the time to check the cryptographic proof is logarithmic in the size of the set. Security: If the hash function used is collision-resistant, then it is hard to compute a fake cryptographic proof for an element that does not belong to the sequence. Philippe Camacho Secure Protocols for Provable Solvency
  9. 9. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Secure Broadcast Channel A Secure Broadcast Channel (SBC) guarantees the following: One can post messages. Everyone sees exactly the same messages in the same order. No one can delete messages. Hey! Bitcoin is a SBC :) It’s quite an important tool, it can be used for example in electronic-voting protocols [5]. Philippe Camacho Secure Protocols for Provable Solvency
  10. 10. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Commitments A commitment is a tool that allows to delay the disclosure of some information. It works basically as follows: Alice chooses some message M and computes a commitment C = Comm(M, r), where r, the randomness is used to hide the information of M. When the context is clear we will write C = Comm(M) instead of C = Comm(M, r). Alice sends C to Bob. Then Bob can tell Alice to open the commitment C. Alice will give the message M and r to Bob Bob can check that indeed C = Comm(M, r). There are two main security properties for commitments Given only C = Comm(M, r) one does not learn anything about M. It’s impossible for Alice to open the commitment C to another message M′ = M. Commitments are useful to implement apparently contradictory requirements where one needs to prove something about some value, but wants to keep this value secret at the same time. Some commitments [10] have interesting algebraic properties that we will exploit for the protocol described in section 3 (see next slide). Philippe Camacho Secure Protocols for Provable Solvency
  11. 11. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Pedersen Commitments[10] Their security relies on the discrete logarithm problem. Intuitively this means that given some group element X = gd where g is some generator, it is hard to compute d, the discrete logarithm. Operations Setup: consider a group G and two random elements g, h ∈ G Comm(M, r) = CM = gM hr where M is the message and r the randomness of the commitment. Open(CM , M, r): returns (M, r). Verify(CM , M, r): checks that CM = gM hr . Security (intuition) The commitment CM = Comm(M, r) does not leak any information about M as it’s indistinguishable from a random message (due to the randomness r). It’s hard to open CM = Comm(M, r) to (M′, r′) where M′ = M because due to the discrete logarithm problem the messages in exponents M, r are somehow “locked” in their respective base g, h. For rigorous definitions and proofs see http://bit.ly/1e4gSxu Homomorphic property Given CM = Comm(M, r) and CN = Comm(N, r′) whe have that CM · CN = gM hr · gN hr′ = gM+N hr+r′ = Comm(M + N, r + r′) Basically, multiplying the commitments relative to messages M, N one obtains the commitment of message M + N. We use this trick in order to compute the sum of owed/owned amounts without disclosing these amounts. Philippe Camacho Secure Protocols for Provable Solvency
  12. 12. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Proving two Commitments Encode the same Value with ZKPoK In our construction we need to do the following: Given Comm(M, r) and Comm(M′, r′) prove that M = M′ without opening the commitments. For this we need another tool, Zero-Knowledge Proofs of Knowledge (ZKPoK). This consists of letting the prover convince a verifier that he knows (M, r) such that CM = Comm(M, r) = gM hr . Using ZKPoK proving our statement can be done as follows: Compute V = Comm(M,r) Comm(M,r′) = gM−M hr−r′ = hr−r′ Compute a ZKPoK of the discrete logarithm of V with respect to the base h. See [4] for references on ZKPoK and techniques to prove more involved statements. Philippe Camacho Secure Protocols for Provable Solvency
  13. 13. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Merkle Trees Secure Broadcast Channel Commitments Proving a Commitment Encodes a Value in a Specific Range A simple technique [7] (see also [2] Section 1.2.1) does the trick: Decompose the committed number in a product of k commitments where each commitment corresponds to a bit. Then prove each commitment encodes a bit. Multiply these commitments together and check you obtain a commitment of the number you want to test. It’s not optimal but when the range is short, as in our case, it is efficient enough. The size of the proof is proportional to the number of bits required to encode the range (51 in our case). More sophisticated and efficient proofs have been proposed [3]. Philippe Camacho Secure Protocols for Provable Solvency
  14. 14. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Preliminaries All the information produced by FI is published on a secure broadcast channel SBC. This information may be signed by FI in case the SBC is shared with other participants. We consider two types of protocols Accounting Declaration protocols: the FI declares how much money it owes to its customers. Asset Declaration protocols: the FI declares how much money it owns. Philippe Camacho Secure Protocols for Provable Solvency
  15. 15. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Maxwell-Todd Protocol Todd Privacy-Preserving Protocol Improving the Privacy of Maxwell-Todd Protocol Maxwell-Todd Protocol [12],[8] Description1: Periodically (once a day, week or month for example) the FI publishes a value that represents the list of accounts with their respective balances for each client. The value is computed by using a Merkle-Tree where Each leaf contains a pair (id, X) where id is the identifier of the customer and X the current balance for his account. Each internal node value N is computed recursively as follows N = H(X + Y ||L||R) where X is the amount of the left child, Y the amount of the right child, L the (hash) value of the left child and R the (hash) value of the right child. The hash value for the root node is the one that is published. It is the responsibility of the Customer to check that his account balance belongs to the tree by asking for the corresponding cryptographic proof (siblings node from the leaf to the root) to the FI. Discussion: User must check his account for each update of the root value. However it is risky in practice for the FI to try to lie on some user’s account balance as it might be detected. The amount in each node must be positive. It is the responsibility of the user to check that as well. The total amount owed is public. The root hash value must be published in the SBC otherwise different hash values (and thus user’s account declaration) could be published to different groups of people. 1 A more detailed description is available at [14]. Philippe Camacho Secure Protocols for Provable Solvency
  16. 16. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Maxwell-Todd Protocol Todd Privacy-Preserving Protocol Improving the Privacy of Maxwell-Todd Protocol Privacy-Protecting Proof of Reserves without the Moon-Math and without the backup angst [13] Peter Todd addresses the problem of privacy (for user and FI) with the following idea The FI commits2 each deposit address to a domain name and the nonce relative to the user This technique allows to Keep FI’s and user’s respective balance private Avoid the key reuse attack (assign same bitcoin addresses to different users) Some practical challenges arise This solution forces a specific administration of bitcoin addresses for the FI. Also this solution depends on the specific implementation of Bitcoin (in particular the way Bitcoin addresses are computed). 2 In this case hash functions are used, not commitments. Philippe Camacho Secure Protocols for Provable Solvency
  17. 17. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Maxwell-Todd Protocol Todd Privacy-Preserving Protocol Improving the Privacy of Maxwell-Todd Protocol Adding privacy to Maxwell-Todd’s protocol One of the limitations of Maxwell-Todd’s protocol is that it forces the FI to reveal the total amount it owes to its customers. We show (see [11] for a generalization of this technique.) here how to allow this amount to be kept private while at the same time enabling the users to check that their account is present in the Merkle-Tree. Idea: Replace the amount X stored in each node by the commitment of this amount Comm(X) Instead of computing Z = X + Y the amount of the parent node, multiply the commitments of the left child and right child. That is compute Comm(Z) = Comm(X) · Comm(Y ). The homomorphic property ensures that indeed Z = X + Y . Check using ZKP that each amount is in the range [0, Z] where Z = 21 · 106 · 108 is the total amount of satoshis. Philippe Camacho Secure Protocols for Provable Solvency
  18. 18. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Maxwell-Todd Protocol Todd Privacy-Preserving Protocol Improving the Privacy of Maxwell-Todd Protocol Example A = H(B||C||Comm(65)); Comm(65) B = H(D||E||Comm(30)); Comm(30) D = ID1||Comm(10) E = ID2||Comm(20) C = H(F||G||Comm(35)); Comm(35) F = ID3||Comm(15) G = ID4||Comm(20) Figure 2 : Providing privacy to Maxwell-Todd’s tree using commitments: Here we replace the amounts by the commitments of the amounts. For a node N, given the commitments CL = Comm(X) and CR = Comm(Y ) of the left and right child respectively, computing the commitment of the node consists of multiplying these commitments. That is CN = CL · CR = Comm(X) · Comm(Y ) = Comm(X + Y ). Philippe Camacho Secure Protocols for Provable Solvency
  19. 19. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Maxwell-Todd Protocol Todd Privacy-Preserving Protocol Improving the Privacy of Maxwell-Todd Protocol Discussion The commitments do not leak any information about the amounts. Yet all the necessary relationships can be checked. Now what do we do with this commitment? We can compare it to another commitment that will contain for example the total asset of the FI. For example, in case of fiat money, the bank could compute another commitment containing the FI’s balance in USD and sign it so that people can check the information is legitimate. Then the FI can prove with ZKP that the two amounts included in each commitment are equal. In the case when the FI needs to prove the size of its assets in bitcoins we will use the protocol described in section 2 to compute this commitment. Compared to Todd’s solution [13] our solution allows to have two separate protocols for Accounting and Asset declaration. This can be useful for example in the case where assets are in fiat money. On the other side Todd’s solution offers better privacy than our protocol related to asset declaration (see next: section 2). Philippe Camacho Secure Protocols for Provable Solvency
  20. 20. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Basic Coin Ownership Protocol Towards more privacy: random sampling Coin Ownership Protocol Already mentioned in the introduction. An implementation can be found at [6]. COIN OWNERSHIP 1 Pick the address you claim to own 2 Get a random (not controlled by you) message: data from the blockchain can serve this purpose 3 Sign this message with the private key corresponding to your bitcoin address 4 The amount of BTC for this address is available in the Blockchain By being able to compute a signature on a random message the owner of the bitcoin address proves he is able to transfer funds from this address to another. Philippe Camacho Secure Protocols for Provable Solvency
  21. 21. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Basic Coin Ownership Protocol Towards more privacy: random sampling Adding privacy How do you prove you have a given amount of bitcoins without leaking this amount? Initial Idea3 Use a private Maxwell-Todd tree where the leaves are composed by The bitcoin addresses the FI claims to own. The amount available at these addresses. The Merkle-tree must be such that the addresses are ordered in ascending order so that no address is duplicated (that would inflate artificially the total value of the assets). Users must check that the neighbour leaf (can be on the left or on the right) satisfies the condition. This might create the need to compute two branches of the Merkle tree. Again the FI could lie (by duplicating some bitcoin addresses) but it exposes itself to be detected in case of fraud. Choose a random leaf and ask the FI to open the commitment containing the address A and the balance B at the leaf. Run COIN OWNERSHIP on address A. Check on the Blockchain that the amount B is correct. 3 This is only an idea. As mentioned next it needs to be refined in order to work. Philippe Camacho Secure Protocols for Provable Solvency
  22. 22. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Basic Coin Ownership Protocol Towards more privacy: random sampling Example A = H(B||C||Comm(65)); Comm(65) B = H(D||E||Comm(30)); Comm(30) D = BTC1||Comm(10) E = BTC2||Comm(20) C = H(F||G||Comm(35)); Comm(35) F = BTC3||Comm(15) G = BTC4||Comm(20) Figure 3 : Proving the size of assets with random sampling. This is the same construction as in Figure 2 but we replace the user ID by the bitcoin address BTC1, BTC2, .... Note that we must have BTC1 < BTC2 < BTC3 in order to avoid the duplication of bitcoin addresses. Philippe Camacho Secure Protocols for Provable Solvency
  23. 23. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Basic Coin Ownership Protocol Towards more privacy: random sampling Discussion The main problem of this solution is that the more checks we do, the more we reveal about the bitcoin addresses owned by FI and thus the total amount of bitcoins owed. So we need somehow to choose between privacy (of the FI) and increasing the odds to catch a malicious FI. Some ideas for future research Use zk-SNARKS as in Zerocash [1] to prove (without revealing it!) that a bitcoin address is controlled by the FI. The we also need to prove that this address has the right amount of BTC binded to it. This could be done using accumulators that would store the list of pairs (address,balance) of the blockchain and then checking in zero-knowledge that this address belongs to the table represented by the accumulator. Philippe Camacho Secure Protocols for Provable Solvency
  24. 24. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Open problems Privacy for asset declaration without imposing any condition on bitcoin address management like in [13]. Our solution is only partial as it is based on statistical sampling. Key rental attack. In [13] is proposed a way to prevent reusing keys internally or between institutions, yet nothing prevent anyone to rent addresses to others in order to simulate solvency. Philippe Camacho Secure Protocols for Provable Solvency
  25. 25. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion Thank you! Please send me feedback, questions at philippe.camacho@gmail.com Philippe Camacho Secure Protocols for Provable Solvency
  26. 26. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion [1] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized Anonymous Payments from Bitcoin. 2014. [2] Fabrice Boudot. Efficient Proofs that a Committed Number Lies in an Interval. In Bart Preneel, editor, EUROCRYPT, volume 1807 of Lecture Notes in Computer Science, Berlin, Heidelberg, May 2000. Springer Berlin Heidelberg. [3] Jan Camenisch, Rafik Chaabouni, and Abhi Shelat. Efficient Protocols for Set Membership and Range Proofs. In ASIACRYPT ’08: Proceedings of the 14th International Conference on the Theory and Application of Cryptology and Information Security, pages 234–252, Berlin, Heidelberg, 2008. Springer-Verlag. [4] Jan Camenisch and Markus Stadler. Proof Systems for General Statements about Discrete Logarithms. Technical report, 1997. [5] Ronald Cramer, Rosario Gennaro, and Berry Schoenmakers. A Secure and Optimally Efficient Multi-Authority Election Scheme. In Walter Fumy, editor, EUROCRYPT, volume 1233 of LNCS, pages 103–118. Springer Berlin / Heidelberg, July 1997. [6] Olivier Lalonde. bitcoin-asset-proof. https://github.com/olalonde/bitcoin-asset-proof, 2014. [7] Wenbo Mao. Guaranteed correct sharing of integer factorization with off-line shareholders. In Hideki Imai and Yuliang Zheng, editors, Public Key Cryptography, volume 1431 of Lecture Notes in Computer Science, Berlin/Heidelberg, 1998. Springer-Verlag. [8] Greg Maxwell. IRC transcript of gmaxwell describing his prove-how-(non)-fractional-your-Bitcoin-reserves-are scheme. https://iwilcox.me.uk/2014/nofrac-orig, 2014. [9] Ralph C. Merkle. A Digital Signature Based on a Conventional Encryption Function. Philippe Camacho Secure Protocols for Provable Solvency
  27. 27. Introduction The Problem Building blocks Preliminaries Protocols for Accounting Declaration Protocols for Asset Declaration Open problems Conclusion In Carl Pomerance, editor, CRYPTO, volume 293 of LNCS, pages 369–378. Springer Berlin / Heidelberg, August 1987. [10] Torben Pedersen. Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. In J. Feigenbaum, editor, CRYPTO, volume 576 of LNCS, pages 129–140. Springer Berlin / Heidelberg, 1991. [11] Brian Thompson, Stuart Haber, William G. Horne, Tomas Sander, and Danfeng Yao. Privacy-Preserving Computation and Verification of Aggregate Queries on Outsourced Databases. In Ian Goldberg and Mikhail J. Atallah, editors, Privacy Enhancing Technologies, volume 5672 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, 2009. [12] Peter Todd. Peter Todd’s talk (Bitcoin Conference). http://youtu.be/4d3LA8KpdMQ?t=6m33s, 2013. [13] Peter Todd. Privacy-Protecting Proof of Reserves without the Moon-Math and without the backup angst. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/20140325220507.GB4846@tilt/, 2014. [14] Zak Wilcox. Proving your Bitcoin reserves. https://iwilcox.me.uk/2014/proving-bitcoin-reserves, 2014. Philippe Camacho Secure Protocols for Provable Solvency

×