Available online at www.sciencedirect.

com

Electronic Commerce Research and Applications 7 (2008) 247259 www.elsevier.com/locate/ecra

Experiences in developing a fair-exchange e-commerce protocol using common o-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 suer 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 proposed earlier. We show how to use common o-the-shelf software components to develop such a protocol. 2007 Elsevier B.V. All rights reserved.
Keywords: E-commerce; Fair-exchange; Certicate; 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 customer. This dilemma has prompted researchers to propose fair-exchange protocols that ensure no player in the transaction suers 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 transactions [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 protection [14,15] may be too little, too late in an e-commerce environment solely because the customer and the merchant may not have identiable 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) 247259

Several protocols have been proposed [1012] that do not use the third party unless a problem, such as, a party misbehaving or prematurely aborting, occurs. Such protocols are termed optimistic [3,1012]. Some of these protocols 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 associated with a monetary value). In this paper, we describe a novel fair-exchange protocol that we have developed. The protocol is based on the work by Ray et al. [5]. The protocol addresses the problem of fair-exchange of value products. It is an optimistic protocol in the sense of the term dened in [10]. The protocol ensures fairness under all possible circumstances. It does not require a manual after-the-fact dispute resolution 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 nding 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 implementation. Thus, we rst describe the modied protocol. We then describe our eorts 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 Microsystemss 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 othe-shelf (COTS) software products JBuilder 5, iPlanet Certicate 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 seamlessly integrate with other internal and external systems. By providing high performance, reliability, scalability, and manageability, iPlanet Web Server solves the busi-

ness-critical needs of web site, regardless of the size of the enterprise. We use the iPlanet Web Server to host the merchants interface to the outside world to conduct the e-commerce transaction. The iPlanet Certicate Management System [7] is a highly congurable set of software components and tools for creating, deploying, and managing certicates. Based on open standards for certicate management, Certicate Management System leverages Netscape Directory Server and Netscape Console to provide a complete, scalable, high-performance certicate management solution for extranets and intranets [7]. We use iPlanet Certicate Management System 4.2 to post and issue public-key certicates. Such certicates and the associated publicprivate 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 customizability. Extensive reuse of pieces of code within the software and an ambition to produce minimalist but functionally rich features have resulted in a database management 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 merchants products and other back-oce 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 validation 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 realization, 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 suers because of foul play by the merchant. As a side eect, this property also ensures that the merchant never suers as a result of foul play by the customer. Thus, fair-exchange is ensured in our protocol. Below we briey discuss the theory. For more details as well as proof of correctness the interested reader is referred to [6].

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.

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

249

