On the Design of Secure Electronic Payment ... - Semantic Scholar

4 downloads 0 Views 182KB Size Report
a variety of ways, namely using cash, cheques, credit and debit cards. ... Merchant. Client. Finanical. Institution. Figure 1: Participants in an Electronic Credit Based. Payment ...... electronic cash. in Advances in Cryptology ? CRYPTO '88 ...
On the Design of Secure Electronic Payment Schemes for Internet Vijay Varadharajan and Yi Mu Distributed System and Network Security Research Unit, University of W. Sydney, Nepean PO Box 10, Kingswood, NSW 2747, Australia (fvijay,[email protected])

Abstract

enabling secure commercial transactions form the foundation stone of this electronic information revolution. In the non-electronic world, payments are made in a variety of ways, namely using cash, cheques, credit and debit cards. Similarly, in a network environment, payments may be made using any or all of the above methods. Needless to say security aspects become critical to the successful operation of any of these electronic payment schemes. Broadly speaking, there are two classes of electronic payment schemes. Schemes such as DigiCash [1, 2] and NetCash [3] try to emulate \cash" like properties for electronic payment. Others such as iKP [4], NetBill [5], NetCheque [6], CyberCash [7], STT [8] and SEPP [9] consider credit and debit based electronic payments. Our focus in this paper is on credit based electronic payment systems. We use the iKP family of protocols as a representative of this class to develop our arguments. Our discussion is also applicable to other protocols in this class such as the STT and the SEPP protocols which have been proposed by today's largest credit card operators VISA and MasterCard respectively. The organization of the paper is as follows: Section 2 analyses this class of electronic credit card schemes, and reveals some of the issues that have been inadequately addressed by the protocols proposed todate. This discussion leads to the development of an improved payment protocol. The new protocol (referred to as Permission Based Payment Protocol (PBP)) is described in Section 3. It makes very simple assumptions in terms of what clients have and the environment, but still provides a high degree of security; hence its practicality in providing secure commercial electronic credit card based transactions. In particular, the proposed scheme separates the purchase request phase from the payment phase; we will show that this separation increases the ability to handle certain class of disputes. It provides a fair treatment of the Client and the Mer-

This paper considers the design of secure electronic credit card based payment schemes for Internet and reveals some of the issues that have not been adequately addressed in the proposed protocols todate. It proposes additional mechanisms that need to be incorporated as part of the design phase of the scheme to deal eciently with the disputes that can arise. The design methods described in this paper are applicable to a range of protocols including iKP , STT , and SEPP . Based on this discussion, the paper goes on to propose an improved payment scheme and protocol. The new protocol provides a fair treatment of both the Client and the Merchant involved in the transaction. It se parates the purchase request phase from the payment phase thereby increasing the ability to handle certain class of disputes more eciently. It removes the need to store the secret private key at the Client's machine or the need for a smartcard device. This is important as one cannot assume that all the clients connected to the Internet have or will have smartcard readers attached to them. The new protocol makes simpler assumptions about the environment, thereby making the scheme practical for securing commercial electronic credit card transactions.

1 Introduction Recently there has been an explosion of interest in the area of electronic commerce and payment schemes over Internet. In particular, several protocols dealing with payment for Internet transactions have been proposed, while several others are in development. It is clear that if Internet were to become an open marketplace for goods and services, the need for secure charging and payment is essential. Given the explosive growth in the use of Internet, and in the services and applications being o ered over the Internet, the mechanisms 1

chant involved in the transaction. The scheme also removes the need to store the secret private key (of the public key system) at the Client's machine or the need for a smartcard device. Furthermore, based on the principle of separation of tasks, it introduces and uses an electronic commerce identity which is employed only when carrying out electronic commerce transactions. Section 4 presents our concluding remarks.

2 Electronic Credit Based Payment Systems In general, an on-line credit card payment system involves at least the following parties: Clients (Service Users) requesting services from Merchants (Service Providers) who provide the services, and Financial Institutions providing guarantee and transfer of cash and credits between Clients and Merchants. STT and SEPP refer to the Financial Institution as the Acquirer whereas iKP models this using a Gateway that acts as an intermediary to the existing nancial network. Client

