You are on page 1of 13
Available online at www.sciencedirect.com Electronic Commerce Research and Applications 7 (2008) 247–259

Available online at www.sciencedirect.com

Available online at www.sciencedirect.com Electronic Commerce Research and Applications 7 (2008) 247–259

Electronic Commerce Research and Applications 7 (2008) 247–259

Commerce Research and Applications 7 (2008) 247–259 www.elsevier.com/locate/ecra Experiences in developing a

www.elsevier.com/locate/ecra

Experiences in developing a fair-exchange e-commerce protocol using common off-the-shelf components

Indrajit Ray * , Hongjun Zhang

Department of Computer Science, Colorado State University, 601 S Howes Street, Fort Collins, CO 80523, United States

Received 30 March 2005; received in revised form 15 February 2007; accepted 19 March 2007 Available online 24 March 2007

Abstract

Fair-exchange is an important property that must be ensured in all electronic commerce environments where the merchants and the customers are reluctant to trust each other. This property guarantees that none of the transacting parties suffer because of the fraudulent behavior of the other party in the transaction. In this paper, we describe our experiences in developing a new e-commerce protocol to address the problem of fair-exchange for digital products. The protocol is based on a novel cryptographic technique that we had pro- posed earlier. We show how to use common off-the-shelf software components to develop such a protocol. 2007 Elsevier B.V. All rights reserved.

Keywords: E-commerce; Fair-exchange; Certificate; Keystore; Keytool; Encryption; Decryption; JDBC; Servlet

1. Introduction

In an electronic commerce environment the merchants and the customers are reluctant to trust each other and the following scenario is not uncommon. A customer is not willing to pay for a product without being sure it is the right product sent by the merchant. A merchant is not willing to give the product unless he is sure that he will receive payment. If the merchant delivers the product without receiving the payment, the fraudulent customer may accept the product and then disappear, causing loss for the merchant. If the customer pays before receiving the product, the merchant may not deliver the product or may deliver some wrong product causing loss to the cus- tomer. This dilemma has prompted researchers to propose fair-exchange protocols that ensure no player in the trans- action suffers due to the unacceptable behavior of the other player.

* Corresponding author. E-mail addresses: indrajit@cs.colostate.edu (I. Ray), zhangho@cs. colostate.edu (H. Zhang).

1567-4223/$ - see front matter 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.elerap.2007.03.005

Fair-exchange protocols have been variously proposed in the context of electronic mail [13] and electronic transac- tions [1,9,14] . Most of these works [1,9,13] focus on storing evidence during protocol execution that is to be used in case one party misbehaves. If a dispute occurs, a human judge looks at the evidence and delivers his judgment. The dispute resolution is done after the protocol execution, that is, after the customer has obtained his product or the merchant his money. However, such ‘‘after-the-fact’’ pro- tection [14,15] may be too little, too late in an e-commerce environment solely because the customer and the merchant may not have identifiable places of existence and may be unreachable after the transaction. Protocols that do better than providing after-the-fact protection typically use an online trusted third party [6,15] . The trusted third party receives the information from each party and then forwards it to the other party. As a result if any party misbehaves or prematurely quits, no harm is caused to the other party. However, the third party is a source of bottleneck for these protocols. Not only is the performance of the third party an issue, but also its vulnerability to denial of service attacks.

248

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

Several protocols have been proposed [10–12] that do not use the third party unless a problem, such as, a party misbehaving or prematurely aborting, occurs. Such proto- cols are termed optimistic [3,10–12] . Some of these proto- cols do not ensure fairness [12] and others that do ensure fairness [3] are restricted to exchange of digital signatures. It is not clear whether these protocols are suitable for exchanging value products (that is products that are asso- ciated with a monetary value). In this paper, we describe a novel fair-exchange proto- col that we have developed. The protocol is based on the work by Ray et al. [5] . The protocol addresses the prob- lem of fair-exchange of value products. It is an optimistic protocol in the sense of the term defined in [10] . The pro- tocol ensures fairness under all possible circumstances. It does not require a manual ‘‘after-the-fact’’ dispute resolu- tion by a human judge. Additionally, a unique feature of this protocol is that it allows a customer to validate a product that is about to be received from the merchant before paying for it. Thus a customer is never faced with the situation of finding himself/herself with an incorrect product that has already been paid for and that cannot be returned anymore because the merchant is no longer available. A major motivation of this work was to investigate and identify the challenges a developer faced when implementing a complex cryptographic protocol for which there were no readily available toolkit support. We needed to modify the previous protocol [5] so as to be amenable to implementa- tion. Thus, we first describe the modified protocol. We then describe our efforts to implement the protocol in a complete e-commerce facility. The system described here is up and running. It has been tested to run on Windows 2000 , Solaris 2.8, and Red Hat Linux 7.1. We have implemented the e-commerce facility using Sun Microsystems’s Java technology. We used the following packages from the Java Development Kit (JDK) 1.3.1: java.awt , java.awt.event, java.io, java.math , java.net , java.security , java.security.cert , java.security.interface , java.security.spec, java.util , java. sql, javax.swing, javax.swing.border, javax.servlet, and javax. servlet.http. Various supporting components for the protocol has been developed using the following other common off- the-shelf (COTS) software products – JBuilder 5, iPlanet Certificate Management System 4.2, iPlanet Web Server and the MySQL database management system. The iPlanet Web Server [8] is an extremely powerful multi-process, multi-threaded, secure web server built on open standards that enables business enterprise to seam- lessly integrate with other internal and external systems. By providing high performance, reliability, scalability, and manageability, iPlanet Web Server solves the busi-

Java is a registered trademark of Sun Microsystems, Inc. in the US and other countries. Windows and Windows 2000 are registered trademarks of Microsoft Corporation and Solaris is a registered trademark of Sun Microsystems, Inc.