2.1. Cryptographic background The theory of cross validation is based on an asymmetric encryption technology, which is an extension of the classic RSA encryption technology. Messages and keys are represented as positive integers. Encryption and decryption functions are nothing but modular exponentiation operations. A encryption key K is dened to be the ordered pair e, N, where N is a product of distinct primes and e is relatively prime to /(N).1 The decryption key K1 corresponding to the encryption key K is the ordered pair d, N satisfying the equation e dmod/(N) = 1. The encryption of a message m < N with the key K is denoted by [m, K] and is dened as [m, K] = [m, e, N] = me modN. Similarly the decryption of message m 0 with the decryption key K1 is dened as [m 0 , K1] = (m 0 )dmodN. If m 0 = [m, K], then m = [m 0 , K1]. We dene two keys K1 = e, N1 and K2 = e, N2 to be compatible if N1 and N2 are relatively prime. The product of two compatible keys K1 and K2, given by K1 K2 is  dened as e, N1 N2. 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 modN 1 m; K 1 modN 1 if and only if m m   m; K 1 K 2 modN 2 m; K 2 modN 2 if and only if m m Basically, the two properties imply that if a message is encrypted with the product key of two compatible keys and another message is encrypted with either of the two compatible keys and the two encrypted messages compare, then the two original un-encrypted messages must also compare. The signicance 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 satises 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 satises 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 N1. When the customer decides to purchase m, it rst downloads T m; K M 1 from the trusted third partys 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 1 such that K M 2 is compatible with M2 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 TmodN1 = T 0 modN1. If TmodN1 = T 0 modN1 evaluates to true then the validated receipt property is satised. The customer then proceeds to send the payment for the product. The merchant in return sends the product decryption key K 1 . Finally, M2 the customer obtains the actual product m by decrypting T 0 with the key K 1 . M2 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 rst 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 he; N 1 i; K M 2 he; N 2 i, K M 3 he; N 3 i and K M 4 he; N 4 i are compatible. Let N = N1 N2 N3 N4. Knowing memod Ni, for i = 1, . . ., 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 dicult. To preclude this scenario and provide an additional degree of security we use a random number in the encryption process as follows. For every transaction Ti that the merchant performs for the product m, the merchant chooses a random number r, which is relatively prime to the current encryption key modulus Ni+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
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 dierent 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) 247259

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 condent that the validated receipt property is satised. The customer can now go ahead and pay for the product. For the decryption key, the merchant now sends K 1 M2 and r1 instead of just K 1 , where r1 is the multiplicative M2 inverse of r modulo N2. Using the decryption key K 1 the M2 customer obtains m rmodN2. Multiplying this value by r1 the customer retrieves m. 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 appropriate decryption key. Similarly, cryptographic checksums 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 nancial institution. 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 various parties. The direction of the arrow shows the direction of the message sent while the label of the arrow shows the contents of the message. Note that each message is accompanied by a signed cryptographic checksum of the contents so that integrity of message and non-repudiation of origin is ensured. Also each message is encrypted by the recipients public key while in transit, so as to ensure condentiality. 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 C, M, B and TP Aprv, Apub [X, K] CC(X) wA K C1 ; K 1 C1 K C2 ; K 1 C2 K M 1 ; K 1 M1 K M 2 ; K 1 M2 R r1 M PID PO Cact u Acert Interpretation IDs for the customer, merchant, bank and trusted third party The private and public key pair of an entity A The encryption of object X with the key K 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. A nonce for the entity A. Each entitys nonces are unique and dierent 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 is kept by the bank indexed by the C1 customers id. K C 1 he; N 1 i; K 1 hd; N 1 i and e d1  1modN 1 C1 Key pair generated by customer; the key K C2 he; N 2 i is compatible with the key K C 1 and the key K 1 hd2 ; N 2 iis the decryption key C2 corresponding to K C2 ; e d2  1modN 2 A key pair generated by the merchant and given to the trusted third party; K 1 hd0; N 1 i decrypts anything that is encrypted with M1 K M 1 he; N 1 i; e d 0 1modN1 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 1 hd 2 ; N 2 i M2 decrypts anything encrypted by K M 2 since e d2 1modN2 A random number chosen by the merchant for the current transaction Multiplicative inverse of rmodN2 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, wC Customers account information with the bank Payment token used by the customer to pay for m. The payment token contains information to debit Agreed_Price amount of money from the customers account in the bank and credit it to the recipient. The Agreed_Price is signed by the merchant. Entity As public key certicate

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

251

Initial setup merchants product registration with trusted third party

Initial Setup Customer and Merchant negotiates price for selected price Customer Merchant Customer initiates price negotiation for product by sending a basis for the requested price Merchant Merchant responds by agreeing to Agreed_Price

Merchant

Merchant

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

Customer

Initial setup customer determines product from catalog service at the trusted third party

Initial setup customer prepares payment token from bank

Customer Customer Trusted Customer browses third catalog, nds party product to purchase and requests download Trusted of encrypted third product from party catalog and merchant id

Customer

Customer

Bank Customer prepares and sends payment token for bank to sign Bank Bank veries that customer has sucient funds and if so, signs the payment token.

Basic protocol:

Customer

Customer

Customer

