An Anonymous Fair- Exchange E-Commerce Protocol Indrajit Ray Computer Science Department Colorado State University

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

Motivation Fair Exchange

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

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

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

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

Motivation (2) Cross Validation

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

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

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

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

Motivation (3) Anonymity

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

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

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

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

Background Theory of Cross Validation

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

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

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

Protocol - The Actors  Customer  Merchant

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Questions