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

Fernando Krell, PhD Columbia U. Lead Cryptography Engineer, Findora

Cryptographic Tools for Privacy, Compliance & Efficiency in Blockchain Applications

Public-Ledgers/Blockchains

R1:... R2:... R3:... R4:... ... Append only Database Public visibility Privately or publicly writable Cannot tamper history Auditable processes What can be written? Whatever the allowed writers agree on

1st App: Decentralized Currencies

Privacy in Decentralized Currencies

TransferNote:

• Source: Addrs_in, amount_in
• Destination: Addrs_out, amount_out
• ...
• Signature 𝛕

TransferNote:

• Source address: ?
• Source amount: ?
• Destination address: ?
• Destination amount: ?
• ZK-Proof of correctness
• Anonymous Signature 𝛕

UTXO Model

UTXO TransferNote:

• In1: UTXOi1
• In2: UTXOi2
• ...
• InN: UTXOiN
• Out1: Addrsi1, Amounti1
• Out2: Addrsi2, Amounti2
• …
• OutM: AddrsiM, AmountiM
• Signatures 𝛕1...𝛕N
• Unspent transaction output
• In every transaction, coins involved are destroyed, new coins

are created.

• System state is the set of all coins that hasn’t been spend

○ Or the set of UTXOs

• XfrNote number + Output index
• After approved, UTXO is removed
• New UTXO
• After approved, UTXO is added
• Verifiers check

○ Signatures ○ ∑in_amounts >= ∑out_amounts ○ Out_amount_i >= 0 for all i

Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out

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

BLS Signatures:

• Params: Bilinear map e: G1xG2 -> Gt, Hash

○ e(g1^a, g2^b) = e(g1,g2)^ab ○ Hash: Zq->G1

• Gen(): sk∼Zq, pk = g2^sk
• Sign(sk,m): 𝞃 = Hash(m)^sk
• Vrfy(pk, m, 𝞃): e(𝞃, g2) = e(Hash(m), pk)

Aggregation technique 1

• t1,...,tn <- Hash’(pk1,...,pkn)
• Compute 𝞃 = ∏ 𝞃i^ti
• Compute pk = ∏ pki^ti

Aggregation technique 2

• Compute 𝞃 = ∏ 𝞃i
• Verify e(𝞃, g2) = ∏ e(Hash(mi), pki

Account Balance Model

Account-Balance TransferNote:

• In Address: Addr_sender
• Out Address: Addr_recv
• Amount
• Signature 𝛕
• System state is the map of addresses to current amounts
• Addresses are maintained over time
• Verifiers check

○ Balance[Addr_sender]>= amount ○ Signature

• After proved

○ Balance[Addr_sender] -= amount ○ Balance[Addr_recv] += amount addr1 amount1 addr2 amount2 ... addrN Amount N

Privacy in the UTXO Model

UTXO TransferNote:

• In1: UTXOi1
• In2: UTXOi2
• ...
• InN: UTXOiN
• Out1: Addrsi1, Enc(Amounti1)
• Out2: Addrsi2, Enc(Amounti2)
• …
• OutM: AddrsiM, Enc(AmountiM)
• Zero-Knowledge proofs
• Signatures 𝛕1...𝛕N
• 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

• Verifiers check

○ Signatures ○ ZK-Proofs of ■ ∑in_amounts >= ∑out_amounts ■

• ut_amount_i >= 0 for all u

What about Anonymity?

Efficiently achievable via ZK-SNARK

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 ○ Homomorphic: ■ Com(a,b) + Com(c,d) = Com(a+b, b+d) ○ Perfectly hiding ■ Blinding completely hides amount ○ Computationally binding ■ two openings => breaking DLog ○ Questions to Students: ■ Can we easily switch to computationally hiding and perfectly binding? ■ Why would we do that?

Sender “needs” to send openings to receivers via a private channel Works in the UTXO Model Can it work on the account-balance model?

Privacy in Account-Balance Systems

• Account poisoning
• Zether [BAZB19]:

○ ElGamal Encryption for balance ■ Balance on the exponent ■ Enc(PK, b, r) = (b*G + r*PK, r*G)

• Additively homomorphic
• Add/Subs Xfr amount ctexts to

balance ciphertext ○ Adapt range proof on commitments to ElGamal ciphertexts (𝝩-Bullet proof system) addr1 Com(balance1,r1) addr2 Com(balance2,r2) ... addrN Com(balanceN,rN) addr1 Enc(pk1, balance1, r1) addr2 Enc(pk2, balance2, r2) ... addrN Enc(pkN, balanceN,rN)

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

Anonymity in UTXO Systems

Hiding Sender in Monero

• User chooses an Anonymity set of Tx

Outputs

• User provides a one-time group signature
• Verifier can recognize if input is used twice

○ Tool: Linkable Ring Signature

Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out Tx Out

Detectable by signature scheme

Anonymity in UTXO Systems

Hiding Sender in Zcash (Sketch)

• Each output contains a commitment to

○ Destination address ○ 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

Merkle Tree

Anonymity in Zether

• Issue: Full anonymity => Every balance ctext in the system needs

to be updated ○ => No scalable solution

• Ok! But Some anonymity is possible

○ Choose anonymity set of size N ○ Provide N ciphertexts ■ Receiver ctext encrypts amount ■ Sender ctext encrypts -amount ■ All others encrypts 0 ○ 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 ■ Sender’s balance is positive after Tx is processed addr1 Enc(pk1, balance1, r1) + Enc(pk1, - amount, r1’) addr2 Enc(pk2, balance2, r2) + Enc(pk2, 0, r2’) ... Addrj Enc(pkj, balancej, rj) + Enc(pkj, amount, rj’) …. addrN Enc(pkN, balanceN,rN) + Enc(pkN, 0,rN’)

Privacy vs Compliance

Public records:

• Allow public auditability of processes
• Allow law/regulator compliance checks
• Reveal ALL private data to everybody

Encrypted records

• Data is hidden for everybody
• ⇒ processes are not publicly auditable
• compliance checks are hard/impossible

Who would use it?

Ahh, this seems better! but who would allow it?

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

Tracing confidential amount and asset type

Plain Transfer Note

Input: <amount, asset type, Addrsender> Output: <amount’, asset type’, Addrrecv> Signature: sign(...,SKsender)

Input: <Com(amount,ra), Com(type_in,rt), Addrsender, PKissuer> Output: <Com(amount’,ra’), Com(type_out,rt’), Addrrecv, PKissuer> Issuer Data: Enc(amount’’, PKissuer, ra’), Enc(type_issuer, PKissuer,

rt’)

Zero-Knowledge Proofs:

• amount-amount’ > 0
• amount’ > 0
• typein = typeout
• amount’’ = amount’
• typetracer = typeout

Signature: sign(...,SKsender) Input: Com(amount,ra), Com(typein,rt), Addrsender Output: Com(amount’,ra’), Com(typeout,rt’), Addrrecv

Zero-Knowledge Proofs:

• amount-amount’ > 0
• amount’ > 0
• typein = typeout

Signature: sign(...,SKsender)

Hide amount, type

Tracing Capabilities

Cryptographic Tools 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) 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)

