Purchase of Physical Products Online

Abdullah Mohammed Alaraj

Information Technology Department College of Computer, Qassim University

Saudi Arabia arj@qu.edu.sa

Abstract-This paper proposes a new offline TTP-based fair

exchange protocol. The protocol will allow customers to buy physical products (such as computers, furniture, and so forth)

from merchants online. The protocol will ensure fairness for both

customer and merchant. That is, the customer will get the

physical product and the merchant will get the payment or

neither does. Only six messages to be exchanged between the

parties involved in the protocol. Automatic dispute resolution is

provided in case one party misbehaves.

Keywords-fair exchange protocol; e-commerce; physical products; cryptographic protocols

I. INTRODUCTION

In the Internet world, customer and merchant normally do not trust each other. If the customer does not trust the merchant then they will not send the payment to them without making sure that the merchant will send the product to them. Also, the merchant will not send the product to the customer unless they receive the payment. In the purchase process, one of the parties (customer or merchant) will be at risk because they need to send their item (payment or product) fIrst to the other party. The customer is usually the party who sends their item fIrst. Therefore, as the customer is the fIrst party to send the payment to the merchant, there is a chance where the merchant acts dishonestly by either not sending the product to the customer or sending incorrect product. Therefore, to solve this problem in the e-commerce domains, e-commerce fair exchange protocols are used to ensure that either both the customer gets the product and the merchant gets the payment or none of them gets anything.

This paper proposes a new e-commerce fair exchange protocol that assures the customer and the merchant to get each other's items i.e. the customer gets the product and the merchant gets the payment or none of them gets anything. The proposed protocol is for the purchase of physical products online (physical products are products that need physical delivery such as phones, laptops, and so forth).

The paper is organized as follows. Section 2 discusses the literature survey. Section 3 presents the proposed protocol in two phases: the exchange protocol (where parties will exchange their items) and the dispute resolution protocol (where a party can raise dispute the third party if one party misbehaves).

II. LITERATURE SURVEY

Fair exchange protocols are used to help customers and merchants to exchange their items fairly over a communication network.

