Constructing Fair-Exchange Protocols for E-commerce Via Distributed Computation of RSA Signatures

1. Constructing Fair-Exchange Protocols for E-commerceVia Distributed Computation of RSA Signatures Jung Min Park, Edwin K. P. Chong, Howard Jay Siegel 22-th Annual ACM Symp. on Principles of Distributed Computing, July 2003.

2. Outline • Introduction • Related Work • Technical Background • The Fair-exchange Protocol • Efficiency Evaluations • Conclusion

3. INTRODUCTION • fair-exchange problem • either each party gets the other's item, or neither party does • fair-exchange protocol • Require zero-knowledge proofs in exchange protocol • Novel method for constructing efficient fair-exchange protocol • Employ RSA-based multisignatures • No zero-knowledge proofs in exchange protocol and only once in setup phase(one-time cost) • compatible with the underlying standard (single-signer) signature scheme

4. INTRODUCTION--fair-exchange protocol • gradual exchange protocols • probability of fair exchange is gradually increased over rounds • Impractical: communication intensive, require equal computational power to ensure the security • protocols requiring an online trusted third party (TTP) • TTP must be available for the entire duration of every exchange • protocol is simple and efficient • on-line TTP is expensive, can become bottleneck • optimistic fair-exchange protocols (with an offline TTP) • TTP is involved only if one party behaves unfairly or aborts the protocol prematurely, otherwise never involved. • Seem to be most practical

5. INTRODUCTION--optimistic fair-exchange protocol • two types of protocol frameworks • Asokan et al, Bao et al • cryptographic primitive • each protocol employs a different technique for constructing it • ensures fairness(Fairness primitive) • is the cornerstone of the fair-exchange protocol • its design poses the greatest technical challenge.

6. EXCHANGE Alice --- cA,V --> Bob Alice <--- σB----- Bob Or Bob stop the protocol Alice ---- σA----> Bob Or Alice stop the protocol End by Bob or initiates the dispute resolution protocol DISPUTE RESOLUTION Initiate by Bob If σA is invalid(4) or Bob do not receive σA(3) Bob --- cA,V, σB --> Charlie Charlie compute σA Bob <-------- σA---- Charlie Alice <-------- σB---- Charlie Alice and Bob : two players exchanging digital signatures σAand σBon a message M Charlie : TTP Fairness primitive cA : commitment that Alice send to Bob, no intrinsic value V : voucher that provides proof of the following: (i) exist a tamperproof one-to-one link between cA and σA, and (ii) Charlie can compute σAusing cAif needed. optimistic fair-exchange protocol framework example

7. RELATED WORK • four types of optimistic fair-exchange protocols (categorized by fairness primitive creation) • (i) protocols using verifiable escrows • Pro:can apply to almost any signature scheme • Con: computation and communication overhead • (ii) protocols using verifiable encryptions • Pro: efficiency(less computation and communication overhead) • Con: vulnerable to security flaw (based on ad hoc techniques) • (iii) protocols using convertible undeniable signatures • con: also utilizes zero-knowledge proofs in the exchange protocol • Con: needs a different verification algorithm compare to standard signature • (iv) protocols using one-time tokens • Pro: no zero-knowledge proofs in the exchange protocol • Con: not a truly optimistic protocol, TTP has to be involved intermittently to replenish the exhausted one-time tokens.

8. TECHNICAL BACKGROUNDMultisignatures(1/2) • multisignature scheme • Multiple-signers signature has little or no difference in size with an individual signature • multisignatures are compatible with the underlying (single-signer) signature scheme. • most convertible undeniable signatures not • algorithm is identical between multisignature verifying and underlying signature scheme verifying

9. TECHNICAL BACKGROUNDMultisignatures (2/2) • a typical multisignature scheme • n (>=2) signers, 1 verifier • ski : partial private key of signer i • σi : partial signature created by partial private key ski • pki : partial public key corresponding to ski • sk : joint private key, sk = sk1 +…+ skn • σ : multisignature combined form the σi , and will send to the verifier • pk : joint public key corresponding to sk • verifier will verifies σ using pk • If correctly, it is infeasible to create a multisignature using only a proper subset of {sk1 ,…, skn}

10. a modified version of the typical multisignature model primary signer is the “owner” of the multisignature primary signer(Alice) sk1(σ1(Alice’s commitment) ), with corresponding pk1 sk2 (σ2 )(no pk2) σ(Alice’s signature) : σ1 + σ2 Cosigner(Charlie-TTP) sk2( σ2) Verifier(Bob) σB EXCHANGE Alice --- σ1,V --> Bob Alice <--- σB----- Bob Or Bob stop the protocol Alice ---- σ ----> Bob Or Alice stop the protocol End by Bob or initiates the dispute resolution protocol DISPUTE RESOLUTION Initiate by Bob If σ is invalid(4) or Bob do not receive(3) Bob --- σ1,V, σB --> Charlie Charlie compute σ Bob <-------- σ ---- Charlie Alice <-------- σB ---- Charlie TECHNICAL BACKGROUNDOur Multisignature Paradigm