ness-critical needs of web site, regardless of the size of the enterprise. We use the iPlanet Web Server to host the merchant’s interface to the outside world to conduct the e-commerce transaction. The iPlanet Certificate Management System [7] is a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate Management System leverages Netscape Directory Server and Netscape Console to provide a complete, scalable, high-performance certificate management solution for extranets and intranets [7] . We use iPlanet Certificate Man- agement System 4.2 to post and issue public-key certifi- cates. Such certificates and the associated public–private key pairs provide bulk of the security services needed for the protocol. The MySQL database server embodies an ingenious software architecture that maximizes speed and customiz- ability. Extensive reuse of pieces of code within the soft- ware and an ambition to produce minimalist but functionally rich features have resulted in a database man- agement system unmatched in speed, compactness, stability and ease of deployment. The unique separation of the core server from the table handler makes it possible to run MySQL under strict transaction control or with ultrafast transactionless disk access, whichever is most appropriate for the situation. The MySQL database server is used as the backend to host the merchant’s products and other back-office services like inventory control, etc. The rest of the paper is organized as follows. In the next section, we describe the basic protocol used to support the e-commerce facility. We describe the theory of cross valida- tion on which our protocol is based. Section 3 provides the architecture of the e-commerce facility identifying the major modules and their interaction. Section 4 provides the design details including the use cases, use case realiza- tion, class diagram, and description of the major modules of the system. Section 5 concludes the paper.

2. Overview of the fair-exchange protocol

The fair-exchange protocol underlying our e-commerce facility uses the theory of cross validation that we have developed earlier [5,6] . This theory enables a customer to validate a product that he/she is purchasing, before its receipt from the merchant. In other words, this theory enables the customer to make sure that the product he/ she is about to receive from the merchant is indeed the product that he/she is paying for, before actually paying for the product. This is a unique property of our protocol; it ensures that the customer never suffers because of foul play by the merchant. As a side effect, this property also ensures that the merchant never suffers as a result of foul play by the customer. Thus, fair-exchange is ensured in our protocol. Below we briefly discuss the theory. For more details as well as proof of correctness the interested reader is referred to [6] .

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

249

2.1. Cryptographic background

The theory of cross validation is based on an asymmet- ric encryption technology, which is an extension of the clas- sic RSA encryption technology. Messages and keys are represented as positive integers. Encryption and decryption functions are nothing but modular exponentiation opera- tions. A encryption key K is defined to be the ordered pair Æ e , N æ , where N is a product of distinct primes and e is rel- atively prime to /( N). 1 The decryption key K 1 corre- sponding to the encryption key K is the ordered pair Æ d , N æ satisfying the equation e Æ d mod / (N ) = 1. The encryption of a message m < N with the key K is denoted

as [m , K]=[m , Æe , N æ ] = m e mod N .

by [m , K] and is defined

Similarly the decryption of message m 0 with the decryption key K 1 is defined as [ m 0 , K 1 ]=( m 0 ) d mod N. If m 0 = [ m , K], then m = [ m 0 , K 1 ]. We define two keys K 1 = Æ e , N 1 æ and K 2 = Æ e , N 2 æ to be compatible if N 1 and N 2 are relatively prime. The product of two compatible keys K 1 and K 2 , given by K 1 · K 2 is defined as Æ e , N 1 · N 2 æ . If m and m are two messages such that m; m < N 1 ; N 2 , then we can show (please see [5] for a proof) that the following properties hold.

½ m ; K 1 K 2 mod N 1 ¼ ½ m ; K 1 mod N 1 if

and only if m ¼ m

½ m ; K 1 K 2 mod N 2 ¼ ½ m ; K 2 mod N 2 if

and only if m ¼ m

Basically, the two properties imply that if a message is en- crypted with the product key of two compatible keys and another message is encrypted with either of the two com- patible keys and the two encrypted messages compare, then the two original un-encrypted messages must also compare. The significance of the above two properties is that we can compare two encrypted messages and tell whether they are the two plaintext messages are the same or not. This property gives rise to the validated receipt property, which we discuss now.

2.2. Validated receipt property

The validated receipt property is stated as follows:

Validated Receipt: An e-commerce protocol satisfies the validated receipt property provided the customer is able to ensure that the digital product he/she is about to receive from the merchant is the same as the product he/she ordered, before the customer pays for the product. Our e-commerce protocol satisfies this validated receipt property. Let m be a digital product that a merchant wants to sell a customer. The merchant begins by registering the product with a trusted third party. During this time, the merchant uploads the product to the third party. The third party stores the product encrypted with a key K M 1 (called

1 /( Æ ) is the Euler totient function which returns the number of integers that are less then and relatively prime to the functions integer parameter.

the merchant master key) in a publicly accessible place

together with a description of m and the public modulus

N 1 . When the customer decides to purchase m , it first

downloads T ¼ ½ m ; K M 1 from the trusted third party’s site

and keeps it for future validation of the product received from the merchant. To sell m to the customer, the merchant selects a second

set of keys ð K M 2 ; K 2 Þ such that K M 2 is compatible with K M 1 . The merchant provides the customer with T 0 ¼ ½ m; K M 1 K M 2 . The customer validates that ½m ; K M 1 and ½ m; K M 1 K M 2 are encryptions of the same product, m, by verifying that Tmod N 1 = T 0 mod N 1 . If Tmod N 1 = T 0 mod N 1 evaluates to true then the vali- dated receipt property is satisfied. The customer then pro- ceeds to send the payment for the product. The merchant

in

return sends the product decryption key K 2 . Finally,

the customer obtains the actual product m by decrypting

1

M

1

M

T 0 with the key K

1

M 2 .

2.3. Security

In the theory presented in Sections 2.1 and 2.2 if the base

e is small and the customer can guess e , 2 we can have a security problem. In this the customer can actually obtain the product m without getting the decryption key from the merchant (that is, essentially without paying for the product). To show how, consider a small exponent e = 3.

A customer starts as if he is buying the same product m

three times from the merchant but always stops short of paying for the product. For the first buying request, the merchant sends the customer the encrypted product as ½m ; K M 1 K M 2 . The customer does not make the payment; instead, he makes the second buying request. The merchant sends the encrypted product a second time as

½m ; K M 1 K M 3 and a third time as ½ m; K M 1 K M 4 . The keys K M 1 ¼ h e ; N 1 i ; K M 2 ¼ h e ; N 2 i , K M 3 ¼ h e ; N 3 i and K M 4 ¼ h e ; N 4 i are compatible. Let N = N 1 · N 2 · N 3 · N 4 . Knowing m e mod N i , for

, 4 an attacker can use the Chinese Remainder