Fair exchange protocols are either gradual exchange protocols [4] or trusted third party (TTP) based protocols [1, 2, 3, 5, 11, 13, 17]. The gradual exchange protocols work as follows. The items to be exchanged are divided in parts. The fIrst party sends its fIrst part to the second party. The second party will then send its fIrst part to the fIrst party. The second part will then be exchanged between the two parties in the same manner. The exchange will continue until the whole items are exchanged between the two parties. The problem with this approach is that there is a chance that the last party will not send its [mal part. This is an unfair end for one of the parties. The involvement of the TTP in fair exchange protocols can be either online or offline. The online TTP-based fair exchange protocols [5] rely on the TTP during the exchange of the items. The offline TTP-based fair exchange protocols [1,2,3, 11, 13, 17] allow the parties to exchange their items directly without any involvement of the TTP. The TTP will be contacted in the case of dispute between the participating parties.

Zhang, Markantonakis, and Mayes [18] proposed an online TTP-based e-commerce fair exchange protocol for the exchange of payment and a physical product between two parties (customer and merchant). The customer starts the protocol by requesting a product from the merchant. On receiving the customer's request, the merchant sends the invoice to the customer. If the customer is satisfIed with the invoice then they will send two messages. The fIrst message is an encrypted payment to be sent to the merchant and the second message is the encrypted payment to be sent to the TTP. It is assumed that the merchant is able to download the encrypted payment (that was sent by the customer to the TIP)

from the TTP. The merchant then compares the two encrypted payments. If they are compared correctly then the merchant is sure that the encrypted payment is correct. Then, the merchant sends the product to the delivery agent. The customer will then collect the product from the delivery agent. When the customer fInds that the product is the same as they expected, they send the decryption key to the merchant who will then decrypt the encrypted payment.

978-1-4673-1520-3/12/$31.00 ©2012 IEEE

The problems with Zhang, Markantonakis, and Mayes's protocol [18] are as follow. First, extra costs will be added for running the online TTP as it is needed during each exchange. Second, the protocol will not be executed if the online TTP has any failure. Third, the protocol requires the customer to send two payments. One payment will be sent to the TTP and the other payment will be sent to the merchant. Fourth, the protocol has not discussed the dispute resolution phase and therefore it is not clear how the dispute will be resolved. Li, Kou, and Du [10] proposed an e-commerce fair exchange protocol for the exchange of payment and physical product. No third party is included in the protocol. The protocol involves the bank (where all parties have their accounts) and the delivery agent that will deliver the physical product to the customer. Eight messages (steps) are needed in the protocol. The two parties will start the protocol by exchanging their signatures. Then, the delivery agent will deliver the physical product to the customer. If the customer is satisfied with the product then they will release the key to the delivery agent. Then, the physical product will be handed to the customer. The customer will then send a signed receipt to the delivery agent. The delivery agent will forward the key and the signed receipt to the merchant. The merchant will forward the key and the signed receipt to the bank. The bank will finally transfer the amount from the customer's account to the merchant's account. The problems with Li, Kou, and Du's protocol [10] are as follows. First, the customer and the merchant are required to have accounts at the same bank. It is not clear how the protocol will work if the two parties have accounts at different banks. Second, the protocol does not discuss the dispute resolution phase and therefore it is not clear how the disputes will be resolved if one of the parties acts dishonestly. In this paper, a new offline TTP-based e-commerce fair exchange protocol for the exchange of payment and physical product is proposed. The proposed protocol has only six messages to be exchanged between the parties involved. The proposed protocol discusses both the exchange protocol and dispute resolution protocol.

III. PHYSICAL PRODUCTS PURCHASE PROTOCOL

A. Notation

The following represents the notations used in the proposed protocol.

• C: Customer

• CB: Customer's Bank

• M: Merchant

• TTP: Trusted Third Party which is a party neither M nor C. The TTP is trusted by all parties. It is asswned that the TTP will not collude with any other party

• DA: Delivery Agent that is responsible for delivering the product to the customer

• h(X): a strong-collision-resistant one-way hash function, such as SHA-l [6]

• pkx = (ex, nJ: RSA Public Key of the party x [16], where nx is a public RSA modulus and ex is a public exponent

• skx = (dx, nx): RSA Private Key of the party x [16], where nx is a public RSA modulus and dx is a private exponent

• kx: a symmetric key generated by the party x

• C. ct: the certificate for the shared public key between C and the TTP. c.ct is issued by the TTP. A standard X.S09 certificate is used to implement c.ct

• enc.pkx(Y): an RSA encryption of Y using the public key pkx (ex, nx)' That is, enc.pkx(Y) = Ve

x mod nx = Z

• enc.skx(Z): an RSA decryption of Z using the private key skx (dx' nx)' That is, enc.skxCZ) = Zd

x mod nx = Y

• enc.kx(Y) : encryption of Y using a symmetric key kx (kx can be used for decrypting enc.kx(Y))

• Sig.x (A): the RSA signature of party x on A i.e. encrypting the hash value of A using the private key skx [16]. That is, Sig.x (A) = (h(A))dX mod nx

• P-Cert: payment's Certificate that is issued by the CB. The contents of P-Cert are:

o amount: the amount of payment o payee: the name of the party who will

receive the payment o hP: hash value of payment o heP: hash value of encrypted payment with

kc o heKc: hash value of encrypted kc with pkc, o Sig.CB: CB's signature on P-Cert

• A ---+ B: X: A sends message X to B

B. The Exchange Protocol

The following asswnptions are made in the proposed protocol. First, the Delivery Agent (DA) is trusted, will not collude with any party and is known to both C and M. Second, the same encryption, decryption and hash algorithms will be used all parties. Third, communication channels between parties are resilient i.e. all sent messages will be received by their intended receivers. The customer (C) needs to contact the TTP and its bank (CB) to get the necessary certificates to be used in the protocol messages. First, C and TTP will share a public key and hence C needs to get the certificate c.ct of the shared public key from the TTP. The shared public key between C and TTP is denoted as pkc, = (eeh net) and its corresponding private key is denoted as sket = (deh net). Sket is kept at TTP. Second, C needs to get the payment and its certificate P-Cert from the CB. The P-Cert is unique for each transaction.

The exchange protocol will start by the customer (C) sending the first message E-I to the merchant (M) as follows.

{E-I} C --+ M: desc + enc.kc(P) + P-Cert + c.ct +

enc.pkct(kc) + Sig.c(p)

C sends message E-I to M. "dese" describe the product that C wants from M. kc that is used to encrypt the payment is generated by C.

{E-2} M --+ DA: product

On receiving the first message E-I, M will verify the signatures of CB, C and TTP on P-Cert, Sige(P) and e.et, respectively. If they are correctly verified then M will verify the correctness of the encrypted payment ene.klP) by computing the hash value of ene.klP) and comparing it with the "heP" that is included in P-Cert. If they match then M can be sure that C encrypted the payment using kc' M will also compute the hash value of "ene.pkcl(kc)" and then compare it with "heKe" that is included in P-Cert. If they match then M can be sure that the encrypted key in E-l is kc.

If all verifications are correct then M will send the product to the delivery agent (DA).

{E-3} DA --+ C: product

On receiving the product, DA will send the product to C.

{E-4} C --+ DA: Sig.c(receipt)

On receiving the product, C will check if it meets the "dese"

that was specified in E-l. If so then C will sign a receipt. The signed receipt indicates that C is satisfied with the product. If C is not satisfied with the product then DA will return the product back to M.

If C found that the received product is the one specified in "dese" then C will send message E-5 to M. On receiving E-5, M will first decrypt ene.pkn.{skcJ then use skc1 to decrypt ene.pkc,{kc). Finally, kc will be used to decrypt ene.klP) to get the payment.

{E-6} DA --+ M: Sig.c(receipt)

After DA received the signed receipt from C (i.e. in E-4), DA forwards the signed receipt to M. M will use the signed receipt in case of dispute to assure TTP that C has received the product. After E-6, C gets the product and M gets the payment. If, however, C behaves dishonestly by not sending the decryption key to M or by sending incorrect decryption key to M then M can contact the TTP to resolve the dispute.

e. Dispute Resolution Protocol

In case C cheated by sending incorrect decryption key in E-5 or C did not send the decryption key at all, M will be able to recover the decryption key from TTP. To do so, M will send DR-l to the TTP. DR-l includes "Sige(reeeipt)" that was sent to M in E-6.

{DR-I} M --+ TTP: Ack

On receiving DR-I, TTP will check C's signature on "Sige(reeeipt)". If the signature is correctly verified then this means that C has received the product and is satisfied with it. Therefore, TTP retrieves the decryption key "skct" from its database then it will send it to M. The decryption key "skct" will be used to decrypt the key "kc" that will then be used to decrypt the payment. If, however, the signature is not correctly verified then TTP will reject M's request.

{DR-2} TTP --+ M: enc.pkm(skct)

On receiving DR-2, M will first decrypt "ene.pkn.{skcJ" then use "skc," to decrypt "ene.pkc,{kc)". Finally, kc will be used to decrypt ene. klP) to get the payment.

Now, C gets the product (in the exchange protocol) and M gets the payment (either in the exchange protocol or in the dispute resolution protocol). Therefore, fairness is ensured for both the customer and the merchant.

IV. CONCLUSION

A new e-commerce fair exchange protocol is proposed in this paper. The proposed protocol is for exchanging physical products and payments between two parties. An offline TTP is used in the protocol i.e. it will only be contacted in the case of dispute. The proposed protocol consists of only six messages. Not like similar protocols in the literature, the proposed protocol discusses both the exchange phase and dispute resolution phase.

Future work will analyze the proposed protocol. It will also compare it with similar protocols. Additionally, the protocol will be implemented.

REFERENCES

