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

An Anonymous Fair-Exchange E-

Commerce Protocol

Indrajit RayComputer Science

DepartmentColorado State Universityindrajit@cs.colostate.edu

Outline Motivation

Fair-exchange Cross-validation Anonymity

Background Protocol Description Conclusion

Motivation

Fair Exchange

The ProblemI 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 10thvictim today. Bye Bye

Tough luck lady! We cannot trace

him!!

The Problem

Complain! 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 doStrong or true fair-exchange

Gather enough evidence so that wrong doer can be brought to justice

Weak fair-exchange

Motivation (2)

Cross Validation

The ProblemI 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 20thvictim 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! 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 ProblemI 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! 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 K1 and K2 are said to be compatible if

K1 e,N1 , K2 e,N2 share the same exponent e

N1 and N2 are relatively prime

e is relatively prime to N1 and N2

K i e,N i ,K i 1 d,N i such that ed 1mod N i

and e is relatively prime to N i

Nature of Keys Used (2) The product of two compatible keys K1

and K2 is defined as

Used by customer for product validation

K1 K2 e,N1 N2

m,K i me mod N i

mKKKmKKKm 1221

1121 ,,,,

m,K1 K2 ˆ m ,K1 modN1 iff m ˆ m

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

K1,K1 1

m,K1

Protocol - Step 0 Customer selects a

product m, to download based on the description Downloads

Customer generates a one time public / private key pair

m,K1

Cipub ,Ciprv

Protocol - Step 1 Customer indicates

intent to purchase by sending Signed Purchase

order Pseudo identity C

and one time public key, Cipub

Digest of PO signed by one time private key

CC PO ,Ciprv

PO,Ciprv

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

CC PO ,Ciprv ,M prv

K1 K2, namely,

m,K1 K2

Macct ,MBpub

Protocol - Step 3 Customer validates

product Compares downloaded

product with that received from merchant

Sends money transfer instruction to bank Customer’s account

number (Cacct) and amount to be transferred to encrypted account

m,K1

m,K1 K2

Macct ,MBpub

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

Macct ,MBpub

CC P ,Bprv

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

Macct , MBpub

Protocol - Step 8 Merchant sends

product decryption key, , encrypted with customer’s one time public key,

K2 1

Cipub

K2 1,Cipub

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

PO,Ciprv , CC PO ,Ciprv , CC PO ,Ciprv ,M prv ,P,Bprv , CC P ,Bprv

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

PO,Ciprv , CC PO ,Ciprv , CC PO ,Ciprv ,M prv ,P,Bprv , CC P ,Bprv

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

m,K1 K2 ˆ m ,K1 modN1 iff m ˆ m

m,K1

m,K1 K2

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 AnonymityInformation Customer’s Bank Merchant’s Bank Merchant Third Party

Customer’s ID Yes No No No

Cust. Bank’s ID Yes Yes No No

Merc. Bank’s ID No Yes Yes No

Merchant’s ID No Yes Yes No

Third Party’s ID No No Yes Yes

Cust. Account Yes No No No

Merc. Account No Yes Yes No

Purchase Order No No Yes Maybe

Cipub No No Yes Maybe

Cpub Yes No No No

No No Yes Maybe

No No Yes Yes

No No Yes Maybe

Payment token Yes Yes Yes Maybe

m,K1 K2

K1,K1 1

K2 1

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