PGC: Decentralized Confjdential Payment System with Auditability Yu Chen Shandong University Xuecheng Ma SKLOIS, CAS Cong Tang pgc.info Man Ho Au The University of Hong Kong ESORICS 2020 http://eprint.iacr.org/2019/319 https://github.com/yuchen1024/libPGC 1 / 43
Outline 1 Background 2 Framework of Auditable DCP System 3 An Effjcient Instantiation: PGC 4 Summary 2 / 43
Outline 1 Background 2 Framework of Auditable DCP System 3 An Effjcient Instantiation: PGC 4 Summary 3 / 43
Privacy in Payment System no one can fjgure out the transfer amount no one can identify the “true” sender and recipient 4 / 43 1024
Auditablity in Payment System tx tx validity check audit 5 / 43 f ( { tx i } ) ? = 1 f denotes the audit predicate that checks if { tx i } satisfy some specifjed policy
Centralized Payment System txs are kept on a private ledger only known to the center the center is in charge of validity check as well as protecting privacy and conducting audit 6 / 43
Decentralized Payment System (Blockchain-based Cryptocurrencies) txs are kept on a global distributed public ledger — the blockchain to ensure public verifjability, Bitcoin and Ethereum simply expose all tx 7 / 43 information in public � no privacy
Motivation Privacy and Auditability are crucial in any fjnancial system, we want to know: In the decentralized setting, can we have the good of both? Confjdentiality Anonymity Auditability double-edged sword co-exist plausiable deniability In this work, we trade anonymity for auditablity, propose the fjrst auditable decentralized confjdential payment (DCP) system in the account-based model 8 / 43
Outline 1 Background 2 Framework of Auditable DCP System 3 An Effjcient Instantiation: PGC 4 Summary 9 / 43
Algorithms of Auditable DCP (Account-based Model) ctx 10 / 43 Setup (1 λ ) → ( pp ) CreateCTx ( sk 1 , pk 1 , pk 2 , v ) → ctx CreateAccount (˜ v 1 , sn 1 ) CreateAccount (˜ v 2 , sn 2 ) VerifyCTx ( ctx ) ? = 1 [ pk 1 , sk 1 , ˜ [ pk 2 , sk 2 , ˜ C 1 , sn 1 ] C 2 , sn 2 ] update ˜ update ˜ C 1 C 2 increase sn 1 AuditCTx ( f, ctx , π ) → 0/1 sn , memo = ( pk 1 , pk 2 , C ) , aux
Desired Functionality and Security Verifjability validity of txs are publicly verifjable Authenticity only the sender can generate txs, nobody else can forge Confjdentiality except the sender and receiver, nobody learns the transfer amount Soundness even the sender cannot generate an illegal tx that passes validity check Auditability particpants cannot cheat and audit is privacy-preserving 11 / 43
Formal Security Model (Oracles) register honest accounts corrupt honest accounts direct honest accounts to conduct ctx ask honest accounts to reveal ctx register corrupted accounts inject ctx from corrupted accounts 12 / 43 O extH O regH O trans O reveal O regC O inject
Formal Security Model: Authenticity 13 / 43 [ VerifyCTx ( ctx ∗ ) = 1 ∧ ] s ) : pp ← Setup ( λ ); Adv A ( λ ) = Pr . s ∈ T honest ∧ ctx ∗ / ctx ∗ ← A O ( pp ); pk ∗ ∈ T ctx ( pk ∗
Formal Security Model: Confjdentiality R Restrictions 1 and 2 prevents trivial attack by decryption, restrictions 3 prevent 14 / 43 pp ← Setup ( λ ); ( state, pk ∗ s , pk ∗ r , v 0 , v 1 ) ← A O 1 ( pp ); − 1 β = β ′ : Adv A ( λ ) = Pr ← − { 0 , 1 } ; 2 . β ctx ∗ ← CreateCTx ( sk ∗ s , pk ∗ s , pk ∗ r , v β ); β ′ ← A O 2 ( state, ctx ∗ ); To prevent trivial attacks, A is subject to the following restrictions: 1 pk ∗ s , pk ∗ r chosen by A are required to be honest accounts, and A is not allowed to make corrupt queries to either pk ∗ s or pk ∗ r ; 2 A is not allowed to make reveal query to ctx ∗ . 3 let v sum (with initial value 0 ) be the dynamic sum of the transfer amounts in O trans queries related to pk ∗ s after ctx ∗ , both ˜ v s − v 0 − v sum and ˜ v s − v 1 − v sum must lie in V . inferring β by testing whether overdraft happens.
15 / 43 Formal Security Model: Soundness [ VerifyCTx ( ctx ∗ ) = 1 : pp ← Setup ( λ ); ] Adv A ( λ ) = Pr . ∧ memo ∗ / ctx ∗ ← A O ( pp ); ∈ L valid Here, ctx ∗ = ( sn ∗ , memo ∗ , aux ∗ ) .
Choice of Building Blocks Verifjability Authenticity Confjdentiality Soundness Auditability additively HE eliminate out-of-band transfer Signature NIZK 16 / 43
A Subtle Point: Key reuse vs. Key Separation Pros and sign, while IND-CPA and EUF-CMA hold in the joint sense We choose Integrated Signature and Encryption (ISE): one keypair for both encryption case-tailored design Cons more effjcient greatly simplify DCP system key reuse We employ PKE and SIG simutaneously to secure auditable DCP. tricky address derivation double key size Cons ofg-the-shelf & easy to analyze Pros key separation 17 / 43 ( pk 1 , sk 1 ) , ( pk 2 , sk 2 ) ( pk, sk )
adaptive soundness Generic Construction of Auditable DCP: Building blocks adaptive ZK 18 / 43 ISE = ( Setup , KeyGen , Sign , Verify , Enc , Dec ) PKE component is additively homomorphic over Z p Fix pp , KeyGen naturally induces an NP relation: R key = { ( pk, sk ) : ∃ r s.t. ( pk, sk ) = KeyGen ( pp ; r ) } NIZK = ( Setup , CRSGen , Prove , Verify )
Algorithms of Auditable DCP: 1/4 19 / 43 Setup (1 λ ) : generate pp for the auditable DCP system pp ise ← ISE . Setup (1 λ ) , pp nizk ← NIZK . Setup (1 λ ) , crs ← NIZK . CRSGen ( pp nizk ) output pp = ( pp ise , pp nizk , crs ) , set V = [0 , v max ] CreateAcct (˜ v, sn ) : create an account ( pk, sk ) ← ISE . KeyGen ( pp ise ) , pk serves as account address ˜ C ← ISE . Enc ( pk, ˜ v ; r ) RevealBalance ( sk, ˜ C ) : reveal the balance of an account m ← ISE . Dec ( sk, ˜ ˜ C )
Algorithms of Auditable DCP: 2/4 20 / 43 CreateCTx ( sk s , pk s , v, pk r ) : transfer v coins from account pk s to account pk r . C s ← ISE . Enc ( pk s , v ; r 1 ) , C r ← ISE . Enc ( pk r , v ; r 2 ) , memo = ( pk s , pk r , C s , C r ) . run NIZK . Prove with witness ( sk s , r 1 , r 2 , v ) to generate a proof π correct for memo = ( pk s , pk r , C s , C r ) ∈ L valid �→ L equal ∧ L right ∧ L solvent L equal = { ( pk s , pk r , C s , C r ) | ∃ r 1 , r 2 , v s.t. C s = ISE . Enc ( pk s , v ; r 1 ) ∧ C r = ISE . Enc ( pk r , v ; r 2 ) } L right = { ( pk s , C s ) | ∃ r 1 , v s.t. C s = ISE . Enc ( pk s , v ; r 1 ) ∧ v ∈ V} L solvent = { ( pk s , ˜ C s , C s ) | ∃ sk 1 s.t. ( pk s , sk s ) ∈ R key ∧ ISE . Dec ( sk s , ˜ C s − C s ) ∈ V} σ ← ISE . Sign ( sk s , ( sn , memo , π valid )) output ctx = ( sn , memo , π valid , σ ) .
Algorithms of Auditable DCP: 3/4 signed message ctx is recorded on the ledger if validity test passes or discarded otherwise. 3 2 sn Figure: Data structure of confjdential transaction. aux 1 21 / 43 memo π valid π equal π right π solvent pk s , pk r , C s , C r σ VerifyCTx ( ctx ) : check if ctx is valid. parse ctx = ( sn , memo , π valid , σ ) , memo = ( pk s , pk r , C s , C r ) : check if sn is a fresh serial number of pk s (inspect the blockchain); check if ISE . Verify ( pk s , ( sn , memo , π valid ) , σ ) = 1 ; check if NIZK . Verify ( crs, memo , π valid ) = 1 . Update ( ctx ) : sender updates his balance ˜ C s = ˜ C s − C s and increments sn, receiver updates his balance ˜ C r = ˜ C r + C r .
Algorithms of Auditable DCP: 4/4 anti-money laundering ctx selective disclosure tax payment 22 / 43 JustifyCTx ( pk, sk, { ctx i } n i =1 , f ) : user pk runs NIZK . Prove with witness sk to generate a zero-knowledge proof π f for f ( { ctx i } n i =1 ) = 1 . f limit : ∑ n f open : v = v ∗ f rate : v 1 / v 2 = ρ i =1 v i < ℓ ctx 1 ctx i ctx 1 ctx 2 ctx n AuditCTx ( pk, { ctx i } n i =1 , f, π f ) : auditor runs NIZK . Verify to check if π f is valid.
Outline 1 Background 2 Framework of Auditable DCP System 3 An Effjcient Instantiation: PGC 4 Summary 23 / 43
Disciplines in Mind While the auditbale DCP framework is intuitive, secure and effjcient instantiation requires clever choice and design of building blocks . effjcient effjcient ctx generation/verifjcation compact ctx size transparent setup system does not require a trusted setup design case-tailored NIZK simple & modular build the system from reusable gadgets can be reused in other places 24 / 43
Zether’s approach [BAZB20] Encryption Component of ISE consistency require dissecting Bulletproof, not modular and Sigma protocol integration of Bulletproof -Bullet bring extra bridging cost Quisquis’s approach [FMMO19] proof protocol ElGamal commitment Pedersen td oblivious state-of-the-art Bulletproofs 25 / 43 g r pk r g m
Zether’s approach [BAZB20] Encryption Component of ISE consistency require dissecting Bulletproof, not modular and Sigma protocol integration of Bulletproof -Bullet bring extra bridging cost Quisquis’s approach [FMMO19] proof protocol ElGamal commitment Pedersen td oblivious state-of-the-art Bulletproofs 25 / 43 g r pk r g m
Zether’s approach [BAZB20] Encryption Component of ISE consistency require dissecting Bulletproof, not modular and Sigma protocol integration of Bulletproof -Bullet bring extra bridging cost Quisquis’s approach [FMMO19] proof protocol ElGamal commitment Pedersen td oblivious state-of-the-art Bulletproofs 25 / 43 g r pk r g m g r h m
Recommend
More recommend