Merchant Customer creates and sends purchase order to merchant with encrypted payment token (signed by bank); associates a unique transaction identier Ti, stores a log record Ti,INITIATE and waits for encrypted product Merchant Merchant writes a log record Ti,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 Ti,ABORTrecord 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 Ti,PAYMENT-SENT record else an unsuccessful validation message is sent. If merchant has aborted in previous step, customer writes Ti,ABORT record. Merchant If merchant succeeds in retrieving payment token, it sends the decryption key for the encrypted product and writes Ti,FINISH else merchant sends failure

Customer

252

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

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 1 only after it has successfully received the payment that M2 is, only after it has been able to successfully decrypt the payment token with the decryption key K 1 sent by the customer. C2 Consequently, the merchant can never claim foul play on the part of the customer after it has sent out the product decryption key K 1 (it had an opportunity to back out from the M2 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 customer sends the payment token decryption key K 1 in good C2 faith to the merchant. However, due to network failure the merchant never receives it and consequently does not send the product decryption key K 1 . Or the merchant sends the M2 product decryption key K 1 but the customer does not receive M2 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 customer needs to send the payment token decryption key K 1 C2 to the third party together with evidence of transaction. This is a major change from the original version of the protocol [5]. Extended Protocol:

Theorem 4. The e-commerce protocol ensures fair-exchange. Proof. To show fair exchange we rst note that the payment token used in the transaction species the amount that is debited from the customers account and credited to the merchants account. This specied by the value Agreed_Price which is signed by the merchant. So the customer 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

Customer

Trusted third party

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

Trusted third party Trusted third party Trusted third party Trusted third party Trusted third party Customer

Merchant

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

Merchant

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 Customers This step is optional. The trusted third party contacts the customers bank bank only if the product decryption key fails to decrypt payment token correctly Customers This step is optional only if last step occurs. Customers bank 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 token If the merchant responds to the third partys request within the 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.

Trusted third party

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

253

in the basic protocol. But then the extended protocol is started which ensures that the customer nally gets the product. Thus follows the proof. 3. Implementation of the E-commerce facility We now describe our eorts to build a complete e-commerce 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 modules the (trusted) Third Party, the Merchant and the Customer. The Third Party module includes three major servers (i) a certicate server that provides certied 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 customer 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

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 Ecommerce 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 customers and the merchants nancial institution. These can be the same entity or dierent entities. In our implementation we provide the necessary interface for standardized AFSA protocols3 that are used in communication with nancial 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 dierent players in the protocol to provide the e-commerce service. Finally, the data tier provides the back-end data management functionality 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 Microsystemss JAVA technology including Jbuilder 5 and the Java Development Kit, iPlanet Web Server and the iPlanet Certicate Management Solution and the MySQL database management system. The iPlanet Web Server is an extremely powerful 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 particular, with the readily available iPlanet Certicate Management System. The latter is a highly congurable set of software components and tools for creating, deploying and managing public key certicates. Based on open standards for certicate management, this set of tools leverages the Netscape Directory Server and Netscape Console to provide a complete, and scalable certicate management solution. We use JDKs built in application Keytool, to generate publicprivate key pairs, generate certicate request and import certicates into Keystore. The certicates are then managed by the iPlanet Certicate Management 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.

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

American Financial Services Association protocols.

254

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

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 diculty 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 implementation issues. For this discussion we emphasize more on our experiences in implementing the cryptographic subsystem than any other component. 4.1.1. Software modules Three major software modules implement the e-commerce facility. They are the Third Party server, the Merchant server and the Customer application. The merchant server has an additional module, the Registration Application module that provides an important functionality to the protocol. A fth software module is necessary to complete the protocol. Its the Bank Server, which provides nancial services to the customer and the merchant. Since such a service is really a universal one and not limited just to our e-commerce facility, we assume that one is available. There are well-dened protocols for communication with nancial institutions. In our implementation, we developed a very rudimentary version of a Bank Server so that the necessary 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 Customers 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 implements the trusted Third Party in the protocol. It is implemented 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 rst veries the certicate of the merchant. If veried, the third party checks the signature of the merchant and the integrity of the message received. If everything veries 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 merchants 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 message. This message is either a registration success message or a registration failure message. For the product download request which comes from the customer, the third party server rsts 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 merchants 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 merchants master key to decrypt the product from its catalog and send it to the customer.

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

255

4.1.1.2. 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 the registration request, the merchant includes product 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 Partys public key, secure hash value for this decryption key, Merchant ID, Merchant IP address, Merchant Port number and Merchants certicate. If the merchant is a new merchant to the Third Party, then the merchant does not have to provide a Merchant ID; the third party automatically provides one. After sending the request to Third Party, the Merchant will receive the registration response. The response displays whether this registration transaction is success or failure. If it is failure, the response will also contain an appropriate reason. 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 customers 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 implements the customer process. To purchase a product the module sends a download request to the third party module. 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 customer 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 verication and data integrity modules Digital signature, message digests and secure message authentication codes are used throughout the implementation 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

take a message, m, of arbitrary length and compute a xed length ngerprint of the data H(m) called the message digest. For the signature, we sign the message digest by computing d(H(m)), where d() is the RSA signature algorithm. Digital signature generation follows these steps: (i) A message digest is computed. (ii) The message digest is encrypted using the private key of the publicprivate key pair, producing the messages digital signature. Signature verication follows these steps: (i) The signature is decrypted using the public key of a publicprivate key pair, producing a message digest value. (ii) The message digest value is compared with the message 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. We use the Signature class in java.security to perform sign and verify. The Signature class supports both signature generation and verication. The Signature class is a factory class, and Signature objects are created with the static getInstance() 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 message 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 SHAmessage digest algorithm with the RSAsignature algorithm to sign and verify. 4.1.3. Key generation algorithm This implementation uses KeyPairGenerator class to generate publicprivate 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 identies 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) 247259

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()

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 certicate generation.

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