theorem to compute m . Note that this attack is similar to the low exponent attack on the RSA cryptosystem

[2] . However, since the customer does not know e , but has to guess it in order to launch the attack, the attack

is considerably more difficult. To preclude this scenario

and provide an additional degree of security we use a ran- dom number in the encryption process as follows. For every transaction T i that the merchant performs for the product m , the merchant chooses a random num- ber r , which is relatively prime to the current encryption key modulus N i +1 . The customer downloads ½ m; K M 1 from the third party as usual. When sending the encrypted product to the customer, the merchant sends the following

i = 1,

2 Note that although we use an asymmetric key cryptosystem (in the sense that the encryption key and the decryption key are the inverse of each other and different from each other), unlike traditional public key cryptosystems like RSA, we do not disclose the exponent e .

250

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

½ m r ; K M 1 K M 2 ; ½ r ; K M 1 instead of ½ m ; K M 1 K M 2 as was previously the case. Here m Æ r is the product of m with r . To validate the product, the customer multiplies ½ m; K M 1 with ½ r ; K M 1 and the resulting value is compared with ½ m r ; K M 1 K M 2 . If they compare, the customer is confi- dent that the validated receipt property is satisfied. The customer can now go ahead and pay for the product. For the decryption key, the merchant now sends K and r 1 instead of just K 2 , where r 1 is the multiplicative inverse of r modulo N 2 . Using the decryption key K 2 the customer obtains m Æ rmodN 2 . Multiplying this value by r 1 the customer retrieves m .

1

M

1

M

1

M

2

2.4. Protocol description

We make the following assumptions in the protocol:

(1) We assume that all encryptions, including the one employed in the theory of cross validation, are strong enough that the receiver of an encrypted message is unable to decrypt the message without the appropri- ate decryption key. Similarly, cryptographic check- sums and digital signatures are strong enough to provide non-repudiable evidence about the identity of the signatory and ensure integrity of messages. (2) All parties use the same algorithm for encryption, message digests, digital signatures and cryptographic checksums. (3) Payment for a product is in the form of a token, P, which is accepted by the merchant.

(4) Each party involved in the transaction keeps a copy of all messages that it sends to another party in its stable storage. The information is maintained in the stable storage till such time as the information is no longer needed. Writes to the stable storage are atomic and durable until intentionally purged. (5) All parties know a system wide constant time out

period.

We describe the e-commerce protocol by breaking it down into two parts – the basic protocol and the extended protocol. The protocol consists of a sequence of messages exchanged between the various parties – the customer, the merchant, the trusted third party and the financial insti- tution. The following table lists the symbols used to describe the messages exchanged (see Table 1 ). The protocol proceeds via the exchange of a series of messages between the customer, the merchant and (when required) the trusted third party. In the following, we show the messages that are exchanged between the vari- ous parties. The direction of the arrow shows the direc- tion of the message sent while the label of the arrow shows the contents of the message. Note that each mes- sage is accompanied by a signed cryptographic checksum of the contents so that integrity of message and non-repu- diation of origin is ensured. Also each message is encrypted by the recipient’s public key while in transit, so as to ensure confidentiality. We do not show these checksums and encryptions so as to keep the exposition simple and readable.

Table 1 List of symbols used in protocol description

Symbol

Interpretation

C, M, B and TP IDs for the customer, merchant, bank and trusted third party

A prv , A pub The private and public key pair of an entity A [ X , K ] The encryption of object X with the key K CC(X ) A cryptographic checksum of object X , using an algorithm such as Secure Hash [4]. We assume that all messages are accompanied by signed cryptographic checksums to ensure integrity and non-repudiation of origin of message.

w A K C 1 ; K

A nonce for the entity A. Each entity’s nonces are unique and different from other entities’ nonces

A key pair generated by the bank for the customer; key K C 1 is given to the customer and K

1

C 1

¼ hd; N 1 i and e d 1 1modN 1

1

M

C

1

1

2

C

1

1

is kept by the bank indexed by the

1

C

1

M

customer’s id. K C 1 ¼ he ; N 1 i; K

¼ hd 2 ; N 2 iis the decryption key

corresponding to K C 2 ; e d 2 1modN 2

A key pair generated by the merchant and given to the trusted third party; K 1 ¼ hd 0 ; N 1 i decrypts anything that is encrypted with K M 1 ¼ he ; N 1 i; e Æ d 0 1modN 1

Key pair generated by merchant for current transaction; the key K M 2 ¼ he ; N 2 i is compatible with the key K M 1 . Key K 2 ¼ hd 2 ; N 2 i decrypts anything encrypted by K M 2 since e Æ d 2 1modN 2

A random number chosen by the merchant for the current transaction Multiplicative inverse of rmod N 2 The digital product the customer purchases The product id for the product m The purchase order used by the customer to order the product m. The purchase order contains the following information – PID, C, M, Agreed_Price, w C Customer’s account information with the bank

Key pair generated by customer; the key K C 2 ¼ he; N 2 i is compatible with the key K C 1 and the key K

K C 2 ; K

C

1

2

1

M 1

K M 1 ; K

1

M 2

K M 2 ; K

R

r 1

M

PID

PO

C act

u

A cert

Payment token used by the customer to pay for m. The payment token contains information to debit ‘‘Agreed_Price’’ amount of money from the customer’s account in the bank and credit it to the recipient. The Agreed_Price is signed by the merchant. Entity A’s public key certificate

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

251

Initial setup – merchant’s product registration with trusted third party

Initial Setup – Customer and Merchant negotiates price for selected price

Merchant Trusted If this is the third first time the party merchant is registering, then
Merchant
Trusted
If this is the
third
first time the
party
merchant is
registering,
then only the
1
key K M 1 ; K
M 1
are sent,
otherwise not
Merchant
Trusted
result of
third
registration
party
process

Initial setup – customer determines product from cata- log service at the trusted third party

Customer

Customer

Customer Customer Merchant Customer initiates price negotiation for product by sending a basis for the requested
Customer Customer Merchant Customer initiates price negotiation for product by sending a basis for the requested

Merchant Customer initiates price negotiation for product by sending a basis for the requested price Merchant Merchant responds by agreeing to Agreed_Price