Merchant

Finanical Institution

Figure 1: Participants in an Electronic Credit Based Payment System The ow of messages between the Client, Merchant and the Financial Institution is shown in Figure 1. There are minor variations between the di erent protocols in terms of the message structure and the terms used, but these are not relevant to our present arguments. In our discussion we use the terms similar to iKP. The Merchant presents the information about the service in terms of an Offer (or some sales information). When the Client wishes to make a purchase, s/he sends an Order and a payment Slip to the Merchant. The Order is intended for the Merchant whereas the Slip is passed on to the Financial Institution. The Merchant requests the authorization from the Financial Institution, and upon receipt of the authorization (referred to as Authz), the Merchant con rms to the Client the conclusion of the payment transactions. This is then followed by the service delivery. All the three systems mentioned above rely on the use of public key technology and certi cates.

2.1 Notation

The basic quantities used in the message ows are as follows:

 Merchant's o er: Offer  fo er description, price, items, expiration time, identity of merchantg  Client's order: Order  forder description, amount, currency,

timestamp, identity of merchant, identity of client, delivery address g  The client's payment slip: Slip  fcredit card number, expiration date, amount, currency, timestamp, PIN, identity of merchant, h(Order)g.  The authorization from the nancial server: Authz  f`approve'/`reject', identity of nancial server, h(amount, currency, timestamp), identity of merchant, h(Order)g  Public key certi cate for user X: CertX  fidentity of X, X's public key, timestamp, validity of public key, issuing authorityg signed by the issuing authority. We also use the following notation in the protocol description:

         

C: Client M: Merchant TA: Trusted Certi cation Authority. TX : Timestamp generated by X. KX?1 : Private Key of user X. KX : Public Key of user X (associated with KX?1 ). h:::iKX : Public Key Encryption key using KX . h:::iKX?1 : Public Key based Signature KX?1 .

TransNo: Transaction Number. A ! B : message: denotes that a message is sent from party A to party B.

2.2 A la 3KP Protocol

Let us now consider a protocol a la 3KP, and look at what each of the parties have in terms of security information. We will consider the case where all the three parties have public key and private key pairs. This case corresponds to the 3KP protocol.

 Financial Institution (F): F; KF?1; KF ; CertF ;

KTA ; PIN. F has its public key - private key pair, (KF , KF?1 ). This enables F to sign its messages. F has the certi cate CertF validating KF , which has been issued by the trusted authority TA. We will assume the existence of such an authority.  Merchant (M): M; KM?1 ; KM ; CertM ; CertF ; KTA . M has its own public key - private key pair (KM , KM?1 ); hence M can sign its messages. M also has F's certi cate CertF and his own certi cate CertM . Once again, M's certi cate is signed by the trusted authority TA1 .  Client (C): C; KC?1; KC ; CertC ; PIN; KTA . C has a public key - private key pair (KC , KC?1 ), its certi cate CertC , and a PIN. To illustrate some of the issues in the design of of payment schemes, we use as an example the 3KP protocol given below. 1: M ! C : CertM ; CertF ; Offer 2: C ! M : CertC ; Order; hhSlipiKF ; h(Order)iKC?1 3: M ! F : CertM ; CertC ; hhhSlipiKF ; h(Order)iKC?1 iKM?1

4: F ! M : hAuthz; hSlipiKF iKF?1

5: M ! C : hAuthz; hSlipiKF iKF?1 ; hhhSlipiKF ; h(Order)iKC?1 iKM?1 .

6: M ! C : fServiceg

2.3 Protocol Discussion

First note that in the protocol discussed above, the encrypted version of Slip has been signed by the Client. A general principle to follow in the design of cryptographic protocols is to avoid signing encrypted content. This is because signing of an encrypted message does not necessarily imply that the plain message has been seen by the person who signed it. Now consider the problem of replay of message in Step 2. Note that the Merchant cannot read the contents of Slip but can check the contents of the Order. 1 If the trusted authorities are di erent, then we assume the existence and access to cross-certi cates enabling one party to verify another party's certi cate.

In principle, message replay can be detected by checking the timestamp that appears within the or der. However from the Merchant's point of view, s/he may feel that it is perfectly legitimate for a Client to make multiple purchases within a time window for the same service as long as the Client pays. As the Merchant sees only the encrypted Slip, s/he will pass on the Order and the encrypted Slip (the replayed message) to F. The burden is therefore on F to determine that the message 2 in Step 2 (or the message 3 in Step 3) is a replayed message. Though it is quite correct for F to thoroughly validate the integrity and uniqueness of message at Step 3 before it takes the authorization decision (which is the norm in most schemes), the above argument shows the opportunity that exists for replays to occur; the conclusion we would like to highlight is the need for ecient mechanisms at F to deal with these situations thereby not degrading the system performance. In the class of payment protocols such as the one analysed above, the Client sends both the Order and the payment instruction Slip together (cf. Step 2). The assumption is that when the Financial Institution receives the Slip via the Merchant in Step 3, it will carry out procedures to debit the Client's account and credit the Merchant's account. This may be done during the protocol run or may be done at a later point in time in an o -line manner. But the crucial point is that the decision to debit and credit appropriate accounts has been taken and committed after Step 3. This aspect introduces several issues. First, at this point in time, the decision to credit Merchant's account and debit Client's account has been committed even though neither the Client has received the service and nor the service has been provided by the Merchant. Subsequently, the Merchant may deny that s/he has received the authorization from F as s/he knows that the account has or will be credited. The denial by the Merchant can be genuine if there has been a communication error in Step 4 or it may be malicio us if s/he has received the Step 4 message. After a certain wait period for receiving Step 5 message from the Merchant, the Client may decide to contact the Merchant again. If the Merchant is in fact malicious or if the communication links between the Me rchant and the Client are loss prone, then the Client has to get in contact with F with a reliable evidence that it did not receive the requested Service. If the Client decides to purchase the same Service from another Merchant, this poses a problem, because the decision to debit Client's account has already been committed. Hence there is a need for the Client to go through another proc ess for obtaining refunds which in general increases the transaction costs.

We will refer to this characteristic in payment protocols design as merchant trusted since it relies on the honesty of the merchant. Not only the trust assumptions need to be made explicit but also suitable mechanisms should exist to deal with situations when such disputes arise. The protocols proposed so far have tended to ignore these aspects. Any scheme that requires the use of public key technology creates the need for secure storage of private keys associated with the public key system. The scheme such as the one above requires storage of private keys for all the three parties. The storage of Client's private key raises additional issues. The Client's secret key can be store d in a tamper-proof device such as a smartcard or may be stored within the Client's machine protected using access control mechanisms. Here it is important to consider the assumptions that one can make about the operating environment. If one considers a simple environment where we have PCs connected to the Internet, neither of the above solutions may be practical. The use of smartcard requires some form of a smartcard reader attached to the PCs2 . One cannot assume that all the PCs connected to the Internet have or will have smartcard readers attached to them. Use of access control mechanisms to protect the private key stored in the PC is in general not very secure. One can encrypt the private key using some other symmetric key which the user can remember3. However the problem here is that this places constraints on the mobility of the user. That is, it ties the user to a particular machine where the private key of the user is stored.

3 Improved Payment Scheme In this section, we propose an improved new scheme which overcomes the weaknesses outlined above. The scheme has the following characteristics. (A) the separation of purchase request and payment instruction, thereby reducing the dispute problem discussed above (B) the removal of the need to store the secret key (of the public key system) at the Client's machine or the need for a smartcard reader (C) introduction of an identity which is used only in carrying out electronic commerce transactions, based on the principle of separation of tasks. 2 It is possible to use smart diskettes which do not require special smart card readers. 3 The assumption here is that it is far more dicult to remember a 512-bit private key of an RSA system compared to remembering a 8-10 character symmetric key

3.1 Environment

We assume that users have standard credit cards issued by Financial Institutions with a credit card number, expiry date and a PIN. If a user wishes to engage in any electronic payment transaction over the Internet using the credit card, s/he registers with the Financial Institution his or her intentions and the Financial Institution issues an identity which we refer to as an Electronic Commerce ID (EID). Note that this is a one-o process which typically occurs when the credit card is being issued4 . EID is a sequence of some 8 characters, and the EID is stored at F's database and the user is expected to remember it just like a password. The introduction of such an EID serves several useful purposes. First, it helps the user to separate the ordinary (non-Internet) electronic transactions which s/he is carrying out in the usual manner from the Internet based electronic payment transactions which use EID. This notion is similar to the idea of separation of tasks or duties; in this case, we are using the type of ID attribute to create a coarse partition of electronic payment transactions. Adoption will also give the user a mechanism whereby s/he can choose not to obtain the EID if s/he does not wish to use the credit card for payments over the Internet.

3.2 Permission Based Payment Protocol (PBP)

As before, we have the three parties in the protocol, namely the Financial Institution (F), the Client (C) and the Merchant (M).

 Financial Institution F has the following security

related information: F, KF?1 , KF ; CertF ; KTA ; PIN; EID; certC F has its own public key - private key pair and the certi cate CertF signed by TA. However note that certC is di erent from 'normal' certi cate and hence we will call it a \pseudo-certi cate". It is signed by TA and contains the Client's pseudopublic key ppk along with the Client's identity, timestamp and validity period. We will see below the relationship between the ppk, the PIN and the EID.  Merchant has the following information: M; KM?1 ; KM ; KTA ; CertM ; CertF These are same as the ones used in the earlier protocol.

4 This is similar to the additional registering process required with many banks now if one wishes to do telephone banking.

 Client: C; PIN; EID; KTA

Note that one of our requirements is that the Client does not store any private key within the machine. However public key features are required for non-repudiation and signature purposes when conducting secure electronic business. This is achieved using the pseudo parameters which are computed at the preparation stage of the transaction. The Client computes a pseudo secret key parameter psk as follows: psk = h(PIN  EID  CreditCardNum). The corresponding pseudo public key parameter ppk is given by (psk ppk mod (n) = 1), where (n) = lcm(p ? 1; q ? 1), p and q are large primes and lcm denotes the least common multiple. If the PIN is 32 bits and the EID is 64 bits, then PIN plus EID gives a total of 96 bits. The factorization of n is known only to TA. To further strengthen the cryptographic security of the system, we use psk in conjunction with a random number RC . (R?C 1RC mod (m) = 1), where

(m) = lcm(u ? 1; v ? 1), and u and v are two large primes generated at the Client and used only once. We will see below how these are used. The introduction of RC and R?C 1 can be seen an optional extension of the protocol (See Section 3.7). The protocol can function without them in its basic form. The important thing to note is that all these parameters ppk, psk, and if used RC , u, v are generated at the preparation stage of the protocol and are removed at the end of the protocol run. Hence it is not necessary to store them for use in the subsequent protocol runs, which is distinctly di erent from the use of permanent public keys.

 We will be using RequestSlip instead of Slip to

emphasize that it is a purchase request and no monetary transaction takes place when F receives it. It has the same syntax as Slip. We have a PaymentSlip later in Step 7 which indicates the payment instruction. PaymentSlip includes hC; TransNo, Timestamp, M, h(Order)i.

 Delivery Key DKey used to encrypt the Service provided by M to C.

3.3 Protocol Steps 1: M ! C : M; CertM ; CertF ; Offer; hh(Offer)iKM?1 .

2: C ! M : C; Order; hh(Order)iR?C1 ; hC; F; m; RC; TransNo; hhh(m; RC ; TransNo); RequestSlipipsk iR?C1 iKF .

3: M ! F : M; CertM ; hF; hC; F; m; RC ; TransNo; hhh(m; RC ; TransNo); RequestSlipipsk iR?C1 iKF ; h(Order)iKM?1 : 4: F ! M : F; hF; M; C; yes=no; RC ; m; h(Order); TransNo; TF iKF?1 ; hF; M; C; TransNo; TF ; hDkey; iKM iKF?1 .

5: M ! C : M; hServiceiDkey ; hM; C; TransNo; TM ; h(Service); h(Order)iKM?1 ; hF; M; C; yes=no; RC ; m; h(Order); TransNo; TF iKF?1 : 6: C ! M : C; hPaymentSlip; h(Service)iR?C1 . 7: M ! C : M; hhM; C; Dkey; TransNo; TM0 ; h(Order)iKM?1 iRC .

The next two Steps 8 and 9 can be done anytime after Step 6. 8: M ! F : M; hM; F; TM00 ; hhPaymentSlip; h(Service)iR?C1 iKM?1 . 9: F ! M : F; hF; M; C; PaymentCompleted; TF0 ; h(Order); h(Service)iKF?1 .

Step 1 is very similar to the rst step in the earlier protocol with one minor addition namely M's signature on the Offer. In Step 2, the RequestSlip along with the hash function has been signed using the (psk, RC ) mechanism and then encrypted under the public key of F. More explicitly, the Client's signature is given by ((h(m; RC ; TransNo); RequestSlip)psk modn)R?C1 modm. Note that the veri cation of this signature depends on both ppk and RC . It is important to note that the semantics of the signed RequestSlip in this message only denotes the authority of purchase request and not a payment instruction. Hence the explicit use of the name RequestSlip instead of Slip. The paymen t instruction part occurs at the end of the protocol in Step 6. Since RC , m and Slip are encrypted under F's public key KF , only F is able to extract this part of the message. The hash of the Order is also signed by the Client using RC . There are two points to note here. First the

Order is signed using R?C 1 and not (psk; R?C 1 ). The use of psk can be seen as a 'permanent' signature of the Client, whereas the use of RC alone is more like a 'session' signature. The Step 2 chains these two parameters. Second, if the contents of the Order need to be kept con dential, then they need to be encrypted. This may be required for certain services; however this is optional. In Step3, the Client signed and encrypted RequestSlip and h(Order) are now signed by M and passed onto F. Using RC and computing ppk, F can verify the Client's signature: ((SignedMessage)RC modm)ppk modn. F can verify the Merchant's signature using M's public key in the usual manner. In Step 4, when F is able to satisfy itself of the validity of the Client's request, F returns to M a Yes/No authorization for the speci c service request. This is achieved by attaching the h(Order) signed by F. In making this decision F goes through all the normal procedures which need to be done for this decision to be made. The one important di erence here is that the accounts of the Merchant and the Client are not updated at this stage. F also sends RC and m to M. We have two design choices for the establishment of the delivery key Dkey which is used to encrypt the service provided by M to C. Either F can generate the key and pass it to M as part of the message in Step 4, or M can generate the key itself. In one sense the second option of M choosing the key would be better as it is in the interest of M to protect its service and hence to select the key. For instance, in the case of NetBill [5], M generates the one-time key used to encrypt the service. However from the arbitration of disputes point of view, F determining the key and passing onto M is more appropriate as we discuss below. Note that there is a timestamp TF included in this message. This is generated by F and it indicates the time at which the authorization of purchase request is given by F. In Step 5, M delivers the service to C in an ecrypted form using the delivery key Dkey. The message also contains the F's reply to M in Step 4 as well as M' s signature on hashed Service and the Order. There is also a timestamp TM in th is message which indicates when the encrypted service is delivered. C is able to verify the contents of the signed message from F to M authorizing the request as well as the signature of M on the hashed Order. However, C cannot obtain the Service itself, as it has not yet received the delivery key. If the checks on the hashed Order received from M, from F and its own initial

request match, then C sends a signed con rmation using its 'session' signature based on R?C 1 . The con rmation message indicates that a package has been received from M, and transfers the authority to pay in the form of a PaymentSlip. This constitutes C's payment instruction. The timestamp TC indicates when this payment instruction is made by the Client. M can present this PaymentSlip message to F for collecting the appropriate amount for the service provided. M can do this immediately or at a later point in time (e.g. at the end of a day) on a batch basis. After receiving the message from C in Step 6, M can provide the delivery key Dkey to C (Step 7) as M will be guaranteed the appropriate amount on presentation of the payment instruction in Step 6 to F. When M presents the payment instruction message to F in Step 8, F updates C's and M's accounts. It is at this time that the real monetary transactions take place. Note that F needs to store transaction records of the form < C; TransNo; M; Dkey; Timestamp; h(Order); Y=N > in its database. Y=N Flag indicates whether the transaction has been successfully completed or not. When the appropriate accounts have been credited and debited, the Flag is set to Y. F can search this database using (C; TransNo) as the indexing key. After a certain period of time, successful transaction records can be deleted by F. The time period for which the transaction records are maintained is a policy issue which may depend on F's organizational constraints, the type and value of transactions, and the typ e and characteristics of the Clients and Merchants.

3.4 On Disputes

One of the aims of the improved protocol is that both the Client and the Merchant should be fairly treated. The Client's account should be debited only after the point whereby the Client is guaranteed to obtain the delivery of the requested Service. In this case, this amounts to having an encrypted version of the service and the ability to obtain the delivery key used to decrypt the encrypted package. The Merchant is guaranteed that its account will be credited upon presentation of the pay ment instruction from the Client which is obtained prior to the transfer of the delivery key in the normal course of the protocol run. Consider the following dispute situations:

 The Merchant does not provide the delivery key

in Step 7 even though the Client has sent its payment instruction in Step 6. However if the Merchant wishes to get paid, s/he needs to present the payment instruction to F.

Consider rst the case where the Merchant has presented the payment instruction message from C to F. In this case, the transaction record would have been updated and appropriate accounts debited and credited. After some timeout period waiting for the Step 7 message from M, C contacts F directly and provides the evidence of the purchase request (Order and Slip) as well as the payment instruction (Step 6) message that it sent to M. After veri cation of the request and the payment instruct ion, and checking the transaction record, F provides the delivery key Dkey to C thereby enabling C to decrypt the service. Note that in this case, the transaction record will indicate that the accounts have already been updated which occurred whe n the Merchant presented the payment instruction. This will indicate to F that the Merchant was acting dishonestly. The sequence { whereby C having the encrypted version of the service before sending the payment instruction to M as well as F ha ving a copy of the delivery key Dkey { has helped us to address the problem of the Merchant behaving dishonestly. If, on the other hand, M was responsible for the generation of Dkey then it would be far more dicult to resolve this situation. It would be necessary for M to have sent a copy of Dkey to F before the accounts are updated by F (to protect against a dishonest merchant). However it would be dicult for F to verify whether the Dkey received from M is the \correct" one. Hence the decision for F to generate Dkey. This does add a new responsibility for F, and whether a nancial institution will be willing to accept this role needs to be further explored. If the Merchant has not presented the payment instruction message when the request from C comes to F, then this does not provide a clear indication that the Merchant is behaving dishonestly. It may be that the communications between the Merchant and the Client may be error prone, and that the Step 7 message containing the delivery k ey has not been able to reach the Client. On the other hand, the Merchant may be behaving dishonestly by deliberately waiting for some time prior to lodging the payment instruction message with F. Hence when C requests F for the delivery key, after veri cation of the purchase request and the payment instruction, F provides the delivery key to C and updates the transaction record. Subsequently, if the Merchant contacts F for payment, the transaction record will indicate that the Merchant's account has been updated appropriately

and F can inform the Merchant accordingly.

 The Client does not send the payment instruction

after receiving the encrypted version of the service in Step 5. Assuming that the encryption algorithm is strong, C cannot obtain the plain version of the service without the knowledge of the deliv ery key. However C can contact F and claim that s/he did send the payment instruction message in Step 6 to M but M did not provide the delivery key (even though C did not send the Step 6 message). The

ag in the transaction record will show tha t it has not been succesful, and hence F can update the Merchant and the Client accounts and update the ag, and then provide the delivery key to C. The Merchant after some timeout period waiting for payment instruction message (Step 6) from C may contact F to inform that s/he has not received the payment instruction message from C even though s/he has provided the encrypted service (Step 5). After checking the transaction record, F can inform M about the current status of the transaction, that is, whether C has requested the delivery key directly from F. If this is the case, then this situation indicates a dishonest Client5.

 Consider the case where the Merchant delivers fake

Service in Step 5. This may occur, for instance when the Merchant does not have the Client requested service. The Client discovers the aw after the reception of the delivery key in Step 7. The dispute can be resolved successfully by the Client presenting to F as evidence the received Service, the Merchant signed versions of the hashed Order and the hashed Service, along with F and Client signed versions of the hashed Order. The resolution involves F taking appropriate actions to recredit C account, and informing M and debiting its account.

 Finally, let us now consider the case of double pay-

ment request by the Merchant. This occurs by the replay of the payment instruction message to F by the Merchant. This is not possible in this protocol because once the payment for a particular transaction (M, C, TransNo, Order) is done, it is recorded on the transaction record along with the time at which this was done, and replayed requests for payment will not be successful.

5 There is a possibility that there was some communication problem between C and M; in this instance, C should inform F of its communication problem to F.

3.5 Protocol Discussion Let us now consider informally the transaction goals that need to be satis ed.

 F's Point of View

{ F believes (Service Transaction requested by C) ! Achieved after Step 3. { F believes (Service Transaction can be provided by M) ! Achieved after Step 8 (before the Client's and Merchant's accounts are updated).

 M's Point of View

{ M believes (Service Transaction authorized by F) ! Achieved after Step 4. { M believes (Service Transaction requested by C) ! Achieved after Step 4 (before the Mer-

chant provides the encrypted version of the Service). { M believes (Payment made by C) ! Achieved after Step 6, as the Merchant will be paid when s/he presents the message containing the PaymentSlip to F. { M believes (Service provided to C) ! For this to be achieved, theoretically M requires an acknowledgement to its message in Step 7 containing the delivery key.

 C's Point of View

{ C believes (Service Transaction authorized by F) ! Achieved after Step 5. { C believes (Payment made to M) ! C be-

lieves that as far as s/he is concerned the payment has been or will be made to M after s/he sends Step 6 message. { C believes (Service provided by ! Though C gets the encrypted Service from M after Step 5, C can only believe that the right Service has been provided by M after Step 7.

3.6 PBP Scheme Simpli cations We conclude by presenting some simpli cations of the above protocol.

3.6.1 Pure Public Key Approach

If we assume that the Client has a suitable facility for storing the private key, for instance using a smartcard, then one can use a 'pure' public key approach. (See (B) in Section 3). This leads to the following protocol: 1: M ! C : M; CertM ; CertF ; Offer; hh(Offer)iKM?1 .

2: C ! M : C; CertC ; Order; hOrderiKC?1 ; hC; F; TransNo; hhh(F; TransNo); RequestSlipiKC?1 iKF .

3: M ! F : M; CertM ; CertC ; hF; hC; F; TransNo; hhh(F; TransNo); RequestSlipiKC?1 iKF ; h(Order)iKM?1 : 4: F ! M : F; hF; M; C; yes=no; h(Order); TransNo; TF iKF?1 ; hF; M; C; TransNo; TF ; hDkeyiKM iKF?1 .

5: M ! C : M; hServiceiDkey ; hM; C; TransNo; TM ; h(Service); h(Order)iKM?1 ; hF; M; C; yes=no; m; h(Order); TransNo; TF iKF?1 : 6: C ! M : C; hhPaymentSlip; h(Service)iKC?1 .

7: M ! C : M; hhM; C; Dkey; TransNo; TM0 ; h(Order)iKM?1 iKC .

Once again the next Steps 8 and 9 can be done anytime after Step 6.

8: M ! F : M; hM; F; TM00 ; hhPaymentSlip; h(Service)iKC?1 iKM?1 .

9: F ! M : F; hF; M; C; PaymentCompleted; TF0 ; h(order); h(Service)iKF?1 . This protocol still has this important separation property whereby the purchase request and the payment are separated. Hence the discussion on disputes given in Section 3.4 still applies. As such, this can be seen as a useful extension to the class of electronic credit card based payment protocols; in particular, this extended scheme solves some the important inadequacies in the existing protocols such as iKP, STT and SEPP.

3.6.2 Removal of RC

We introduced a pair of random numbers R?C 1 and RC ,

which were used in the computation of the Client's signature in the form hh  ipsk iR?C1 . This led to an increased cryptographic strength of the signature scheme. However in certain circumstances, it may be considered adequate to use just the psk based on the PIN and the EID (which typically will have some 96 bits). This will result in the simpli cation of the protocol.

3.6.3 Trusted Merchant

If we assume that the Merchant is trusted to provide the service, then the protocol can be reduced to the following 5 Steps. This amounts to sending the purchase request and the payment instruction in Step 2, and the Client's and the Merchant's accounts being updated at the end of Step 3, as expected this is similar to the original protocol. The modi ed PBP scheme is as follows: 1: M ! C : M; CertM ; CertF ; Offer; hh(Offer)iKM?1 .

2: C ! M : C; Order; hOrderiR?C1 ; hC; F; m; RC ; TransNo; hhh(m; RC ; TransNo); Slipipsk hR?C1 iKF . 3: M ! F : M; CertM ; hF; hC; F; m; RC; TransNo; hhh(m; RC ; TransNo); Slipipsk iR?C1 iKF ; h(Order)iKM?1 :

4: F ! M : F; hF; M; C; yes=no; RC ; m; h(Order); TransNo; TF iKF?1 ; hF; M; TransNo; TF ; hDkeyiKM iKF?1 .

5: M ! C : M; hServiceiDkey ; hhM; C; TransNo; Dkey; TM ; h(Service); h(Order)iKM?1 iRC ; hF; M; C; yes=no; RC ; m; h(Order); TransNo; TF iKF?1

4 Concluding Remarks In this paper, we have considered the class of secure electronic credit card based schemes for Internet, and revealed some of the issues that have not been adequately addressed in the proposed protocols todate. In particular, the paper discussed the arguments that need to be carefully considered at the design stage to

deal eciently with the disputes that can arise. The paper presented these arguments using 3KP as a representative of the credit based class of protocols. The arguments presented are also applicable to other protocols such as STT adn SEPP. The results of these analyses led to the development of an improved payment scheme and protocol, referred to as the Permission Based Payment Protocol (PBP). The proposed scheme has several useful characteristics. It separates the purchase request phase from the payment phase; we have shown how this increases the ability to handle certain class of disputes. In particular, it provides a fair treatment of both the Client and the Merchant involved in the transaction. It removes the need to store the secret private key (of the public key system) at the Client's machine or the need for a smartcard device. This is worth considering as one cannot assume that all the clients connected to the Internet have or will have smartcard readers attached to them. Furthermore, it introduces an identity which is used only for carrying out electronic commerce transactions over the Internet. This idea is based on the principle of separation of duties or tasks. This mechanism gives the user an additional handle in choosing whether or not to use his or her credit card for electronic payment transactions over the Internet. We have also used an extended form of BAN logic to study some of the properties of this protocol. We have not presented this analysis in this paper, as we believe that this will only bury the reader with logical proofs. Furthermore, the analysis exposes some of the limitations of the logic rather than of the protocol. Hence it is more appropriate to describe it in a paper dedicated to the use of logic in the analysis of electronic commerce protocols where comparisons between di erent avours of the logic can be properly made[12].

References [1] D. Chaum, A. Fiat, and M. Naor. Untraceable electronic cash. in Advances in Cryptology ? CRYPTO '88 Proceedings, pp. 319{327, 1990. [2] D. Chaum. Achieving electronic privacy. Scienti c American, pp. 96{101, August 1992. [3] G. Medvinsky and B. C. Neuman. Netcash: A design for practical electronic currency on the internet. in Proceedings of the ACM Conference on Computer and Communication Security, November 1993.

[4] iKP. iKP - a family of secure electronic payment protocols. . [5] M. Sirbu and J. D. Tygar. Netbill: An internet commerce system optimized for network delivered services. , 1995. [6] B. C. Neuman and G. Medvinsky. Requirements for network payment: The netchequeTM perspective. in Proceedings of the IEEE CompCon'95, March 1995. [7] CyberCash. The cybercashTM system - how it works. . [8] STT. Secure transaction technology. , 1995. [9] SEPP. Secure electronic payment protocol. , 1995. [10] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. ACM Transactions on Computer Systems. vol. 8, pp. 18{36, Febrary 1990. [11] Bruce Schneier. Applied Cryptography. John Wiley and Sons, 1995. [12] V. Varadharajan and Y. Mu. Logic Based Analysis of iKP type Electronic Payment Protocols. Submitted for Publication, 1996.