make the results of operations, such as key generation, difcult 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 getInstance(), 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 PublicKey object and PrivateKey object using getPublic() and getPrivate() methods in KeyPair class. In our implementation, generating compatible keys and product keys are a little dierent from generating RSA key pairs. Product keys are the keys for encrypting digital goods and payment tokens. For each such message, we need keys K1 = e, N1,K2 = e, N2 and K he; N 1 N 2 i. After getting public key/private key pair using the way described earlier, we need to generate the related key K2 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 MyRSAPrivateKey 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 getInstance() 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.

After creating MyRSAPublicKey/MyRSAPrivateKey pair as key K1 and inverse of K1, respectively, we need to compute K2 and K. Note that K1 and K2 are compatible. Using Denitions 11 and 12, we know that to create K2 we need to compute N2 such that N1 and N2 are relatively prime. N is dened as N1*N2. To create N2, rst we generate primes P2 and Q2. Then compute N2 = P2*Q2. We still need to check whether N2 and N1 are relatively prime. After getting N2, we can compute N as N1*N2. Finally, we get K1 = e, N1,K2 = e, N2 and Ke, 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 les to represent products. Each product is encoded in MIME specication. Before transmission the relevant keys encrypt the le. To do this the encryption program rst reads the binary le as a byte array. It then divides the byte array into 64 bytes long blocks and converts these blocks to BigInteger (BigInteger class in the Java API). Encryption is performed 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 original product. In the implementation, class BigIntArrayObj represents product that has been divided to small blocks. In this class, there are some elds: BigInteger array, integer array, and integer for last length. BigInteger array contains the big integer values obtained from each block of the binary le, integer array contains the ags 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 twos-complement representation of this BigInteger. The byte array is in big-endian byte-order: the most signicant 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) 247259

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 eld in class BigIntArrayObj is for this purpose. Last, because the toByteArray() method in BigInteger 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 nal byte array is 64 bytes long. If it is shorter that 64 bytes, then for positive BigInteger, we need to add 0s in the front of the byte array, for negative BigInteger, we need to add 1s in the front of the byte array. For the last BigInteger, we use the integer eld lastLen in BigIntArray class for recording the original length of byte array. 4.1.5. Certicate generation and key management For lack of a proper certifying authority in our test-bed, we use self-signed certicates 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 format certicate and specify the appropriate elds in the certicate. Below is the code for generating the self-signed certicate. To be useable in practice, the only change that is needed is the specication of an appropriate certifying authority in the certicate. We create a key store to store the key pair and certicate. In JDK 1.3, a keystore is a container for secret keys, publicprivate key pairs, and certicates 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 publicprivate key pair (and a chain of certicates that authenticates the public key). A key entry can be used to sign objects and to provide a certicate that authenticates the signature. (2) Trusted Certicate Entry: Holds a public key certicate of another party. Each of the entries in a keystore is associated with a unique alias. This alias is a string that identies the use of a key entry or the name of the entity with which a trusted certicate 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 certicate for the public key, we store them in the keystore Fig. 6. Before registration for product, the Merchant needs Third Partys certicate. We use Keytool to import the Third Partys certicate to the keystore. The Merchant then can read the Third Partys certicate from the keystore as and when required. Keytool was introduced with the Java 2 SDK. It is used to manage keys and certicates. 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 certicate for the public key. (2) Management of key entries: allows key entries to be created, imported, exported, listed, and deleted. (3) Management of trusted certicate entries: allows the certicates and certicate chains of others to be imported, exported, listed and deleted. (4) Certicate signing request (CSR) generation: CSRs can be generated for submission to a certication 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. 7. Structure of a typical certicate.