Cryptographic Tools Σ-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) Range Proofs

• Zero-Knowledge proof protocol
• Knowledge of a,b such that

C= Com(a,b) AND 0 ≤ a ≤ MAX

Confidential-Traceable Transfer Details

Input: <Com(amount,ra), Com(t,rt), PKsender, PKissuer> Output: <Com(amount’,ra’), Com(t’,rt’), PKrecv, PKissuer> Issuer Data: Enc(amount’’, PKissuer, ra’), Enc(t’’, PKissuer, rt’) Zero-Knowledge Proofs:

• amount-amount’ > 0
• amount’ > 0
• t = t’
• amount’’ = amount’
• t’’ = t’

Signature: sign(...,SKsender)

Pedersen Commitments ElGamal Ciphertexts Correctness proofs

Tracing Proofs

Tracing Proofs

ZK Proofs: Commitment-Encryption Equality Proof

• Pedersen Commitment

○ Com(a,r) = C = a*G + r*H

• ElGamal Encryption

○ Enc(PK, a, r) = (E1,E2) = (a*G + r*PK, r*G)

• G,H,PK are public
• a,r are secret to the sender
• Need to prove knowledge of a and r s.t

C = COM(a,r) and E = Enc(PK,a,r)

• Same proof technique for amount and asset type

Tracing Proof Protocol

𝝩 Protocol Commitment-Encryption Equality Proof

b1,b2← Random() C’ = Com(b1,b2) E’ = Enc(PK,b1,b2) z1 = a*c + b1 z2 = r*c + b2

Common Input C = Com(a,r), E = Enc(PK,a,r), PK, G, H

Sender Verifier

c ←Random() Verifier checks

• Com(z1,z2) = c * C + C’
• Enc(z1,z2) = c * E + E’

E’,C’

z1,z2 c

>Wait: This step is interactive <No problem, set c = Hash(PK,G,H,C,E,E’,C’)

Asset tracing proofs

❖ Cost of proof:

➢ Prover does

■ 2 multiexponentiation of size 2 ■ 1 exponentiation ➢ Verifier does ■ 2 multiexponentiations of size 2 ■ 3 exponentiations

➢ Proof consists of

■ 2 group elements (C’ and E’) ■ 2 scalars (z1 and z2) ■ Total 128 bytes on Ristretto Group

❖ Aggregation technique:

➢ N instances into a single 128 bytes proof