Initial setup – customer prepares payment token from bank

Customer

Customer

Customer Customer Trusted Customer browses third catalog, finds party product to Trusted purchase
Customer Customer Trusted Customer browses third catalog, finds party product to Trusted purchase

Trusted

Customer browses

third

catalog, finds

party

product to

Trusted

purchase and requests download of encrypted

third

product from

party

catalog and merchant id

Customer

Customer Bank Customer prepares and sends payment token for bank to sign

Bank Customer prepares and sends payment token for bank to sign

Customer

Bank

Bank verifies that

 
  customer has sufficient funds and if so, signs the payment token.

customer has sufficient funds and if so, signs the payment token.

Basic protocol: Customer
Basic protocol:
Customer

Customer

Customer

Customer

Customer Customer Customer Merchant Customer creates and sends purchase order to merchant with encrypted payment token

Merchant Customer creates and sends purchase order to merchant with encrypted payment token (signed by bank); associates a unique transaction identifier T i , stores a log record ÆT i ,INITIATE æ and waits for encrypted product Merchant Merchant writes a log record Æ T i ,INITIATE æ and checks PO and signature of bank on payment token. If all okay Merchant sends encrypted product and waits for validation by customer and payment; else writes a Æ T i ,ABORT ærecord sends a failure message and terminates. Merchant If successful validation of product is made, customer sends decryption key for payment token and signed checksum of encrypted product received; writes Æ T i ,PAYMENT-SENT æ record else an ‘‘unsuccessful validation’’ message is sent. If merchant has aborted in previous step, customer writes ÆT i ,ABORT æ record.

Merchant If merchant succeeds in retrieving payment token, it sends the decryption key for the encrypted product and writes Æ T i ,FINISH æ else merchant sends failure

252

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

Certain changes need to be made to the basic protocol to

ensure fair-exchange when one of the parties misbehaves. Note that the merchant always sends the product decryption key

K

2 only after it has successfully received the payment – that

is, only after it has been able to successfully decrypt the pay-

sent by the customer.

ment token with the decryption key K

Consequently, the merchant can never claim foul play on the part of the customer after it has sent out the product decryp-

1

M

1

C 2

tion key K 2 (it had an opportunity to back out from the transaction). Thus the extended protocol is always executed by the customer with a claim of foul play by merchant. Note,

however, that the following scenario is also possible. The cus-

in good

faith to the merchant. However, due to network failure the merchant never receives it and consequently does not send the product decryption key K 2 . Or the merchant sends the product decryption key K 2 but the customer does not receive it due to network problems. For both these cases, the customer determines that there is foul play by the merchant and initiates the extended protocol. To resolve these problems, the cus- tomer needs to send the payment token decryption key K to the third party together with evidence of transaction. This is a major change from the original version of the protocol [5].

1

M

tomer sends the payment token decryption key K

1

M

1

M

C 2

1

1

C

2

Theorem 4. The e-commerce protocol ensures fair-exchange.

Proof. To show fair exchange we first note that the pay- ment token used in the transaction specifies the amount that is debited from the customer’s account and credited to the merchant’s account. This specified by the value

Agreed_Price which is signed by the merchant. So the cus- tomer cannot tamper with Agreed_Price. The bank signs the payment token only if it can debit the amount in Agreed_Price. Thus if the merchant receives the payment token properly (which is ensured by the use of message digests and digital signatures) it is guaranteed to receive correct payment for the product it is selling to the

customer. h

The customer gets two versions of the encrypted product –

one from the trusted third party and one from the merchant. Although the customer cannot retrieve the product from the encrypted version it receives from the third party, it has the assurance that if everything fails it can still get the product from that version. Thus the customer does not hand over

the payment token till such point as it has at least one copy of the correct encrypted product. Fair exchange does not occur only if the merchant does not send the last message

Extended Protocol: Customer
Extended Protocol:
Customer

Trusted

third

party

Trusted

third

party

Trusted

third

party

Trusted

third

party

Trusted

third

party

Customer

Trusted

third party

Merchantthird party Trusted third party Customer Trusted third party Merchant Customer’s bank Customer’s bank Customer

Merchant Trusted third party Customer Trusted third party Merchant Customer’s bank Customer’s bank Customer requests

Customer’s

bankCustomer Trusted third party Merchant Merchant Customer’s Customer’s bank Customer requests extended protocol by

Customer’sTrusted third party Merchant Merchant Customer’s bank bank Customer requests extended protocol by sending evidence

bank

Customer requests extended protocol by sending evidence of merchant foul play and also payment token decryption key

Trusted third party contacts merchant to obtain product decryption key. Starts a timer

If the merchant is not misbehaving it will either send the product decryption key or present its reason for not sending product. The latter occurs only if the payment token decryption key still does not decrypt the payment token This step is optional. The trusted third party contacts the customer’s

bank only if the product decryption key fails to decrypt payment token correctly

This step is optional only if last step occurs. Customer’s bank decrypts payment token and sends to trusted third party the correct token

Merchant This step is optional only if last step has occurred. Trusted third party sends revised payment tokentoken and sends to trusted third party the correct token Trusted If the merchant responds to

occurred. Trusted third party sends revised payment token Trusted If the merchant responds to the third

Trusted

If the merchant responds to the third party’s request within the

third party

timeout period by sending the product decryption key, the third party forwards it to the customer; else the third party decrypts the product from its catalog and sends it to the customer.

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

253

in the basic protocol. But then the extended protocol is started which ensures that the customer finally gets the prod- uct. Thus follows the proof.

3. Implementation of the E-commerce facility

We now describe our efforts to build a complete e-com- merce facility based on the above protocol. We begin by discussing the architecture.

3.1. Architecture of the E-commerce facility

The protocol is implemented around three main mod- ules – the (trusted) Third Party, the Merchant and the Cus- tomer. The Third Party module includes three major servers – (i) a certificate server that provides certified public keys for both customers and merchants, (ii) a registration authority that registers the customer and merchant prior to any transaction and (iii) the catalog server where the merchant uploads the encrypted products to sell and their descriptions. Although we have co-located these services into one unit, they can be very easily distributed. The cus- tomer module provides three services – (i) the customer application that participates in the transaction with the merchant and, if required, participates in dispute resolution with the third party, (ii) the customer web browser that determines the product to purchase and downloads the