11. TECHNICAL BACKGROUNDThe RSA Signature Scheme • RSA Scheme • p, q : big primes ; N = p * q • e : public key • random integer e, 1<e<ψ(N),such that gcd(e,ψ(N))=1 • ψ(N) : Euler totient function. number of integers in the interval [1,N] that are relatively prime to N • ψ(N) = (p-1)*(q-1) when p,q are primes • d : private key • unique integer d, 1<d<ψ(N),such that ed = 1(mod ψ(N) • signature generation on message M • σ = H(M)dmod N • H:{0,1}*  ZN: public hash function • ZN : signature space , the set of integers modulo N • {0,1}* denotes a binary string of arbitrary finite length • Signature validation • σemodN = H(M)

12. TECHNICAL BACKGROUNDOur RSA-Based Multisignature Scheme(1/4) • Boyd’scheme splits d multiplicatively • d = d1d2(mod ψ(N) ) • H(M)d = H(M) d1d2(mod N) • We split d additively • p,q : safe primes • p = 2p’+1, q = 2q’+1, p’,q’ are all primes • ZN* : multiplicative group of integers modulo N • QN : the set of quadratic residues modulo N • signing space • QN = {a | a ZN* , there exists an x ZN*with x2=a(modN)} • QN is a cyclic subgroup of ZN* , QN ZN* • |QN|= |ZN*| / 4 = p’q’ = λ • d = d1 + d2(mod λ)

13. TECHNICAL BACKGROUNDOur RSA-Based Multisignature Scheme(2/4) • H(M)d = H(M) d1 * H (M) d2(mod N) • H:{0,1}*  QN: public hash function • partial public key e1 • d1e1 = (mod λ) • Lemma : • Let N = pq, where p = 2p’ + 1, q = 2q’ + 1,and p, q, p’, q’ are all prime numbers. Assume p < q. Then, • 1. The order of elements in ZN* is one of the integers in the set { 1, 2, p’, q’, 2p’, 2q’, p’q’, 2p’q’} • 2. Given an element a ZN* \ {-1,1}such that ord(a) < p’q’, then either gcd(a-1,N) or gcd(a+1,N) is a prime factor of N

14. TECHNICAL BACKGROUNDOur RSA-Based Multisignature Scheme(3/4) • characteristic of the elements of QN • For all b QN, b≠+-1, if gcd(b+1,N) and gcd(b-1,N) are not prime factors of N, then ord(b) = p’q’ • If b QN , then ord(b) is one of {a, p’, q’, p’q’} • By Lagrange's Theorem and |QN|= p’q’ • KEY GENERATION • p, q : safe primes ; N = p * q • e : joint public key • random integer e, 1<e< λ, such that gcd(e, λ)=1 • d : joint private key • unique integer d, 1<d< λ, such that ed = 1(mod λ) • e1, d1: e1d1 = 1(mod λ),similar to above • d2 :cosigner’s partial private key, d2 = d – d1 (mod λ) keys satisfy the following relations : ed = 1(mod λ) e1d1 = 1(mod λ) d1+ d2 = d (mod λ)

15. TECHNICAL BACKGROUNDOur RSA-Based Multisignature Scheme(4/4) • SIGNATURE GENERATION • σi = H(M)d imod N, i =1, 2 • H(M)d = σ1 * σ2 = H(M) d1+d2(mod N) • Signature validation • σ1 e1 mod N = H(M) • σ e mod N = H(M) • splitting d multiplicatively(Boyd’scheme) in the protocol is insecure • (e * d2 – e1) is a mulyiple of λ • cosigner can factor N efficiently using Koblitz's probabilistic algorithm by λ • compute d1via the extended Euclidean algorithm

16. TECHNICAL BACKGROUNDTHE FAIREXCHANGE PROTOCOL(1/3) • Players • Alice(primary signer, customer) • Charlie(cosigner, TTP) • Bob(verifier, merchant) • REGISTRATION • Alice prove to Charlie • e1d1 = 1(mod λ) • e(d1 +d2)= 1(mod λ) • without revealing d1 and λ(Charlie knows the rest of the keys) • Charlie sends VCto Alice • VC : voucher created by Charlie signing on e1 • VC assures the following: (i) verification of e1to Alice, and (ii) verification of the keys’ algebraic relations • and, as a result, Charlie can generate a multisignature from the corresponding partial signature

17. TECHNICAL BACKGROUNDTHE FAIREXCHANGE PROTOCOL (2/3) • EXCHANGE • Alice ---CCA ,σ1, Vc --> Bob • Alice <--- Eγ(μ)----- Bob • Or Bob stop the protocol • Alice ---- σ----> Bob • Or Alice stop the protocol • End by Bob • or initiates the dispute resolution protocol • σ1and Vcconstitute the fairness primitive cA and V • CCA: certificate by Certificate Authority(CA) certifing e and N • Eγ(μ): encrypted merchandise, constitute the σB • σasσA

18. TECHNICAL BACKGROUNDTHE FAIREXCHANGE PROTOCOL (3/3) • DISPUTE RESOLUTION • Initiate by Bob • If σ is invalid(4) or Bob do not receive σ(3) • Bob --- σ1, Vc, Eγ(μ),CCA , M--> Charlie • Charlie compute σ • σ = σ1 * H(M)d2 (mod N) • Bob <-------- σ ----------- Charlie • Alice <-------- Eγ(μ) ---- Charlie

19. EFFICIENCY EVALUATIONS

20. CONCLUSIONS • a novel multisignature paradigm • which is quite different from the conventional model • a novel method for constructing efficient optimistic fair-exchange protocols using RSA-based multisignatures. • Advantages of Our approach • Efficient • No zero-knowledge proofs in the exchange protocol, only in the registration phase • Simple • uses multisignatures that are compatible with the underlying (single-signer) signature • Flexible • Can be applied to constructing fair-exchange protocols via multisignatures based on signature algorithms other than RSA • can be used with the protocol framework of Asokan et al