Take away

• Lot of engineering effort needed too

○ How to compose primitives? ○ E.g. How do we choose and run a cryptographic process inside a SNARK ○ Choosing curves to run inside SNARK ■ How to get a prime order sub-group of this curve group? ○ Choosing pairings ○ Choosing low complexity hash functions (Pedersen, MiMC, ?) ○ …

• Many things not covered here

○ E.g. Consensus mechanisms & techniques ○ Smart contracts

• Introductory resource for Students: SoK of Used Cryptography in Blockchain RGK’19

Tracing Identities?

Cryptographic Tool: Anonymous Credentials (Chaum 85)

• Identity provider issue signature on a set of attributed for a given user
• Signature does not reveal public key of user
• User can randomize signature

Selective disclosure:

• User can select which identity attributes to reveal
• ZKPoK of

○ hidden attributes ○ randomizing factor ○ user sk such that signature verification pass

Tracing Identities

Input: <Com(amount,ra), Com(t,rt), Addrsender, PKissuer> Output: <Com(amount’,ra’), Com(t’,rt’), Addrrecv, PKissuer> Issuer Data:

• …
• Credential signature 𝝉 on sender/receiver’ identity attributes
• Enc(SSN, PKissuer, rssn), Enc(zipcode, PKissuer, rzip),

Zero-Knowledge Proofs:

• …
• Verify(𝝉, SSN, zipcode, ?, ?, ?) = 1

Signature: sign(...,SKsender)

𝝩 protocol

Regulator Tracking

User

• 1. Register: Credential, Userpk
• 3. Registration certificate: Rcert

Tx Creation:

• Build TxData
• 𝛖 ← buildTag(Usersk, Rcert, TxData)
• Tx = (TxData, 𝛖, TxSignature)
• 2. - id ← DB-add(credential)
• Rcert ← CreateCert(Rsk, id, Userpk)

Regulator

Public verification

• (TxData, 𝛖) ← Tx
• verifyTag(Regulatorpk, TxData, 𝛖)

Identity Tracking by regulator

• Id ← OpenIdentity(Rsk,𝛖)
• Credentials ← DB-Lookup(id)

Regulator Tracking via Group Signatures

Group Signatures

Users sign messages on behalf of a group Signer remains anonymous

Traceable

• Setup(): Generates manager keys PK, SK (Regulator)
• GenUserKeys(PK): Generates user keys Upk, Usk
• Add(SK, Upk): Generates user certificate Cu for the user
• Sign(Upk, Cu, msg): Generate group signature 𝝊 on msg
• Verify(PK, msg, 𝝊): Verify signature on msg using group

verification key

• Open(SK, 𝝊): Obtain user’s public key Upk

Group manager can identify signers

ZK-SNARK

Zero-Knowledge Succinct Non-interactive ARgument of Knowledge

Use in blockchain:

• Scaling:

○ Perform operation off-chain ○ Provide small proof on-chain

• Privacy:

○ Confidential transactions, anonymity, etc Short Proofs Single one-way message Computationally sound Prover proofs knowledge of NP witness

ZK-SNARK

𝞺

Prover Verifier Succinctness |𝞺| <= polylog(|CR|) Efficiency Verifier time <= polylog(|CR|) 𝞺 reveals no information

• n w

Transparent if no secrets used to compute pp

ZK-SNARK State

Just announced: Supersonic! Transparent, log(C) size proofs, log(C) Verifier time

Stateless Blockchains via Accumulators

Cryptographic Accumulators:

• Commit to a set of elements with a short value
• Provide short of membership

○ E.g. Merkle Tree

• Provide short proof of non-membership
• Dynamic

○ Can efficiently add and remove elements

• Example: RSA-Accumulator

○ Element are hashed to set of primes ○ Accumulator: g∏H(ei) ○ Operations are expensive ○ Trusted setup on RSA group ○ Transparent on class groups

• Breakthrough result [BBF CRYPTO 19]

○ Batching techniques for accumulators

Stateless Blockchains via Accumulators

• High-level idea: Commit to blockchain state in an accumulator

○ Verifiers nodes only need to agree on and maintain accumulator value only ○ Users need to maintain proofs of membership of UTXOs in the accumulator ○ Aggregation techniques allows short proofs for many statements ○ Batching techniques allows to process many proofs at once

• Also works for Account-Balance systems

○ Need a slightly different tool: Vector Commitments ■ Accumulator but elements are indexed.

Take away

• Lots of “old” cryptographic tools waiting to be used in clever ways

○ Encryption ○ Signatures ○ Commitments ○ 𝝩 protocols ○ Credentials ○ ...

• Active areas of research with direct applications

○ Efficient ZK arguments ○ Random functions ○ Elliptic curves ○ Post-quantum ○ MPC ○ …

Contact: fernando@findora.org