that determines the product to purchase and downloads the Fig. 1. System architecture for the E-commerce

Fig. 1. System architecture for the E-commerce facility.

encrypted version from the catalog server at the third party and (iii) the key management unit that manages all keys used by the customer. Finally, the merchant module has three major functional units – (i) the merchant application that participates in the main fair-exchange protocol, (ii) the registration unit that corresponds with the third party for registration purposes and (iii) the key management unit that handles all issues related to encryption decryption key management. Fig. 1 shows the architecture of the E- commerce facility. We would like to point out here that there are two other players in the protocol that we have not included in the proposed architecture. These are the customer’s and the merchant’s financial institution. These can be the same entity or different entities. In our implementation we pro- vide the necessary interface for standardized AFSA proto- cols 3 that are used in communication with financial institutions.

4. Design details

Logically the e-commerce facility is broken down into three tiers: presentation tier , business logic tier and data tier . The presentation tier implements the interface of the e-commerce facility with the external world. The business logic tier implements the interaction of the different players in the protocol to provide the e-commerce service. Finally, the data tier provides the back-end data management func- tionality to the entire system. This is represented in Fig. 2 . The following major pieces of software were used to develop the e-commerce system – Sun Microsystems’s JAVA technology including Jbuilder 5 and the Java Devel- opment Kit, iPlanet Web Server and the iPlanet Certificate Management Solution and the MySQL database manage- ment system. The iPlanet Web Server is an extremely pow- erful multi-process, multi-threaded, secure web server built on open standards. It was chosen primarily because it of its scalability and manageability features and because it allows seamless integration with other external systems, in partic- ular, with the readily available iPlanet Certificate Manage- ment System. The latter is a highly configurable set of software components and tools for creating, deploying and managing public key certificates. Based on open stan- dards for certificate management, this set of tools leverages the Netscape Directory Server and Netscape Console to provide a complete, and scalable certificate management solution. We use JDK’s built in application Keytool, to generate public–private key pairs, generate certificate request and import certificates into Keystore. The certifi- cates are then managed by the iPlanet Certificate Manage- ment System. Finally, we use the MySQL database management system as the backend database server. The primary reason for using MySQL was speed, compactness and ease of deployment.

3 American Financial Services Association protocols.

254

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

Commerce Research and Applications 7 (2008) 247–259 Fig. 2. Logical architecture of E-commerce system. 4.1.

Fig. 2. Logical architecture of E-commerce system.

4.1. Implementation issues

Use of JDK, iPlanet Web Server and MySQL greatly facilitated the development of our e-commerce facility. The major difficulty we faced was in implementing the cryptographic subsystems for the theory of cross validation as there was no readily available software module for this. In the following sections, we discuss some of the implemen- tation issues. For this discussion we emphasize more on our experiences in implementing the cryptographic subsys- tem than any other component.

4.1.1. Software modules Three major software modules implement the e-com- merce facility. They are the Third Party server, the Mer- chant server and the Customer application. The merchant server has an additional module, the Registration Applica- tion module that provides an important functionality to the protocol. A fifth software module is necessary to complete the protocol. It’s the Bank Server, which provides financial services to the customer and the merchant. Since such a ser- vice is really a universal one and not limited just to our e-commerce facility, we assume that one is available. There are well-defined protocols for communication with finan- cial institutions. In our implementation, we developed a very rudimentary version of a Bank Server so that the nec- essary communication exchanges can take place. The Bank Server communicates with other modules via well-known AFSA protocols. At this time the only service the Bank Server provides is a signature on the Customer’s payment token. Below we give brief overview of each module and show the various interfaces that we have developed for the interaction of each module with the external world.

4.1.1.1. Third Party Server Module. This module imple- ments the trusted Third Party in the protocol. It is imple- mented as a multi-threaded server. This is so that the third party can handle multiple requests simultaneously. It creates server sockets for listening to requests. These requests include (a) Merchant registration requests, (b) Product download requests and (c) Run extended protocol requests. For the registration request, the third party first verifies the certificate of the merchant. If verified, the third party checks the signature of the merchant and the integrity of the message received. If everything verifies correctly, the third party stores the encrypted product and the merchant master key to its local database and adds a unique product ID to the catalog. The third party also records the mer- chant’s ID, IP address and port number to a database. This information is needed by the customer to purchase the product from the merchant. Once done, the third party responds to the merchant by sending RegisterResp mes- sage. This message is either a ‘‘registration success’’ mes- sage or a ‘‘registration failure’’ message. For the product download request which comes from the customer, the third party server firsts checks if the product that the customer requests, is in the catalog. If so, the server reads the encrypted product from its database and sends it to the customer together with an appropriate ‘‘download response’’ message. The download response contains the merchant’s IP address and port number which is to be used by the customer to purchase the product. Finally, for the extended protocol request, the third party tries to contact the merchant to resolve the matter. If it cannot contact the merchant, the third party uses the merchant’s master key to decrypt the product from its cat- alog and send it to the customer.

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

255

Registration application module. This module is the

application that the Merchant Server uses to register a product with the trusted Third Party. It sends registration request to Third Party. There is a graphical interface for this module; the merchant can set all the information it needs to create registration request via this interface. In

4.1.1.2.

take a message, m, of arbitrary length and compute a fixed length ‘‘fingerprint’’ of the data H( m ) – called the message digest. For the signature, we sign the message digest by com- puting d (H ( m )), where d ( Æ ) is the RSA signature algorithm. Digital signature generation follows these steps:

the registration request, the merchant includes product

(i)

A message digest is computed.

ID, encrypted product (encrypted by merchant master key), secure hash value for this encrypted product, master decryption key for the merchant that is encrypted by Third

(ii)

The message digest is encrypted using the private key of the public–private key pair, producing the mes- sage’s digital signature.

Party’s public key, secure hash value for this decryption key, Merchant ID, Merchant IP address, Merchant Port number and Merchant’s certificate. If the merchant is a

Signature verification follows these steps:

new merchant to the Third Party, then the merchant does not have to provide a Merchant ID; the third party auto- matically provides one. After sending the request to Third

(i)

The signature is decrypted using the public key of a public–private key pair, producing a message digest value.