258

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

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

We use the command keytoolimportle certicate.txt alias cert to import a trusted certicate. The steps to get a certicate are: (1) Generate key pair and store it in keystore. (2) Use keytool to generate Certicate Signing Request. Using the command: keytool certreq alias Signer le csr.txt. (3) Send the request that stored in le csr.txt to a certificate server. (4) After getting the certicate response from certicate server, we import the certicate into the keystoreusing keytool. A typical certicate 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 network, there are two methods that are invoked by the relevant module toXml() and fromXml(String s). The rst method toXml() generates the XML message representing the object and the second method fromXML(String s) parses the objects 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 vendorspecic 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 le mm.mysql2.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 standard 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-commerce protocol that we have developed to facilitate e-commerce 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 suers 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 o-the-shelf software components. We found JDK to be particularly useful in our eorts. At this stage we have a working prototype 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 checksums, etc. These remain part of our future work. Acknowledgements This material is based upon work supported by the National Science Foundation under Award Number IIS 0242258. Any opinions, ndings, and conclusions or recommendations expressed in this publication are those of

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

259

the author(s) and do not necessarily reect 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. 7788. [2] B. Kaliski, M. Robshaw, The secure use of RSA, CryptoBytes 1 (3) (1995) 713. [3] F. Bao, R.H. Deng, W. Mao, Ecient and practical fair exchange protocols with o-line ttp, in: Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1998, pp. 7785. [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. 8493. [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 Certicate Management System Agents Guide.

[8] iPlanet E-commerce Solutions. iPlanet Web Server Programmers Guide to Servlets. [9] J. Zhou, D. Gollman, A fair non-repudiation protocol, in: Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1996, pp. 5561. [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. 717. [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. 8699. [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, Helsinki, Finland, 1998, pp. 591606. [13] R.H. Deng, L. Gong, A.A. Lazar, W. Wang, Practical protocols for certied electronic mail, Journal of Network and System Management 4 (3) (1996). [14] S. Ketchpel, Transaction protection for information buyers and sellers, in: Proceedings of the Dartmouth Institute for Advanced Graduate Studies95: Electronic Publishing and the Information Superhighway, 1995. [15] S. Ketchpel, H. Garcia-Molina, Making trust explicit in distributed commerce transactions, in: Proceedings of the 16th International Conference on Distributed Computing Systems, 1996, pp. 270281.