INET Conferences


Conferences


INET


NDSS

Other Conferences


[INET'98] [ Up ][Prev][Next]

Payment in Electronic Commerce

Philippe MICHON <philippe.michon@cnet.francetelecom.fr>
France Telecom
France

Abstract

With the growth of the Internet, the network evolved from a research to a commercial network. Because the Internet is perceived as being an unsecured network, people are afraid to use it for commercial transactions. The first evolution that made the Internet more secure was the use of the SSL protocol, which encrypts all the data that are present on the channel. But the SSL protocol seems to be insufficient for banks, and there are also some legal problems with cryptography in several countries. The second evolution was the work of a group composed of companies like Visa and MasterCard. They created a universal protocol called SET (Secure Electronic Transaction) to use cards on the open network. This protocol has been accepted worldwide.

What is the French situation for the use of cards for electronic and face-to-face commerce? There are two distinctive features. The first one is the fact that the customer has been using a Minitel, for ten years, to purchase goods and services (weather forecast, newspaper information, timetable of trains and planes). In the French Minitel network, people are charged on their telephone bills for very small amounts (micropayments). For bigger amounts, the card is used in two ways: the secured way (inserting the card in the inside card reader) or the less secured way (giving the number and expiration date of the card). The second feature began in the 1980s. In this case the customer uses his card for payment in a face-to-face purchase: he inserts his card in the card reader of the merchant and enters his PIN code; the code is verified inside the smart card; if the code is correct, the card signs the transaction and creates a "French Payment Certificate."

With the rise of the Internet, the French bank community wants to build on this situation and needs to adapt the SET protocol. For this reason, a consortium has been created: eComm -- Electronic Commerce Consortium. The Consortium is composed of six members: three famous French banks (Banque Nationale de Paris, Société Générale, and Credit Lyonnais), Visa International, Gemplus (a card and card reader manufacturer), and France Telecom. The consortium has two different projects: the first one concerns the regular payment (for purchases above 50 francs) and the second concerns the micropayment.

First project: eComm phase I-a. The pilot of the first project will begin in December 1997 in France. As in the SET protocol, we have three actors -- the merchant, the gateway, and the customer -- but in our version, the customer has a card reader in his personal computer to increase the security. The merchant software is standard SET software; this means that the merchant can use, for example, American software. The cardholder must use a special wallet to take advantage of the smart card. The gateway is also modified to verify the French Payment Certificate. The steps are as follows:

  • The customer follows a link on the merchant Web server. The wallet, if the customer has an eComm certificate, asks the cardholder to insert his card and to enter his PIN code.
  • The PIN code is verified inside the card; if it's correct, the smart card creates a French Payment Certificate. This certificate is carried in the SET protocol to the gateway, which is able to verify it. The merchant can't do that.

Second project: eComm phase I-b, on the micropayment. The second project will begin in April 1998. The main idea is to use a postpaid card method. In the project we will use four actors: the customer, the merchant, the intermediary, and the gateway. The intermediary manages the asset. We call it "Open to Buy" (OTB): it's an amount (for example, 100 or 200 francs) that the issuer bank authorizes to the client. The micropayment steps are the following:

  • The customer follows a link on a merchant Web server.
  • The wallet contacts the intermediary, which verifies the signatures and the OTB.
  • If all is correct, the intermediary returns an acknowledgement to the wallet.
  • If the OTB is insufficient, the intermediary triggers an SET transaction as a pseudo merchant with the flag NO-CAPTURE to use a standard SET function to obtain an authorization.
  • The intermediary obtains the result of the bank network and if the result is accepted, it stores the amount as a new OTB and clears up the older purchases from the old OTB, subtracts the amount of the payment from the new OTB, and returns an acknowledgment to the wallet.
  • When the wallet receives an acknowledgment, it forwards it for the delivery.

A Web server (http://www.e-comm.fr) is now open to give information about the consortium and the different projects:

For the future, we are planning new evolutions. For the regular payment phase II-a, we will use the protocol that results from the SET and EMV. For the micropayment phase II-b, we will use the French Electronic Purse.

Contents

Introduction

This paper is divided into three parts. We will study some of the main solutions currently used in electronic commerce, point out the weaknesses, and finally explain the solution we have chosen. We will start by analyzing the evolution of electronic commerce and the payment system. Then we will analyze the French experience, and we will end with two French experimentations, and more specifically, the micropayment solution.

Definition

What is a micropayment? There are different definitions of micropayment. But for the purpose of this paper, it will refer to a small amount between 1 F and 50 F, accessible with only one click on the PC and only to online goods. In this range of amounts, it is impossible to carry out a complete bank transaction.

What is a macropayment? This will refer to all payments that are not micropayments, that is, any amount above 50 F and/or goods that cannot be transmitted online. Above 50F, it is possible to do a complete bank transaction in SET or in another mode. In this paper we also refer to macropayment as "regular payment."

The worldwide situation

With the growth of the Internet, the network has evolved from a research network to a commercial one. However, since the Internet is perceived as being an unsecured network, people are afraid to use it for commercial transactions. In the past few years, technological improvements, along with the decreasing price of microcomputers, have put consumers in the mood to purchase a home computer. At the same time, the price of telecommunications has been decreasing and the competitive Internet providers are offering unlimited Internet access to end-users. The new user-friendly Web interface permits inexperienced users to surf worldwide from site to site with only one click. These different elements contribute to the increasing number of people connected to online computers.

With the development of the Web server, the merchant needs to find a way to migrate from a showroom to a commercial online site in order to sell his products over the Net. The problem for the merchant is to convince the customer that the network is secure. The first step is to have the customer fill out a form (with delivery address and payment information). The form below is an example:

Client Identification Billing Information
Last Name & First Name
Phone Number
Address
Zip code
City
State
Country
Last Name & First Name
Phone Number
Address
Zip code
City
State
Country
Invoice Information Payment Information
Subtotal
VAT
Delivery fee
Total
Brand name
PAN
Expiration date

Once the form is filled out and sent back to the merchant, the merchant can deal with the information. He asks the bank to verify the validity of the information, that is, if the card is valid and not stolen. If the customer information is correct, the merchant delivers the goods and settles the transaction:

The messages in a face-to-face purchase

In this scheme, we can see the different movements:

  1. The Client asks to pay for goods.
  2. The Merchant sends a form to the Client to fill out.
  3. The Client provides the information and sends the form back.
  4. The Merchant requests an authorization from the Bank.
  5. The Bank sends its answer back to the Merchant.
  6. The Merchant delivers the goods.
  7. The Merchant settles the transaction.

Some elements of cryptography

To secure the exchange between Merchant and Client, we use a cryptographic tool. There are two kinds of cryptography: symmetric and asymmetric.

Symmetric cryptography

In symmetric cryptography, two users share the same key. For example, when Alice (all examples in cryptography used Alice and Bob) ciphers a message with the symmetric key, only Bob, who also owns the same key, can decrypt the message. The main problem with this kind of cryptography is the fact that Alice and Bob must exchange the key before the transfer can begin. There are many solutions to the problem of how to exchange the symmetric keys; the first one is to use another medium like fax or postal service; the second one is to use the Recipient public key to cipher the symmetric key. Therefore, if you desire to communicate with many people, you must generate and distribute as many new keys as there are message recipients.

Asymmetric cryptography

In asymmetric cryptography, we use a pair of keys: one named secret key and the second one public key. There are two ways to use the asymmetric key depending on what we want to do. The first way is to encrypt the message with the public key of the recipient; the second way is to encrypt the message with the secret key of the sender.

In the first case, let's suppose that Bob decides to cipher his message using Alice's public key. Who can decrypt the message? Only Alice, of course, because she is the sole owner of the secret key. The main problem about the solution is the time needed to cipher the data.

Now in the second case, Alice encrypts the data with her secret key and Bob possesses the public key of Alice, because anyone can know the public key. Everybody can easily verify the message, so we don't use this method to cipher. Rather, we generally use this method to ensure the integrity of the message. We use only a small part of the message (called "hash") and we cipher only the hash which is the result of a mathematical function. When Alice ciphers the hash with her private key, everybody can verify that the received message is the same as the sent message ("integrity").

  • Bob generates the hash of Alice's message (H1).
  • Bob decrypts the received hash with the public key of Alice (H2).
  • Bob verifies the equality of the two hashed parts (H1 = H2).

The other main problem in the asymmetric cryptography is determining the trust we can have in the public key. How can we be sure that the received public key is the real one and not a fake one? We must find a solution so that we can trust public keys and public key directories. There are many solutions, such as always using the same authority certification (like Verisign) or the SET tree.

Cryptography: why and how do we use it?

We use cryptography to keep information, such as payment information, secret. The Merchant and the Client create a cipher channel between them, using, for example, SSL (Secure Socket Layer). The data are encrypted and only the Merchant can read them.

When the Client clicks on a URL (Uniform Resource Locator) to buy some goods, the Merchant sends him a form to fill out in an SSL session. The Client has a private channel and only the Merchant can read the data.

What does the merchant do with the data?

He keeps them in a database for future processing. Currently, there is still a risk that a hacker could get access to financial information like PAN (Personal Account Number) and the Expiration Date. The merchant is obliged to keep the payment information because he has two operations to do: first, he asks for an authorization from the bank and second, he sends the transaction to the clearing system for settlement.

There is also a second risk that an online Merchant is unknown and might be unreliable. Unfortunately, the Client has no way of knowing this.

The law

Another problem is the different national cryptographic laws. The different governments (secret service) want to be able to intercept, decrypt, and control all the data which move on the Net. To do that, the government has to be able to control the length of the key. For example, in France, a new law will authorize the free use of a 56-bit key.

The French experience

In France, we have two important experiences in two technical domains: the first one concerns the smart card or chip card, which has been developed by the banks over the last ten years, and the second one is the French Minitel.

Smart card

In a face-to-face situation, when you use your smart card to purchase goods in an actual shop, you must insert the card in the card reader. The Merchant keys in the amount of the purchase which is displayed on the card reader screen, then the customer enters his PIN code, and the card reader sends the PIN code to the smart card. The PIN code is then verified inside the smart card. If the PIN code is correct, the smart card calculates a special certificate called CAM (Certificate Card Memory). This certificate is a signature with the secret key of the cardholder. The signature proves the purchase, because you must have the card and the PIN code simultaneously to be able to generate this CAM certificate. Only the bank is able to verify the CAM. The signature includes different elements such as the price and the date. The terminal prints a receipt on which we find the following information:

  • Date
  • Merchant Name
  • Price
  • CAM
  • Authorization number if it exists

The terminal point of sale

We have a complementary control during the purchase phase in the following situations:

  • If the amount of the purchase is superior to the Merchant's set limit
  • If the total amount exceeds the Cardholder's 7-day allowed limit
  • In case of a random verification

In the cases above, the terminal of the Merchant (Point of Sale) calls an authorization server to verify that the smart card is not stolen or declared lost. Every evening, the Merchant transfers the daily transactions to the settlement server for clearing. Conclusion: The main advantage of the system is the strong decrease in the fraud rate.

Minitel

The French Minitel has also been an interesting experience. The French users have already tested and used an Internet-like system with France Telecom Operator and Merchants. The Minitel allows the customer to do the following:

  • Access such information as train schedules and train reservations;
  • Access forums;
  • Purchase deliverable goods;
  • Purchase online goods;
  • Take orders;
  • Book hotels; and
  • Access a phone directory.

There are two ways to purchase goods on the Minitel:

The first one is by giving your PAN and Expiration Date and without any cryptographic security element because we consider that the France telecom network is secure enough. Moreover, the Merchant is not unknown because he must be registered by France Telecom. The second way is by means of the telecom billing service. Every two months, France Telecom takes the money and pays the Merchants. For example, when you read a newspaper article on a Minitel, you do not pay the newspaper company directly, but rather France Telecom, who will pay the company, based on the time you used the newspaper service.

There are about 6.5 million Minitels which annually generate 7 billion francs. There are about 25,000 different services, including games, information, news, and forums. Conclusion: The French Minitel is still widely used and generates profits for merchants and France Telecom. But now the terminal is becoming obsolete and we must transfer the Minitel experience to the Internet domain.

The eComm projects

What is eComm?

In July 1976, a consortium (named eComm) was created by a few well-known French banks (Banque National de Paris, Société Générale, et Crédit Lyonnais), Visa International, a card reader and card manufacturer (Gemplus), and France Telecom. Its main goal is to promote electronic commerce by using the international SET (Secure Electronic Transaction) protocol but adapted to the French smart card standard (named B0'). The solution proposed by eComm is an extension of the SET because the Merchant software is a fully compatible SET.

SET

The eComm project for macropayment

SET is a protocol created in 1995 by Visa and MasterCard with the help of GT, IBM, Microsoft, Netscape, RSA, SAIC, Terisa, and Verisign in an effort to find a common protocol for secure electronic commerce. In this protocol, there are three actors: the Client (using a Wallet), the Merchant, and the APG (Acquirer Payment Gateway). The Wallet has two functions. The first is to manage the interface with the customer and to keep track of his purchases. The second is a SET tool kit, which is used for the signature of the SET messages and the management of the certificates. One of the most important things about SET is the creation of a hierarchical trust tree, which permits everybody to verify any SET certificate.

For the eComm Project, which is an extension of SET, the French Client has a special Wallet with a card reader, and the French gateway is also extended to send, if necessary, the CAM to the French banking computers for verification.

The two possible scenarios

If the Merchant and the Client are both French, the Wallet asks the Client to insert his card in the card reader. Then the Wallet asks him to directly key in the PIN code on the card reader which is verified locally in the smart card by the chip. This process keeps the PIN code from moving onto the Net or into the PC. If the PIN code is correct, the chip calculates a CAM which is proof of the purchase. The CAM is transferred to the network in a SET extension protocol. For the Merchant, the operation remains undetected.

If the Merchant is not French, then the Wallet uses the standard protocol SET. If the Client is not French, the Wallet only uses SET protocol, because either there is no card reader or his card has no chip and cannot generate a CAM.

The eComm project for micropayment

The Front Office

In the documentation we often split the study of electronic commerce into two parts. The first one, named Front Office, is in charge of the Internet network and of the messages (between a Client, a Merchant, and a Gateway). The other one, named Back Office, is in charge of all bank processing (messages between the Gateway or intermediary and the bank computers).

The Front Office verifies the different elements of the protocol-like signatures. For the Micropayment eComm Project, we have created a new Front Office protocol named MSET, with M representing micropayment and SET being used because we are reusing the mechanism of SET certificates with its tree of trust.

The Merchant software is composed of two parts: one manages the Merchant's catalog and the other manages the payment process. The payment process is independent of the payment client system; it must be able to generate and understand two kinds of messages:

  • MPOffer message: between Merchant and Wallet for the offer
  • MPAdvice message: between the Wallet and the Merchant for the acknowledgment

The client Wallet implements the SET and MSET protocols: SET messages for the management of the different certificates and for the OTB (see next paragraph) and the MSET protocol for the management of the payment. In the MSET protocol, the Wallet is responsible for the dialogue with the merchant (MPOffer and MPAdvice) and for the dialogue with the Intermediary (MPReq, MPRes).

MSET

The intermediary

The intermediary has two main parts:

The first one concerns the Internet subsystem. In this part we must verify the messages of the protocol, the signatures, and the certificates. The different messages of the scheme above are:

  1. The Merchant makes an offer to the client: MPOffer message
  2. The Client accepts the offer and sends the MPReq message to his Intermediary
  3. The Intermediary answers the Client with the MPRes message
  4. If positive, the Client sends the answer back to the Merchant with the MPAdvice message.

Relation of the intermediary

In this scheme we have not indicated the step before the payment mechanism when the client is "surfing" on the Web server of the Merchant. We have also not indicated the delivery phase when the Merchant receives a valid advice (MPAdvice message).

The second one concerns the bank subsystem. The two main functions are the management of the OTB (see below) and the aggregation technique. The intermediary verifies that the user has an OTB (Open to Buy. An OTB is an authorization to spend money for a fixed amount, which is similar to a purchase in SET system with the flag Capture=NO). The account of the Client is not debited when the authorization is given by the Bank. And at regular periods, the Intermediary generates an aggregated debit transaction per Client and an aggregated credit transaction for the Merchant in the clearing system.

Aggregation M1 M2 Total/Ci
C1 5 5 10
C2 3 15 18
Total/Mi 8 20 28

In this scheme, we can see that the Client C1 has made two micropurchases. One is about 5 francs to the merchant M1 and the second one about 5 francs to the merchant M2. For the Client C2 we have two purchases. One purchase is of 3 francs and the other of 15 francs. At the end of the period, C1 must pay 10 francs; C2, 18 francs. M1 must receive 8 francs and M2, 20 francs. We generate to the clearing system different aggregate transactions:

  • One of about 20 francs to credit the Merchant M2
  • One of about 8 francs to credit the Merchant M1
  • One debit transaction of about 10 francs to the Client C1
  • One debit transaction of about 18 francs to the Client C2

We use the SET hierarchical trust, because it is difficult to have a reliable system for authentication. The Merchant already has a SET certificate from his bank. The Client also has a SET certificate and it is possible to reuse the same system for micropayment. In the hierarchical tree below, we can see the following: the cardholder1 (C1) obtains a certificate from his bank (BANK1); and the cardholder2 (C2) and the merchant1(M1) have the same bank (BANK2). If (C1) wants to verify the certificate of (M1), he must verify the certificate BANK2 before, because we must find a common entity between two end-users (for example, C1 and M1).

Tree

Conclusion

In conclusion we have seen that at first there was no protection, then we have used SSL channel, followed by the SET protocol. In France we extended the SET protocol with smart card B0'. And we decided to build a system for micropayment which is based on SET certificates and uses a post-paid solution.

The main reason to implement a micropayment system concerns the cost of the bank network. To have a viable and low-cost system, we use aggregation and send only important transactions for clearing. The Intermediary uses a post-paid system based on the card system in which we make an authorization to create an OTB and at the end of the period we settle the actual amount spent.

Bibliography: Web addresses

  • SET: http://www.visa.com
  • SSL: http://www.netscape.com
  • Cryptography: http://ww.rsa.com
  • MSET:
  • eComm: http://www

e-mail

philippe.michon@cnet.francetelecom.fr

philippe.michon@wanadoo.fr

[INET'98] [ Up ][Prev][Next]