Party, the Merchant will receive the registration response.

(ii)

The message digest value is compared with the mes-

The response displays whether this registration transaction is success or failure. If it is failure, the response will also contain an appropriate reason.

sage digest calculated from the original message. (iii) If both digest values match, the signature is authentic. Otherwise, either the signature or the message has been tampered with.

4.1.1.3.

Merchant Server Module. This module implements

the merchant server. It is implemented as a multi-threaded server process. The server creates sockets to listen on an advertised port to customer requests. For each customer’s request, the server creates a new thread to service the request. The server creates an additional thread to service requests from third party for the extension protocol.

4.1.1.4. Customer application module. This module imple-

ments the customer process. To purchase a product the module sends a download request to the third party mod- ule. This message contains the product id for the product. In return the customer receives a download response. This message contains (if applicable) the encrypted product for later validation and other relevant information for the cus- tomer to contact the merchant. Next the customer prepares the purchase order and a payment token. The payment token is encrypted and sent to the Bank server. The Bank server signs the token and sends it back to the customer. The customer next sends purchase order and payment token to merchant. After customer receives the encrypted product from the merchant, it validates the product using the theory of cross validation. The customer next sends the decryption key for the payment token; in return the customer receives the decryption key for the product. If the product decrypts correctly, the customer module exists. Otherwise, it initiates the extended protocol.

4.1.2. Signature verification and data integrity modules Digital signature, message digests and secure message authentication codes are used throughout the implementa- tion for non-repudiation purposes and to verify the integrity of transmitted data: signatures on message digests allow non-repudiation of origin of data while cryptographically strong message authentication codes allows to verify the integrity of transmitted data. Message-digest algorithms

We use the Signature class in java.security to perform sign and verify. The Signature class supports both signature generation and verification. The Signature class is a factory class, and Signature objects are created with the static get- Instance() method Fig. 3 . Fig. 4 shows how to sign and verify a message. Here privateKey is the key used to sign. It is an instance of java.security.PrivateKey . msg is the mes- sage that we want to sign and publicKey is the key to verify the signature on the message. The publicKey is an instance of java.security.PublicKey . In the implementation we use SHA message digest algorithm with the RSA signature algo- rithm to sign and verify.

4.1.3. Key generation algorithm This implementation uses KeyPairGenerator class to generate public–private key pair. The KeyPairGenerator class is an abstract class. Instances of KeyPairGenerator are created using the static getInstance() method. This method takes a String object that identifies the algorithm name as a parameter. In this implementation, we use RSA algorithm to generate key pair. Random numbers are important in cryptography. They are typically used to

//for sign Signature sign = Signature.getInstance(“SHA1withRSA”); Sign.initSign(privateKey); sign.update(msg.getBytes()); byte[] b = sign.sign();

//for verify sign.initVerify(publicKey); sign.update(msg.getBytes()); boolean verify = sign.verify(b); //if verify = true, the message is verified

Fig. 3. Code snippet for signing and verifying messages.

256

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

KeyFactory kf = KeyFactory.getInstance(“RSA”); RSAPrivateCrtKeySpec priSpec = (RSAPrivateCrtKeySpec)kf.getKeySpec(privateKey, RSAPrivateCrtKeySpec.class); RSAPublicKeySpec pubSpec = (RSAPublicKeySpec)kf.getKeySpec(publicKey, RSAPublicKeySpec.class); MyRSAPrivateKey priKey = new MyRSAPrivateKey( priSpec.getModulus(), priSpec.getPublicExponent(), priSpecgetPrivateExponent(), priSpec.getPrimeP(), priSpec.getPrimeQ(), priSpec.getPrimeExponentP (), priSpec.getPrimeExponentQ (), priSpec.getCrtCoefficient ()

); MyRSAPublicKey pubKey = new MyRSAPublicKey( pubSpec.getModulus(), pubSpec.getPublicExponent()

);

Fig. 4. Code snippet for retrieving information from key pairs.

make the results of operations, such as key generation, dif- ficult to predict. The SecureRandom class of java.security can be used to access the secure pseudo-random number generator algorithm. In this implementation, we use SecureRandom class to generate secure random number, specifying the SHA1PRNG algorithm for random number. After creating a KeyPairGenerator object using getIn- stance() , we need to initialize it using the initialize() method, specify the length of the key as 1024 bits, and also supply the secure random number we generated before. Then we create KeyPair object using the genKeyPair() method. After we get KeyPair object, we can retrieve Pub- licKey object and PrivateKey object using getPublic() and getPrivate() methods in KeyPair class. In our implementation, generating compatible keys and product keys are a little different from generating RSA key pairs. Product keys are the keys for encrypting digital goods and payment tokens. For each such message, we need keys K 1 = Æ e , N 1 æ , K 2 = Æe , N 2 æ and K ¼ h e ; N 1 N 2 i. After getting public key/private key pair using the way described earlier, we need to generate the related key K 2 and K. For generating these keys, we need to know some information of the key pair we generated, such as modulus, public exponent, and private exponent. MyRSAPublicKey and MyRSAPrivateKey in our implementation are used for these purposes. MyRSAPublicKey and MyRSAPrivate- Key implement RSAPublicKey and RSAPrivateKey and includes toXml() and fromXml() methods for data transfer. To retrieve the information from the key pair, we create an instance of KeyFactory using static method getIn- stance() in KeyFactory class and specify the algorithm as RSA. Then we call getKeySpec() method in KeyFactory class, pass along the private key and public key we got above. Fig. 5 shows a sample code to retrieve information from key pair.

Signature sig = Signature.getInstance(“SHA1withRSA”); sig.initSign(privateKey); String issureName = “CN=Root Authority, O=CSU, C=US”); String subjectName = “CN=Authority, O=CSU, C=US”); X509CertGen cg = new X509CertGen(issureName, sig); cg.setIssureEmail(email@root.authority.us); cg.setSubjectDN(subjectName); cg.setSubjectEmail(email@authority.us); cg.setPublicKey(publicKey);

cg.setSerialNumber(BigInteger.valueOf((long)1));

cg.setValidity(365);

