1. An Anonymous Fair- Exchange E-Commerce Protocol Indrajit Ray Computer Science Department Colorado State University indrajit@cs.colostate.edu

2. Outline  Motivation Fair-exchange Cross-validation Anonymity  Background  Protocol Description  Conclusion

3. Motivation Fair Exchange

4. The Problem I want to purchase Mento Madness No problem! That will be $25 Your financial info is 128 bit SSL encrypted Okay here is an e-check for $25

5. The Problem He! He! That’s my 10th victim today. Bye Bye

6. Tough luck lady! We cannot trace him !! The Problem Complain!

7. What’s Needed? – Fair Exchange  Must ensure that no player suffers owing to the malicious behavior of the other player Either both players receive each other’s commodities or none do  Strong or true fair-exchange Gather enough evidence so that wrong doer can be brought to justice  Weak fair-exchange

8. Motivation (2) Cross Validation

9. The Problem I want to purchase Mento Madness No problem! That will be $25 Your financial info is 128 bit SSL encrypted Good!! Here is Mento Madness Okay here is $25

10. The Problem He! He! That’s my 20th victim today. This is Getting better all the time

11. The Problem This is not Mento Madness!! This is garbage!!!! Tough luck lady! We cannot trace him!! Complain!

12. The Solution – Cross Validation  Ensure (somehow) that the product the customer is about to receive from the merchant is indeed the product he is paying for

13. Motivation (3) Anonymity

14. The Problem I want to purchase Mento Madness No problem! That will be $25 Good!! Here is Mento Madness Here is my guarantee Thank you – here is $25

15. The Problem This lady likes Jamaican music!! Spam her with other offers

16. The Problem I am receiving zillions of SPAM Tough luck lady! You missed the fine prints. This is not SPAM Complain!

17. The Solution  Ensure that a transaction cannot be linked to or traced back to a particular customer  Optionally ensure the same for the merchant

18. Background Theory of Cross Validation

19. Nature of Keys Used  Asymmetric keys   Two keys K 1 and K 2 are said to be compatible if

20. Nature of Keys Used (2)  The product of two compatible keys K 1 and K 2 is defined as Used by customer for product validation

21. Protocol - The Actors  Customer For this transaction assumes a pseudo identity C

22. Protocol - The Actors  Customer  Merchant

23. Protocol - The Actors  Customer  Merchant  Customer’s bank

24. Protocol - The Actors  Customer  Merchant  Customer’s bank  Merchant’s bank

25. Protocol - The Actors  Customer  Merchant  Customer’s bank  Merchant’s bank  Trusted third party

26. Protocol - Step 0  Merchant registers with third party Sends the product (m), its description (d) and keys Third party validates description against product Third party uploads to its web site

27. Protocol - Step 0  Customer selects a product m, to download based on the description Downloads  Customer generates a one time public / private key pair

28. Protocol - Step 1  Customer indicates intent to purchase by sending Signed Purchase order Pseudo identity C and one time public key, C ipub Digest of PO signed by one time private key

29. Protocol - Step 2  Merchant sends to customer Counter signed digest of PO Product m encrypted with key Merchant’s bank account information encrypted with merchant’s bank’s public key

30. Protocol - Step 3  Customer validates product Compares downloaded product with that received from merchant  Sends money transfer instruction to bank Customer’s account number (C acct ) and amount to be transferred to encrypted account

31. Protocol - Step 4  Bank debits customer’s account and sends signed payment token to customer  Payment token, P contains Amount paid Nonce to prevent replays  Signed checksum of P

32. Protocol - Steps 5 & 6  Customer sends signed payment token to Merchant  Merchant forwards signed payment token to its bank

33. Protocol - Step 7  Merchant’s bank Verifies CB’s signature on payment token Decrypts Credits merchant’s account by amount given in payment token Sends acknowledgment to merchant

34. Protocol - Step 8  Merchant sends product decryption key,, encrypted with customer’s one time public key,

35. Analysis of Fair Exchange  Customer’s misbehavior does not create problem Unless proper amount is credited to merchant’s bank, merchant does not send decryption key If customer maliciously claims merchant’s misbehavior, customer needs to produce

36. Analysis of Fair Exchange  Merchant may not send decryption key after receiving payment Customer complains to trusted third party by producing If claim substantiated, trusted third party can provide customer with m

37. Analysis of Cross-Validation  Customer validates,downloaded from trusted third party with received from merchant Recall  Pays if and only if the validation is successful

38. Analysis of Anonymity  No single party has enough information to link customer to merchant  No collusion is possible which will result in the disclosure of this information. To collude, two parties Must know each other’s identity and Must have some common piece of information pertaining to the transaction

39. Analysis of Anonymity InformationCustomer’s BankMerchant’s BankMerchantThird Party Customer’s IDYesNo Cust. Bank’s IDYes No Merc. Bank’s IDNoYes No Merchant’s IDNoYes No Third Party’s IDNo Yes Cust. AccountYesNo Merc. AccountNoYes No Purchase OrderNo YesMaybe C ipub No YesMaybe C pub YesNo YesMaybe No Yes No YesMaybe Payment tokenYes Maybe

40. Conclusions  Fair Exchange protocol that ensures cross validation of product as well as anonymity of customer  Minimal use of trusted third party Used only when something goes wrong

41. Questions