Implementation of Fair Exchange Protocol

In an e-commerce environment, the merchant and the customer are unlikely to trust each other. This problem has motivated researchers to propose fair-exchange protocols based on using an on-line trusted third party. We have implemented a fair exchange protocol which ensures:

i. ii.

Fair exchange. Not requiring manual dispute resolution in case of unfair behavior by any party

The customer The merchant & The Trusted Third Party (Administrator)
Customer
Merchant

Administrator

Every party involved in the transaction has to generate their keysPublic Key Private Key

Keys will be generated using the tools that can be downloaded from the web-site.

 The

Merchant encrypts his product with the Advanced Encryption Standard(AES) Encryption tool provided by the site. The merchant hides the encrypted product in an image. Then he uploads the image to the site and also provides the encrypted product key to the admin. Admin keeps this product key to give it to the customer in case of any dispute.

 The

administrator then verifies the product. After verification of the product the admin makes the product available for downloading.
Uploads product
Merchant Makes available for downloading Administrator Website

Verifies product

The fair exchange protocol begins when the customer downloads the product. After downloading he gets a Transaction Number. A series of messages are exchanged between the customer and the merchant.

Downloads product Customer

Website

Customer (C) initiates the e-commerce transaction by sending Merchant(M) three things: a purchase order, PO the public key of C Transaction number

Customer

{Purchase order Public Key & Transaction No.}

Merchant

M after receiving Message 1 checks if the purchase order is to his satisfaction. If M is not satisfied, he sends an abort message to C and aborts the transaction. If M is happy with the purchase order and wants to continue with the protocol he sends the following things to C:

Encrypted account information & Merchants public key.

If not satisfied, M sends abort msg Else M sends, Encrypted a/c info & his public key Merchant Customer

After receiving Message 2 from M, C checks to see if it is an abort message or the encrypted account information. If it is an abort, C aborts the transaction. If C has received the encrypted account information then he prepares a payment token for the specified account number and send it to merchant.
If it is an abort, C aborts the transaction.

Customer

Prepares & sends payment token for specified a/c no.

Merchant

 If

merchants account is successfully credited he sends the product key else he sends an abort message.

Sends product key Else sends abort message Merchant Customer

 The

customer cannot cheat as he wont be getting the product key until the merchants account gets credited successfully. The only possible fraud is from the merchants side & that is, he gets the payment from the customer and he refuses to send him the product key.

 Now

the trusted third party comes into picture. The administrator acts as the TTP. He then sees the messages that were sent during the transaction and checks whether the customer is been cheated, if so then the admin sends the product key to the customer.

The various possible enhancements of our project areThe number of messages exchanged per transaction can be reduced. Automation of certain tasks is possible. This protocol can be used in the ecommerce extensively to provide fair transaction.