cg.setBasicConstraints(true, 10); cg.setKeyUsage(new boolean[] {true, true, true, true, true, true, false, false}); cg.setNetscapeCertType( new boolean[] {false, false, true, false, true, true, true}); java.security.cert.X509Certificate cert = cg.generateCertificate();

Fig. 5. Code snippet for certificate generation.

After creating MyRSAPublicKey/MyRSAPrivateKey pair as key K 1 and inverse of K 1 , respectively, we need to compute K 2 and K. Note that K 1 and K 2 are compatible. Using Definitions 11 and 12, we know that to create K 2 we need to compute N 2 such that N 1 and N 2 are relatively prime. N is defined as N 1 * N 2 . To create N 2 , first we gener- ate primes P 2 and Q 2 . Then compute N 2 = P 2 * Q 2 . We still need to check whether N 2 and N 1 are relatively prime. After getting N 2 , we can compute N as N 1 * N 2 . Finally, we get K 1 = Æe , N 1 æ ,K 2 = Æ e , N 2 æ and KÆ e , N æ.

4.1.4. Encryption and decryption algorithm Recall that the current e-commerce protocol is intended for transacting products that can be exchanged in the form of electronic messages. Thus we use binary files to repre- sent products. Each product is encoded in MIME specifi- cation. Before transmission the relevant keys encrypt the file. To do this the encryption program first reads the bin- ary file as a byte array. It then divides the byte array into 64 bytes long blocks and converts these blocks to BigInte- ger (BigInteger class in the Java API). Encryption is per- formed on the BigIntegers . At the decryption side we use the toByteArray() method in BigInteger class to get back byte arrays, and combine these byte arrays to get the ori- ginal product. In the implementation, class BigIntArrayObj represents product that has been divided to small blocks. In this class, there are some fields: BigInteger array, integer array, and integer for last length. BigInteger array contains the big inte- ger values obtained from each block of the binary file, integer array contains the flags for sign (positive/negative) of these big integers, and the last length records the length of the last big integer. In the BigInteger class, the toByteArray() method returns a byte array containing the two’s-complement rep- resentation of this BigInteger . The byte array is in big-end- ian byte-order: the most significant byte is in the zero-th element. The array contains the minimum number of bytes required to represent this BigInteger , including at least one

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

257

sign bit. There are some points we need to take care of in the program. First, when converting each 64 bytes block to BigInteger , the BigInteger created may be negative. In the theory for encrypt/decrypt, the set of message M is the set of non-negative integers that are less than an upper bound N. So, we need to convert the negative big integer to positive when computing. Second, when we get the decrypted big integer, we need convert it back to negative. The integer array field in class BigIntArrayObj is for this purpose. Last, because the toByteArray() method in BigIn- teger class returns the minimum number of bytes required to represent this BigInteger , it is possible to loose some bytes. When we convert these BigIntegers back to byte array, we have to add these bytes back. Because it is 64 bytes long for each BigInteger in our implementation except last one, we can check if the final byte array is 64 bytes long. If it is shorter that 64 bytes, then for positive BigInteger , we need to add 0’s in the front of the byte array, for negative BigInteger , we need to add 1’s in the front of the byte array. For the last BigInteger , we use the integer field lastLen in BigIntArray class for recording the original length of byte array.

4.1.5. Certificate generation and key management For lack of a proper certifying authority in our test-bed, we use self-signed certificates in our implementation. This is achieved by using the com.dstc.security.pki.X509CertGen in JCSI 2.2.1. With this class one can generate a X.509 for- mat certificate and specify the appropriate fields in the cer- tificate. Below is the code for generating the self-signed certificate. To be useable in practice, the only change that is needed is the specification of an appropriate certifying authority in the certificate. We create a key store to store the key pair and certifi- cate. In JDK 1.3, a keystore is a container for secret keys, public–private key pairs, and certificates that attest to the validity of a public key. A keystore may contain two types of entries.

(1) Key entry: Holds either a secret key or a public–pri- vate key pair (and a chain of certificates that authen- ticates the public key). A key entry can be used to sign objects and to provide a certificate that authenti- cates the signature. (2) Trusted Certificate Entry: Holds a public key certifi- cate of another party.

Each of the entries in a keystore is associated with a unique alias. This alias is a string that identifies the use of a key entry or the name of the entity with which a trusted certificate is associated. The keystore is protected by password. The java.security.KeyStore class encapsulates the notion of a keystore . The KeyStore class provides a number of methods that are used to manage a keystore and its entries. The getInstance() method is a factory method that is used to create keystore objects by name, and optionally, by provider. After we create a key pair

and a self-signed certificate for the public key, we store them in the keystore Fig. 6 . Before registration for product, the Merchant needs Third Party’s certificate. We use Keytool to import the Third Party’s certificate to the keystore . The Merchant then can read the Third Party’s certificate from the keystore as and when required. Keytool was introduced with the Java 2 SDK. It is used to manage keys and certificates. It also provides an implementation of the java.security.KeyStore class. It supports the following capabilities:

(1) Key pair generation: generates a public and private key pair and creates an X.509 self-signed certificate for the public key. (2) Management of key entries: allows key entries to be created, imported, exported, listed, and deleted. (3) Management of trusted certificate entries: allows the certificates and certificate chains of others to be imported, exported, listed and deleted. (4) Certificate signing request (CSR) generation: CSRs can be generated for submission to a certification authority. (5) Password management: passwords can be used to protect private keys or the entire keystore.

//store key and certificate to keystore KeyStore keystore = KeyStore.getInstance(“JKS”, “SUN”); keystore.load(null, “password”); keystore.setKeyEntry(“alias”, privateKey, “password”, new java.security.cert.X509Certificate[] {mycertificate}); keystore.store(new FileOutputStream(“filename”, “password”);

//get key and certificate from keystore KeyStore keystore = KeyStore.getInstance(“JKS”, “SUN”); Keystore.load(new FileInputStream(“filename”, “password”); RSAPrivateKey priKey = (RSAPrivateKey)keystore.getKey(“alias”, “password”); X509Certificate cert =

(X509Certificate)keystore.getCertificate(“alias”);

RSAPublicKey pubKey = (RSAPublicKey)cert.getPublicKey();

Fig. 6. Code snippet for using KeyStore class.

Fig. 6. Code snippet for using KeyStore class. Fig. 7. Structure of a typical certificate.

