Combating Double-Spending Using Cooperative P 2 P Systems Author : Ivan Osipkov , Eugene Y. Vasserman , Nicholas Hopper , Yongdae Kim Source : International Conference on Distributed Computing Systems, 25 -27 June 2007, page 41 -50 Presenter : Hsiao-Chi Chiang (江小琪) Date : 2010/10/15 1
Outline ß ß ß ß Introduction E-cash system Algorithm Security Complexity Experiment result Conclusions 2
Introduction Goal ³ Introduces a new peer-to-peer system architecture to prevent double-spending without requiring an on-line trusted party or tamper-resistant software or hardware. Scenario ³ This system design is a three-party model, with ® ® ® the broker as a dedicated (but not necessarily on-line) server the merchant as a drop-in module for an existing web server the client as a browser plug-in 3
E-cash system Merchant 1 Client C Witness 1 Mc (1)Withdraw e-coin(s) C (4)Sign payment transcript (2)Buy with e-coin C Broker B (5)Redeem payment transcript(s) E-cash aware (3)Certify e-coin C Merchant 2 M Witness 2 Cash transactions Bank 4 E-cash unaware
Protocol Operations with e-cash involve three protocols: withdrawal ³ payment ³ Deposit ³ (1) Let q be two large primes (2) g be a random generator of order q (3) ˂g˃ is subgroup generated by g (4) let g 1 and g 2 be two random generators of ˂g˃ (5) B chooses a secret key x and publishes the authenticated key y = g x 5
Algorithm 1 - Withdrawal Protocol Broker B (0)Publish Sig. B(version/date , {IMc , r Mc, 1 , r. Mc, 2}) a=gu , b=gs Zd (1) (3) random u, s, d Z=Ƒ(info) c = e-d mod q r = u-cx mod q x= secret key (1) Send a, b Client C 1. Choose: random ti , i=1, …, 4 (2) Send e (2) and x 1, x 2, y 1, y 2 2. Compute: • α=agt 1 yt 2 , β=bgt 3 z t 4 • ϵ = Η(α||β||z|| A ||B) (3) Send ( r , c , s ) • A = g 1 x 1 g 2 x 2, B = g 1 y 1 g 2 y 2 • e = ϵ-t 2 -t 4 mod q (4) Client Compute ρ = r+t 1 mod q ω= c+ t 2 mod q σ = s+t 3 mod q δ = e-c+t 4 mod q Check equality ω+δ = ϵ= Η(gρyω||gσzδ|| z || A ||B) mod q The bare coin = ( ρ , ω , σ , δ , A , B ) Attaches the Sig. B(version/date , {IMc , r Mc, 1 , r. Mc, 2}) C = ( ρ , ω , σ , δ , A , B , Sig. B(version/date , {IMc , r Mc, 1 , r. Mc, 2})) 6
Algorithm 2 - Payment Protocol Client C (2) Witness Mc Merchant M (1) Coin_hash= h ( ρ , ω , σ , δ , info, A , B ) (1) (coin_hash , nonce) nonce =h(salt c ||IM ) , salt c is random v is either some IM is the identify of the merchant random value, r =x +d‧y 1 or tuple (x 1 , x 2 (2) Sig. Mc(coin_hash , nonce , h(ν) , te , commit ) (3) 1 1 r 2=x 2+d‧y 2 ) or (y 1 , y 2 ) d=Ho(C, IM, data/time) (3) Payment transcript = ( C , r 1, r 2 , IM , data/time) M check witness, Sig. Mc (coin_hash , nonce , h(ν) , te , commit ) commitment, nonce (4) salt c and A‧Bd=g 1 r 1‧g 2 r 2 Mc check payment transcript (4) Payment transcript = ( C , r 1, r 2 , IM , data/time , salt check nonce c) (5) Sig. Mc ( payment transcript ) or (x 1, x 2) and/or (y 1, y 2) or refuse =h(salt c ||IM ) (6) Service , (x 1, x 2) and/or (y 1, y 2) 7
Algorithm 3 - Deposit Protocol Merchant M Broker B (1)Send payment transcript , Sign. Mc (payment transcript ) Payment transcript = ( C , r 1, r 2 , IM , data/time , salt c) C = ( ρ , ω , σ , δ , A , B , Sig. B(version/date , {IMc , r Mc, 1 , r. Mc, 2})) B verifies its own signature on the coin B verifies the signature of the witness on the payment, computes d and checks the A‧Bd=g 1 r 1‧g 2 r 2 (2) B searches its database to determine if the bare coin = (ρ, ω, σ, δ, info, A, B) has previously been deposited. 8
Security If the client knows a representation of A (B) : ³ ³ 1) the client actually constructed the coin. 2) the client knows no other representation of A (B). we can make the following conclusions: ³ ³ ³ 1) only the coin owner can successfully make a payment. 2) a payment transcript does not allow one to generate another payment transcript. 3) if the coin owner double-spends, the representation of A and/or B can be extracted which serves as a definitive proof of double-spending. 9
Complexity Table. 1 Number of cryptograghic operations Exp Hash Sig Ver Withdrawal Client Broker 12 3 4 1 0 0 1 0 Payment Client Witness Merchant 3 6 6 0 2 0 Deposit Merchant Broker 0 7 7 +2 0 6 0 4 0 0 1 1 3 -1 0 1 10
Experimental Result Table 2. Wall-clock runtime and bandwidth for payment protocol over 100 trials Client total time Client bytes transmitted Average 1789 ms 1. 6 KB St. dev. 324 ms 1. 3 B An informal survey of a popular ad-supported web site shows that it serves up 37. 13 KB in two ad images and associated links for the main page. The client and broker were located in Wisconsin, the witness in California, and the merchant in Massachusetts. 11
Conclusions ß ß A framework for anonymous e-cash that prevents double-spending without an online trusted authority or special-purpose hardware. If the coins are stolen, the damage to the client will consist only of the value of the stolen coins. 12
Скачать презентацию Combating Double-Spending Using Cooperative P 2 P Systems
191d3a5f6064c6281300f12fbc7a8e15.ppt