[I] Alaraj, A. and Munro, M. An e-commerce fair exchange protocol that enforces the customer to be honest. International Journal of Product Lifecycle Management, llPLM, 3, 2/3 (2008), 114-13l.

[2] Alaraj, A. and Munro, M. An Efficient E-Commerce Fair Exchange Protocol that Encourages Customer and Merchant to be Honest. In Proceedings of the 27th International Conference on Computer Safety, Reliability and Security (SafeComp), New Castle: Springer-Verlag, Lecture Notes in Computer Science, Vol. 5219,2008, pp. 193-206.

[3] Asokan, N.; Schunter, M. and Waidner, M. Optimistic Protocols for Fair Exchange. In Proceedings of the Fourth ACM Conference on Computer and Communication Security, Zurich, 1997, pp. 8-17.

[4] Ben-Or, M.; Goldreich, 0.; Micali, S. and Rivest, R. A fair protocol

for signing contracts. IEEE Transactions on Information Theory, 36, I (I990), 40-46.

[5] Devane, S.; Chatterjee, M. and Phatak, D. Secure E-Commerce

Protocol for Purchase of E-Goods - Using Smart Card. In the 3d IEEE International Symposium on Information Assurance and Security,

Manchester, 2007, pp. 9 - 14.

[6] Ferguson, N. and Schneier, B. Practical Cryptography. Indianpolis, Indiana: Wiley, 2003

[7] Heintze, N.; Tygar, J.; Wing, J. and Wong, H. Model Checking

Electronic Commerce Protocols. In Proceedings of the 2nd USENIX Workshop in Electronic Commerce, Oakland, California, 1996, pp.

146-164.

[8] Hernandez-Ardieta, l; Gonzalez-Tablas, A.; and Alvarez, B. An optimistic fair exchange protocol based on signature policies.

Computers Security, 27, 7-8 (2008), 309-322

[9] Kremer, S.; Markowitch, O. and Zhou, l An intensive survey of fair non-repudiation protocols. Computer Communications, 25, 17 (2002),

1606-1621

[10] Li, H.; Kou, W. and Du, X. Fair E-Commerce Protocols without a Third Party. In Proceedings of the 11th IEEE Symposium on

Computers and Communications (ISCC'06), Italy, 2006, pp. 324-327.

[I I] Nenadic, A.; Zhang, N.; Cheetham, B. and Goble, C. RSA-based certified delivery of e-goods using verifiable and recoverable signature

encryption. Journal of Universal Computer Science, 11,1 (2005), 175-

192.

[12] Nenadic, A.; Zhang, N. and Shi, Q. RSA-based verifiable and

recoverable encryption of signatures and its application in certified e­mail delivery. Journal of Computer Security, 13,5 (2005), 757-777.

[13] Ray, I.; Ray, I. and Narasimhamurthy, N. An anonymous and failure

resilient fair-exchange e-commerce protocol. Decision Support Systems, 39 (2005), 267- 292.

[14] Ray, I. and Ray, I. An Optimistic Fair Exchange E-Commerce Protocol

with Automated Dispute Resolution. In Proceedings of 1st Electronic Commerce and Web Technologies Conference, London: Springer­

Verlag, Lecture Notes in Computer Science, vol. 1875, 2000, pp. 84-

93. [15] Ray I and Ray I. Fair exchange in e-commerce. ACM SIGecom

Exchange. 3, 2 (2002),9-17.

[16] Rivest, R.; Shamir, A. and Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Communications of the

ACM, 21, 2 (1978),120 -126.

[17] Zhang, N.; Shi, Q.; Merabti, M. and Askwith, R. Practical and efficient fair document exchange over networks. The Journal of Network and

Computer Applications, 29, 1 (2006) 46-61.

[18] Zhang, Q.; Markantonakis, K. and Mayes, K. A practical Fair Exchange E-payment Protocol for Anonymous Purchase and Physical Delivery.

In proceedings of the 4th ACS/TEEE International Conference on

Computer Systems and Applications, UAE, 2006, pp. 851-858.