Fig. 7. Structure of a typical certificate.

258

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

Commerce Research and Applications 7 (2008) 247–259 Fig. 8. XML representation of purchase order and payment

Fig. 8. XML representation of purchase order and payment token.

We use the command keytool–import–file certificate.txt

–alias cert to import a trusted certificate. The steps to get

a certificate are:

(1) Generate key pair and store it in keystore. (2) Use keytool to generate Certificate Signing Request. Using the command: keytool –certreq –alias Signer –file csr.txt. (3) Send the request that stored in file csr.txt to a certif- icate server. (4) After getting the certificate response from certificate server, we import the certificate into the keystore using keytool .

A typical certificate that is used in the protocol is shown below (see Fig. 7 ).

4.1.6. Data transfer

All data transfers are implemented using XML. For each

instance of data that needs to be transferred across the net- work, there are two methods that are invoked by the rele- vant module – toXml() and fromXml(String s) . The first method – toXml() – generates the XML message represent- ing the object and the second method – fromXML(String s)

– parses the object’s data members from an XML message.

Fig. 8 shows the XML structure of the purchase order and payment token that is used in this protocol.

4.1.7. Connection with databases

Java Database Connectivity (JDBC) provides access to backend database resources. Java applications access JDBC using a JDBC driver, which is a database vendor- specific interface for a database server. Such a driver was available for the MySQL database server that we used as the backend server. We obtained the file ‘‘mm.mysql- 2.0.12-you-must-unjar-me.jar’’ from http://mmmysql. sourceforge.net . After the driver is loaded, we can connect to a database.

4.1.8. Helper class

The class Conversion provides methods for converting arrays of bytes to string objects that display the bytes in hexadecimal and base64 format. Base64 is the default stan- dard for encoding messages to be MIME compliant during

transmission. When using base64, three binary bytes are converted to four printable characters as follows:

(1) The bytes are laid out one after another to form a 24-bit sequence. (2) The 24-bit sequence is organized into four 6-bit units. (3) Each of these 6-bit units represents an integer value between 0 and 63. (4) For characters are selected using these four integer values.

5. Conclusions

In this paper, we described a new fair-exchange e-com- merce protocol that we have developed to facilitate e-com- merce transactions over the Internet. The protocol has a unique property – it allows a customer to ensure that the product he/she has ordered with a merchant and is about to receive is indeed the product that he/she wanted, before paying for the product. This prevents the merchant from substituting incorrect or defective products. The protocol also ensures fair-exchange – that is neither the customer nor the merchant suffers a loss due to unfair practices of the other player in the transaction. As noted earlier this protocol is build on top of a novel cryptographic technique that we have developed. One of the objectives in building this facility was to identify how easily we can build the software using common off-the-shelf software components. We found JDK to be particularly useful in our efforts. At this stage we have a working pro- totype of the e-commerce facility. However, a lot of improvements need to be done in terms of the interfaces. Ideally we would like to provide a web based interface to all the modules. Also we would like to use a widely accepted security protocol like https to provide bulk of the security functionalities like digital signatures, cryptographic check- sums, etc. These remain part of our future work.

Acknowledgements

This material is based upon work supported by the Na- tional Science Foundation under Award Number IIS 0242258. Any opinions, findings, and conclusions or rec- ommendations expressed in this publication are those of

I. Ray, H. Zhang / Electronic Commerce Research and Applications 7 (2008) 247–259

259

the author(s) and do not necessarily reflect the views of the National Science Foundation.

References

[1] B. Cox, J.D. Tygar, M. Sirbu, NetBill security and transaction protocol, in: Proceedings of the 1st USENIX Workshop on Electronic Commerce, 1995, pp. 77–88. [2] B. Kaliski, M. Robshaw, The secure use of RSA, CryptoBytes 1 (3) (1995) 7–13. [3] F. Bao, R.H. Deng, W. Mao, Efficient and practical fair exchange protocols with off-line ttp, in: Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1998, pp. 77–85. [4] Federal Information Processing Standard, FIPS 180, National Institute of Standards and Technology, 1993. [5] I. Ray, I. Ray, An optimistic fair-exchange protocol with automated dispute resolution, in: Proceedings of the 1st International Conference on Electronic Commerce and Web Technologies,Greenwich, UK, September 2000Lecture Notes in Computer Science, vol. 1875, Springer, 2000, pp. 84–93. [6] I. Ray, I. Ray, N. Narasimhamurthi, A fair-exchange protocol with automated dispute resolution, in: Proceedings of the 14th Annual IFIP WG 11.3 Working Conference on Database Security, Schoorl, The Netherlands. [7] iPlanet E-commerce Solutions. iPlanet Certificate Management Sys- tem Agent’s Guide.

[8] iPlanet E-commerce Solutions. iPlanet Web Server Programmer’s Guide to Servlets. [9] J. Zhou, D. Gollman, A fair non-repudiation protocol, in: Proceed- ings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1996, pp. 55–61. [10] N. Asokan, M. Schunter, M. Waidner, Optimistic protocols for fair exchange, in: Proceedings of the 4th ACM Conference on Computer and Communications Security, Zurich, Switzerland, 1997, pp. 7–17. [11] N. Asokan, V. Shoup, M. Waidner, Asynchronous protocols for optimistic fair exchange, in: Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1998, pp. 86–99. [12] N. Asokan, V. Shoup, M. Waidner, Optimistic fair exchange of digital signatures, in: Proceedings of the Workshop on Theory and Application of Cryptographic Techniques, EUROCRYPT ’98, Hel- sinki, Finland, 1998, pp. 591–606. [13] R.H. Deng, L. Gong, A.A. Lazar, W. Wang, Practical protocols for certified electronic mail, Journal of Network and System Manage- ment 4 (3) (1996). [14] S. Ketchpel, Transaction protection for information buyers and sellers, in: Proceedings of the Dartmouth Institute for Advanced Graduate Studies’95: Electronic Publishing and the Information Superhighway, 1995. [15] S. Ketchpel, H. Garcia-Molina, Making trust explicit in distrib- uted commerce transactions, in: Proceedings of the 16th Interna- tional Conference on Distributed Computing Systems, 1996, pp.

270–281.