cryptographic tools for privacy compliance efficiency in
play

Cryptographic Tools for Privacy, Compliance & Efficiency in - PowerPoint PPT Presentation

Cryptographic Tools for Privacy, Compliance & Efficiency in Blockchain Applications Fernando Krell, PhD Columbia U. Lead Cryptography Engineer, Findora Public-Ledgers/Blockchains R 1:... R 2:... R 3:... R 4:... ... Append only Database


  1. Cryptographic Tools for Privacy, Compliance & Efficiency in Blockchain Applications Fernando Krell, PhD Columbia U. Lead Cryptography Engineer, Findora

  2. Public-Ledgers/Blockchains R 1:... R 2:... R 3:... R 4:... ... Append only Database 1st App: Decentralized Public visibility Currencies Cannot tamper history Privately or publicly writable Auditable processes What can be written? Whatever the allowed writers agree on

  3. Privacy in Decentralized Currencies TransferNote: TransferNote: Source address: ? ● Source amount: ? ● Source: Addrs_in, amount_in ● Destination: Addrs_out, amount_out Destination address: ? ● ● ... Destination amount: ? ● ● Signature 𝛕 ● ZK-Proof of correctness ● Anonymous Signature 𝛕 ●

  4. UTXO Model Tx Out Tx Tx Out Out Unspent transaction output ● In every transaction, coins involved are destroyed, new coins ● Tx are created. Tx Out Out System state is the set of all coins that hasn’t been spend ● Or the set of UTXOs ○ Tx Out UTXO TransferNote: Tx Tx Out ● XfrNote number + Output index In1: UTXO i 1 Out ● Tx ● After approved, UTXO is removed In2: UTXO i 2 ● Out ... ● Tx InN: UTXO i N ● Out Out1: Addrs i1 , Amount i1 ● ● New UTXO Tx Out2: Addrs i2 , Amount i2 ● ● After approved, UTXO is added Out … ● Tx ● Verifiers check OutM: Addrs i M , Amount i M ● Out ○ Signatures Tx Signatures 𝛕 1... 𝛕 N ● Out ○ ∑in_amounts >= ∑out_amounts Tx ○ Out_amount_i >= 0 for all i Tx Out Out

  5. 1st Cryptographic Tool Aggregatable signatures In UTXO system, sender needs to sign TxNote under all input’s keys ● Aggregatable signatures allow a single signature for a message signed under many ● keys Aggregate all signatures in a block ● Aggregation technique 1 BLS Signatures: t1,...,tn <- Hash’(pk 1 ,...,pk n ) ● Compute 𝞃 = ∏ 𝞃 i ^t i Params: Bilinear map e: G1xG2 -> Gt, Hash ● ● e(g1^a, g2^b) = e(g1,g2)^ab Compute pk = ∏ pk i ^t i ○ ● Hash: Z q ->G1 ○ Gen(): sk ∼ Z q, pk = g2^sk ● Sign(sk,m): 𝞃 = Hash(m)^sk ● Aggregation technique 2 Vrfy(pk, m, 𝞃 ): e( 𝞃 , g2) = e(Hash(m), pk) ● Compute 𝞃 = ∏ 𝞃 i ● Verify e( 𝞃 , g2) = ∏ e(Hash(m i ), pk i ●

  6. Account Balance Model System state is the map of addresses to current amounts ● Addresses are maintained over time ● addr1 amount1 addr2 amount2 ● Verifiers check ... ○ Balance[Addr_sender]>= amount ○ Signature addrN Amount N ● After proved ○ Balance[Addr_sender] -= amount ○ Balance[Addr_recv] += amount Account-Balance TransferNote: In Address: Addr_sender ● Out Address: Addr_recv ● Amount ● Signature 𝛕 ●

  7. Privacy in the UTXO Model Confidential Transaction [Max15] ● Amount is hidden from readers AND verifiers ● Amount is replaced by a “encryptions” of the amount ○ Sender proves correctness via a Zero-Knowledge proofs ○ UTXO TransferNote: Efficiently achievable ● In1: UTXO i 1 ● Verifiers check In2: UTXO i 2 via ZK-SNARK ● ... ○ Signatures ● InN: UTXO i N ○ ZK-Proofs of ● ● Out1: Addrs i1 , Enc (Amount i1 ) ■ ∑in_amounts >= ∑out_amounts Out2: Addrs i2 , Enc (Amount i2) ● ■ out_amount_i >= 0 for all u … ● OutM: Addrs i M , Enc (Amount i M ) ● What about ● Zero-Knowledge proofs Anonymity? Signatures 𝛕 1... 𝛕 N ●

  8. Confidential Transactions [Max15] Cryptographic Tool: Homomorphic Commitment Schemes Pedersen Commitments ● Public groups elements G,H ○ Com(amount,blinding) = amount * G + blinding * H ○ Can open amount by revealing amount, blinding ○ Sender “needs” to send openings to Homomorphic: ○ receivers via a private channel Com(a,b) + Com(c,d) = Com(a+b, b+d) ■ Perfectly hiding ○ Works in the UTXO Model Blinding completely hides amount ■ Computationally binding ○ Can it work on the account-balance two openings => breaking DLog ■ model? Questions to Students: ○ Can we easily switch to computationally hiding ■ and perfectly binding? Why would we do that? ■

  9. Privacy in Account-Balance Systems addr1 Com(balance1,r1) addr2 Com(balance2,r2) Account poisoning ● ... Zether [BAZB19]: ● ElGamal Encryption for balance ○ addrN Com(balanceN,rN) Balance on the exponent ■ Enc(PK, b, r) = (b*G + r*PK, r*G) ■ Additively homomorphic ● Add/Subs Xfr amount ctexts to ● addr1 Enc(pk1, balance1, r1) balance ciphertext Adapt range proof on commitments to ElGamal ○ addr2 Enc(pk2, balance2, r2) ciphertexts ( 𝝩 -Bullet proof system) ... addrN Enc(pkN, balanceN,rN)

  10. Anonymity in UTXO Systems UTXO system provide some degree of anonymity, but very naively ● Public-ledger => traceable transactions ● Fairly easy to track and recognize patterns ○ E.g. Identify a business address, then identify consumers addresses and trace them ○ Can we hide origin and destination Addresses? ● Zero-Cash, Monero, and other provide this ● Sketch: ○ Always send to a new “random” address that the receiver can recognize => ■ Hides receiver Use crypto magic to hide sender ■

  11. Anonymity in UTXO Systems Hiding Sender in Monero User chooses an Anonymity set of Tx ● Tx Outputs Out Tx User provides a one-time group signature ● Out Verifier can recognize if input is used twice ● Tx Tool: Linkable Ring Signature ○ Out Tx Tx Out Tx Out Out Tx Tx Tx Out Out Out Tx Out Detectable by Tx Tx Out Tx signature scheme Out Out Tx Out Tx Tx Out Out

  12. Anonymity in UTXO Systems Hiding Sender in Zcash (Sketch) Each output contains a commitment to ● Destination address ○ Merkle Tree Amount ○ Random number 𝞻 ○ Spending it ● Publish nullifier = Hash(sender sk, 𝞻 ) ○ ZK Proof includes ○ 𝞻 exists in the list of UTXO (Merkle Tree Proof) ■ Nullifier is computed correctly ■ Knowledge of spending key ■ Verifier checks ○ Nullifier has not been published ■ ZK-Proof ■

  13. Anonymity in Zether addr1 Enc(pk1, balance1, r1) + Enc(pk1, - amount, r1’) Issue: Full anonymity => Every balance ctext in the system needs ● addr2 Enc(pk2, balance2, r2) to be updated + => No scalable solution ○ Enc(pk2, 0, r2’) Ok! But Some anonymity is possible ● Choose anonymity set of size N ○ ... Provide N ciphertexts ○ Receiver ctext encrypts amount ■ Addrj Enc(pkj, balancej, rj) Sender ctext encrypts -amount ■ + All others encrypts 0 ■ Enc(pkj, amount, rj’) ZK proof: ○ C_i encrypts value a for secret i and a ■ …. C_j encrypts value -a for same a and secret j ■ C_u encrypts 0 for u !=i,j ■ addrN Enc(pkN, balanceN,rN) Sender’s balance is positive after Tx is processed ■ + Enc(pkN, 0,rN’)

  14. Privacy vs Compliance Public records: Encrypted records Allow public auditability of processes Data is hidden for everybody ● ● ● Allow law/regulator compliance checks ● ⇒ processes are not publicly auditable Reveal ALL private data to everybody compliance checks are hard/impossible ● ● Ahh, this seems better! Who would use it? but who would allow it?

  15. Compliance Case Study: Asset Tracing We will issue company stock on a public ledger! Allow secondary transfers ● Protect privacy of shareholders ● Company must see amount and ● identities of all trades System must support Issuance of assets ● Confidential transfers ● Amount, asset type, identity ○ Transfer details revealed to asset ● issuer

  16. Tracing confidential amount and asset type Plain Transfer Note Input : Com(amount,ra), Com(type in ,rt), Addr sender Input : <amount, asset type, Addr sender > Output : Com(amount’,ra’), Com(type out ,rt’), Addr recv Hide amount, type Output : <amount’, asset type’, Addr recv > Zero-Knowledge Proofs: amount-amount’ > 0 ● Signature : sign(...,SKsender) amount’ > 0 ● type in = type out ● Signature : sign(...,SKsender) Input : <Com(amount,ra), Com(type_in,rt), Addr sender , PK issuer > Output : <Com(amount’,ra’), Com(type_out,rt’), Addr recv , PK issuer > Issuer Data : Enc(amount’’, PK issuer , ra’), Enc(type_issuer, PK issuer , rt’) Tracing Capabilities Zero-Knowledge Proofs: amount-amount’ > 0 ● amount’ > 0 ● type in = type out ● ● amount’’ = amount’ type tracer = type out ● Signature : sign(...,SKsender)

  17. Pedersen Commitments Com( value , blinding ) = value *G + blinding *H 1. Commitments are hiding 2. Commitments are binding 3. Homomorphic: Com(a,r) + Com(b,s) = Com(a + b, r + s) Cryptographic Tools ElGamal Encryption PK = sk*G ● (C1,C2) = Enc( PK , val , r ) = ( val *G + r *PK, r *G) ● Dec(sk, C1,C2): Dlog (G, C1 - sk*C2) ● Homomorphic ● Enc(a,r) + Enc(b,s) = Enc(a + b, r + s)

  18. Σ-Protocols ● Zero-Knowledge proof protocol ● Suitable for Pedersen/ElGamal Statements ○ Knowledge of a,b,b’ such that C = Com(a,b) AND C’ = COM(a,r’) ○ Knowledge of a,r,b such that C = Com(a,b) AND E = Enc(PK,a,r) Cryptographic Tools Range Proofs ● Zero-Knowledge proof protocol ● Knowledge of a,b such that C= Com(a,b) AND 0 ≤ a ≤ MAX

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend