Electronic Payment Systems on Open Computer Networks: a Survey: Working paper

Book Chapter

Reference

Electronic Payment Systems on Open Computer Networks: a Survey:

Working paper

PILIOURA, Thomais

Abstract

The extraordinary growth of international interconnected computer networks and the pervasive trend of using these networks as a new field for conducting business processes is stimulating the demand for new payment methods. These new methods must attain high levels of security, speed, privacy, decentralisation and internationalisation for electronic commerce to be accepted by both consumers and businesses. This paper surveys the state of the art in payment technologies and sketches emerging developments.

PILIOURA, Thomais. Electronic Payment Systems on Open Computer Networks: a Survey:

Working paper. In: Tsichritzis, Dionysios. Electronic commerce objects = Objets de commerce électronique . Genève : Centre universitaire d'informatique, 1998. p. 197-227

Available at:

http://archive-ouverte.unige.ch/unige:155929

Disclaimer: layout of this document may differ from the published version.

1 / 1

Electronic Payment Systems on Open Computer Networks: A Survey

Working paper Thomi Pilioura

Abstract

The extraordinary growth of international interconnected computer networks and the pervasive trend of using these networks as a new field for conducting business processes is stimulating the demand for new payment methods. These new methods must attain high levels of security, speed, privacy, decentralisation and internationalisation for electronic commerce to be accepted by both consumers and businesses. This paper surveys the state of the art in payment technologies and sketches emerging developments.

1 Introduction

New electronic technologies are combining with an emerging global information economy on the Internet to change the way we do business. In the centre of these developments are electronic payment mechanisms that provide the financial infrastructure needed to open the electronic marketplace. This paper gives an overview of these new payment mechanisms by describing and evaluating some of those that currently exist or are being developed. These reviews and evaluations are necessarily somewhat tentative, because the various systems are at different stages of development and the various companies operate at different levels of public disclosure.

This paper is organised in the following way. In the second section, we propose a classification schema for the different electronic payment systems. For each category we choose a few representative systems to be examined in this paper. In the third section, we propose an evaluation approach. This evaluation approach uses some of the most important parameters associated with a financial transaction including security, privacy and transaction cost. In the fourth section, we use these evaluation parameters in order to give a structured overview of the different systems. The fifth section summarises the evaluation results. We conclude this paper with some general remarks on the future of electronic payment systems.

2 A Classification Schema for electronic payment systems

At this moment in time, there are many different companies trying to position their products as the dominant way to transfer money across the Internet [!] [2] [3]. In this survey we classify the electronic payment systems according to the following schema (illustrated also graphically in Figure 1):

197

=

!.

a. :;

0 El!

8~

1a1?~

e .'t i

fO

~ ;! •-' • I ;.$ • " ' "

-E?.

'~~_;J..) ___ . __ .: - . ~~

Figure 1 The Classification Schema

• Token-based systems: these systems use tokens, objects that are generally agreed to carry value themselves. The value carried by the tokens is conventional, a matter of consensus.

These systems are based on ''prepayment", i.e. drawing on one's bank account in advance to get possession of payment instruments, token money, to be used in later transactions. We have two subcategories of token-based systems:

• Electronic cash: it attempts to replace paper cash as the principal payment vehicle in online payments.

• Electronic purse systems: they are based on smart cards, also called stored value cards, which use integrated circuit chips to store electronic money.

• Notational systems: in these systems the transaction is directly or indirectly tied to value stored elsewhere. The three subcategories that we can distinguish here are:

• Electronic payment orders (debit/credit) transferred over the nets: the transaction is directly tied to value stored elsewhere (usually in a bank account).

These systems are also called ''pay now" systems because they transfer deposit money "immediately'' after the initiation of a payment order. Examples of these systems are debit cards, checks and credit transfers).

• Credit card billing over the nets: the transaction is indirectly tied to value in that when you use it you undertake to become liable for the amount of the transaction.

These systems are also called "pay later'' systems and they are based on consumer credit and/or delayed debiting of the payer's current account. They can be implemented in two ways: encrypted credit cards or third-party authorisation numbers.

T. Pilioura 199

• Encrypted credit cards: in these systems, credit card details are encrypted before they are sent out over open computer networks.

• Third-party authorisation numbers: one solution to security and verification problems during financial transactions is the introduction of a third party to collect and approve payments from one client to another.

• Smart card-based notational systems: these systems use smart card technology to store customer-specific information in an attempt to offer higher levels of protection than software-only notational systems.

We have to note here that some systems may involve both stored value and a deposit balance transfer capability, thus integrating the two categories of payment systems. Finally, we have to stress out that this classification schema brings together two different dimensions of electronic payment systems, namely process and technology. Two lines of technology, smart cards and open computer networks, are being used to develop payment systems where the process of payment is based either on token or notational schemes.

Table I contains the systems we selected for each category to be used in our survey.

ctMilllcatw.il~

.:<: : .. ^{. ..}

Notational systems

Electronic cash

Electronic purse systems

Electronic payment orders transferred over the nets

Credit card billing over the

nets

Encrypted credit cards

Third-party authorisation

numbers Smart-card based notational

svstems

DigiCash Millicent CAPE MONDEX

NetBill

NetCheque

CyberCash

SET

First Virtual

FSTC e-check Table 1 Systems examined in this survey

"~~--~,-

...

Di.1.dCash. Inc.

NatWest, U.K.

Carnegie Mellon University,

Pittsburgh Information

Sciences Institute of the

University of Southern California CyberCash Inc., Reston, VA.USA

VISA, MasterCard First Virtual Holdings, Inc.

FSTCinc.

3 The Evaluation Approach

The evaluation of electronic payment systems is quite difficult, because we experience short of clear and well-defined criteria for the appreciation of the functionality and the quality of such systems.

In the following paragraphs we present the parameters used in this paper for the evaluation of the systems. Some of these parameters are common to both token-based and notational systems and some others are applicable only to one of these categories. In the last case, we specify the category to which the parameter is applicable.

Transaction cost: Conducting a transaction should not be expensive. One should note that the economy of a transaction is a relative property. For example, if a transaction worth [units]IOOO cost the parties concerned [unit]l to administer, that might be economic;

however, if a transaction of [units]S still cost [unit] I to administer, then that would not be economic. This parameter also specifies the ability of a system to be used for rnicropayments.

Micropayments refer to low-value electronic financial transactions, ranging from a fraction of a cent to a few dollars.

Security: Since Internet services are provided today on networks that are relatively open, the infrastructure supporting electronic commerce must be resistant to attacks in an environment where eavesdropping and modification of messages is easy. This means that payment systems require adherence to some fundamental security principles that cryptography greatly enhances. These principles are authentication, payment integrity, double-spending prevention, loss-tolerance and nonrepudiation.

• Authentication is needed to help make sure that persons in a transaction are who they claim to be.

• Message Integrity is needed to ensure that information has not been altered since the data was signed.

• Double-spending prevention is needed to prevent copied coins being spent repeatedly.

This parameter is applicable only to token-based systems.

• Loss-tolerance: if the network fails or the computer crashes during a payment transaction, coins might be lost. In order to solve this problem, a mechanism must be available to recover the value of these lost coins. It's applicable only to token-based systems.

• Nonrepudiation is needed to prevent a signatory of a document from denying the submission, delivery, or integrity of its contents. This parameter is applicable only to notational systems.

Privacy: It is needed to make sure that information is not revealed to unauthorised people.

Cryptography can be used to enhance privacy during digital communi.cations. With this technology, information can be enciphered so that unauthorised personnel cannot understand it. Only with the appropriate key can the information be easily deciphered and understood.

T. Pilioura 201

In the privacy aspect of electronic payment systems we can distinguish three principles:

• Payment confidentiality: payment details including payer, payee, account numbers, amounts, date and time must not become known to electronic observers able to monitor network traffic.

• Payment anonymity: only a payer's pseudonym is known to the payee.

• Payer untraceability: payment system cannot trace payments back to the payer.

Online verification: Electronic payment systems that need the help of a distant computer throughout the transaction are said to be online systems. On the other hand, offline payments involve no contact with a third party during payment - the transaction involves only the payer and payee. Online systems obviously require more communication, but they are also considered more secure than offline systems as they prevent problems of double spending and dishonest transactions. In the offline payment systems, these problems could be solved by secure hardware components such as smart cards.

One problem is that there is no true offline cash that can be traded ad infinitum without a third party acting as a referee. Paper money or gold coins can be traded for years without being deposited in a bank, but this is because they cannot be counterfeited. Digital notes are easy to copy. The cryptographic algorithms can catch counterfeiters, but only when the money is processed through a bank.

This means that even offline cash is still, in a sense, online. It just means that the interaction with the third party, the bank, can take place at a more leisurely pace. So the distinction between online and offline is unclear. It's really a distinction between now and later.

Software-only vs. tamperproof hardware: Some systems are based on special purpose software only and others are using a combination of software and hardware.

Divisibility: it must be possible to interchange multiple low denominations and single high denominations. It only makes sense to ask whether a system supports divisibility if it is a token-based system.

Change-return capability: in some systems the merchant can give change to the buyer. This parameter is applicable only to token-based systems.

Transferability: the recipient of a token can spend that token without having to contact the issuer. This improves anonymity and reduces the amount of network traffic, but complicates the security issues. It only makes sense to ask whether a system supports transferability if it is a token-based system.

Purse-to-purse transfer: some systems support purse-to-purse transactions to better imitate the functions of conventional money. This parameter is valid only to token-based systems.

Status: Some systems are in testing phase and some in commercial use.

In the following section, we give an overview of the functionality and the most important features of each of the systems examined in this paper. This overview helps us

evaluate each system according to the parameters presented in the above paragraphs. A summary of this evaluation is presented in section 5.

4 Description of the systems

4.1 DigiCash

Based in the Netherlands and the U.S.A., the technology provider DigiCash [ 4) co-operates with the American Mark Twain Bank in a pilot of "ecash", a system based on a "software wallet" and "electronic coins" that can be loaded onto one's PC hard disk.

4.1.1 The ecash model

The actors within the system are clients, merchants and ecash banks, as shown in Figure 2.

Clients and merchants have accounts at an ecash bank. The ecash wallet software is called cyberwallet. It stores and manages a client's coins, keeps records of all transactions and makes the protocol appear as transparent as possible to the client.

Stores coins Makes payments Accepts payments

Sells items Makes payments Accepts payments Figure 2 Entities and their functions within the ecash system The flow of interactions in the DigiCash model consists of four parts:

Withdrawing Money

1. The customer's cyberwallet software generates random serial numbers for the ecash coins.

The serial numbers are then blinded. The blinded coins are sent to the ecash bank.

2. The bank checks the signature and debits the signature owner's account.

3. The bank validates the coins and returns them to the customer.

4. The customer unblinds the coins.

Note here that many coins of different denominations, specified by the customer, can be obtained in a single withdrawal request.

Spending Money

1. The customer sends a buying request to the merchant.

T. Pilioura 203

2. The merchant sends a request back to the cyberwallet software to send the money.

3. The customer confirms the transaction and the software transfers the exact number of coins.

Redeeming Money

I. The merchant has to check the validity of the coins. He sends them to the bank that issued the coins to ensure that they have not already been spent.

2. The bank checks the serial number for double spending. If the coins are valid, the bank destroys the coins, adds the number to the database of spent coins and transfers the amount to the merchant's account.

Finishing the Transaction

After the coins have been validated, the merchants send the purchased goods or/and a receipt to the customer and the financial transaction is finished.

A merchant can also make payments to a client using the same procedure. This is useful for making refunds or providing payout services, where a client might receive back a payment as part of the service.

4.1.2 Ecash coins

The electronic coins used within the ecash system are unique in that they are minted by the client before being signed by the bank. Each coin has a serial number that is generated by the client's cyberwallet software. The serial numbers are chosen randomly and are large enough so there is very little chance that anyone else will ever generate the same serial numbers.

The serial number is blinded and sent to the bank to be signed. This is done using the blind signature protocol. The bank is unable to see the serial number on the coin it is signing.

The method can be considered similar to putting the coin and a piece of carbon paper into an envelope. The envelope is sent to the bank where it is signed and returned to the client. The client opens the envelope and takes out the coin (unblinds it). The coin has now been signed.

The carbon paper ensured that the bank's signature went through the envelope. The signature on the unblinded coin appears the same as any other normal digital signature. There is no way to tell from it that the coin was signed using the blind signature protocol.

However, there is a problem with this method. Since the bank cannot see what it is signing, how can a value be assigned to the coin? The value cannot be included with the serial number in the fields of the coin because the bank cannot see this. The client might assign a very high value and tell the bank that it is only a low-valued coin.

The problem can be solved by the bank using a different signature key for each coin denomination. The client informs the bank of the value he wants the blinded coin to be worth.

Then the bank signs the coin with the signature key representing this denomination and deducts that amount from the client's account.

4.1.3 DigiCash features Transaction cost

The low costs of transaction allow using ecash for micropayments.

Authentication

Everyone gets RSA public-key pairs for creating digital signatures for his transactions.

Double-spending prevention

DigiCash supports double-spending prevention. To ensure that a serial number is not spent twice, the minting bank must record every coin that is deposited back to that bank. A very large database of all spent serial numbers soon develops. When a valid coin is accepted, it then becomes spent and its serial number is entered into the database. By using expiry days with coins, the serial numbers can be removed after the expiry date. In this way we reduce the serial numbers that must be kept in the database. The wallet software can automatically ensure that coins are returned to the bank before they expire.

Loss-tolerance

If the network fails or the computer crashes during a payment transaction, coins might be lost. There is, however, a mechanism to recover the value of these lost coins.

Payment confidentiality and message integrity

All communication in the DigiCash system is digitally signed and encrypted through extensive use of both symmetric and asymmetric cryptography.

Payer anonymity

The current DigiCash system includes blinded digital signatures for protecting the anonymity of the buyers. Like the CAFE system, coins can be signed to detect the buyer who double spends. This partial anonymity is cited as a deterrent to the criminal use of the system.

Payer untraceability

In the DigiCash system the sender is able to prove he sent money, however the recipient (or someone later interrogating the system) cannot see who sent the money.

Divisibility

The client informs the bank of the value he wants the blinded coin to be worth. The bank then signs the coin with the signature key representing this denomination. For example, the bank can have a one-cent signature, a five-cent signature, a ten-cent signature and so on.

Change-return capability

The system has no change-return capability. As consequence, the customer must always provide the exact number of coins required for the purchase. This is done because accepting change could compromise the user's anonymity (the merchant could record the serial numbers of the change and collude with the bank to reveal the user's identity). The cyberwallet will automatically assemble the correct amount and can withdraw new coins from the bank if more denominations are required.

Purse-to-purse transfer

Purse-to-purse transfer of ecash is possible, although the amount transferred still has to be forwarded to the bank for verification. The coins are forwarded through the payee to the bank where they are deposited. New coins worth the same amount are then returned to the payee.

T Pilioura 205 This is all done transparently by the software so that it appears that the new coins were received directly from the payer. Currently, as with merchant payments, both users must have accounts at the same ecash bank in order to perform a purse-to-purse transfer.

Status

There is already an existing software system for the use of ecash and several banks issuing ecash in their national currencies, such as the Mark Twain Bank (USA), Eunet (Finland), Deutsche Bank (Germany) and St. George Bank (Australia).

4.2 Millicent

Millicent [5][6] is aimed at the micropayment portion of Internet commerce, where transactions could involve fractions of a cent and are made very quickly. Given these constraints, micropayment techniques must be both inexpensive and fast. Achieving both requires certain compromises, such as relatively lightweight security.

4.2.1 Scrips

The Millicent system uses scrips, a form of tokens that are only valid with a particular vendor for a limited period of time, and brokers, who act as intermediaries between vendors and customers. In order to avoid customers having to maintain separate accounts with individual vendors, with whom they may only have a very short relationship, brokers act as intermediaries. The long-term relationships are between the brokers and the customers, and the brokers and the vendors, rather than directly between the customer and the vendor.

A scrip can be considered as an "account" between the customer and the merchant which is set up, used and closed. The scrip contains a value and when a customer makes a purchase with it, the amount of the sale is deducted from the scrip's value and the scrip is sent back to the customer as change. A scrip cannot be spent more than once, can only be spent by its initial owner and at a specific merchant, has an expiration time (the date on which the scrip becomes invalid, used to limit the scrips'IDs that must be remembered by a vendor to prevent double spending) and can be regenerated upon expiration.

4.2.2 The Millicent model

The basic sequence of interactions in the Millicent model is as follows (Figure 3):

I. The customer buys a quantity of broker scrips using one of the macropayment schemes.

2. When a customer first encounters a new vendor, he must buy vendor scrip from the broker to spend at the vendor's site. Therefore, he places a request for vendor scrip to the broker.

3. The broker obtains the required vendor scrip from the vendor.

4. The broker sells the vendor scrip to the customer. For example, the customer can buy 20 cents of vendor scrip using the $5 ofbroker scrip purchased earlier (step 1). Both the new vendor scrip and the change in broker scrip are returned to the customer.

5. The vendor scrip is sent to the merchant with a purchase request.

6. The vendor gives change in vendor scrip along with the purcha~ed content.

Steps 1 and 3 need not happen at every transaction - the customer would purchase sufficient scrip from his broker to meet his needs for a period of time; similarly the broker would have enough vendor scrip to service a number of customer requests, or would have a licence from the vendor to mint the specific vendor scrip directly. Although there would seem to be a lot of traffic in this protocol, there is no bottleneck connection to a single currency issuer for each transaction; especially once steps 1 and 3 are factored out.

Customers buy

"vendor scrip"

from Broker

I

l

chunks of"vendor scrip" for licensed vendor

~

4.2.3 Millicent features Security and privacy

Customers buy information with "vendor scrip"

Figure 3 The Millicent model

( vendOTJ

Al.ready spent scrip refused

Millicent protocols offers various levels of security and privacy (Table 2). Namely, scrip in the clear offers no security and no privacy. Here the scrip is transferred back and forth between customer and vendor without any encryption or protection. This would allow someone eavesdropping the connection to take a copy of the scrip returned as change and spend it himself. The private and secure protocol uses a shared secret key between the two parties to establish a secure communication channel (encrypt both the scrip and the purchase request). And the secure without encryption protocol does the same without the privacy aspect in order to achieve better performance.

• Double-spending prevention

In all the Millicent protocols double spending will be detected locally by the vendor at the time of purchase.

• Payer anonymity

Although the Millicent protocol does include a field in the scrip to carry customer information, this field is not always used. The Millicent group suggests that a good use of this field would be to carry age and residence information for taxation purposes and any information needed for discounts, such as student status. However, some limited anonymity could be maintained by buying broker scrip using an anonymous macropayment system.

• Payer untraceability

A scrip has visible serial numbers that could be recorded and traced.

T. Pilioura 207 Online verification

The Millicent system is offline to the extent that no connection to a central server is required.

The fact that any particular type of scrip is only valid at a particular vendor means that the vendor does not need to connect to a separate issuer to validate the token, thereby reducing network traffic and eliminating attendant cost of such a validation.

Divisibility

Scrip can represent any denomination of currency. Expected values range from one-tenth of a cent up to about $5, although there is no defined upper or lower bound limits.

4.3 CAFE

Private and secure Secure without

Encrvntion 2

Yes Yes Table 2 Characteristics of the three Millicent protocols

Yes No

CAFE [7] is a cash scheme with guarantees of anonymity for the users. It involves an electronic wallet to be used as a pan-European mechanism for consumer payments, access to information services and - if required - identification.

There are two kinds of tamper resistant secure electronic devices used in the CAFE system: smart cards and wallets. These devices are used to store electronic money, perform cryptographic operations and to make payments to merchants.

Smart card: this is the simplest of the devices used in the protocol. It is similar to a credit card and has an embedded microprocessor powered by an external source. All information is stored on the chip, which also performs the cryptographic computations.

Wallet: a wallet consists of two parts that work in conjunction with each other. One part is known as an observer and protects the bank's interests and the other is known as the purse and protects the user's interests.

CAFE also supports contactless transactions via infrared wallets.

4.3.1 The CAFE model

Withdrawal: a payer usually only needs to communicate with the bank through a withdrawal session, which results in a number of blank electronic payment slips being loaded into his smart card. The bank keeps track of the balance in the card by means of a counter in the observer part of the smart card. The balance is updated during a withdrawal request and the corresponding amount is deducted from the user's bank account. A withdrawal session consists of the following steps:

1. The user's smart card sends the identity of his bank and information about his bank's public key certificate to the terminal. This allows the terminal to connect to the correct bank and verify/update the bank's public key certificate stored in the smart card.

2. The card and the bank then mutually authenticate each other through the tenninal.

3. The user generates a payment slip and forwards the hash of it to the bank. The bank creates a digital signature on the forwarded hash and sends the result to the user's card.

The user needs to only store the bank's signature on the card as all the other values that a payment slip must consist of (such as one-time public keys) can be regenerated by the user's card at the step 2 of the payment stage.

Payment: the payment transaction consists of the user filling in an amount in a blank payment slip together with the name of the payee, signed with the user's secret key. The steps involved in a payment transaction are as follows (Figure 4):

1. A customer inserts his card into a merchant's payment terminal. The terminal tells the card the identity of the payee, the date and the amount to be deducted from the counter in the observer part of the smart card.

2. The card regenerates the next payment slip to be used. This consists of generating the cryptographic keys.

3. The card sends the blank payment slip to the merchant, consisting of the bank's signature and the public keys needed to use the slip. The payment slip is marked as being spent by the card even though the payment has not been completed yet.

4. The terminal verifies the signature of the bank on the payment slip.

5. The information given by the terminal in the first step is encoded by the card into the payment slip (M).

6. When the payment has been finalised, the terminal sends an acknowledgement to the card, which then updates its counters.

[I] Insert card [2] Regenerate Payslip [3] Send Blank Payslip

[ 5] Signed Payslip (M) [ 6) Verify & ACK

[4] Verify Bank's Signature

Mercbaul

Figure 4 The CAFE flow of interactions for the payment phase

Deposit: on accepting a payment slip, the payee forwards it to the acquirer (at a later date) who in tum clears it through the existing financial clearing system. The acquirer:

1. Verifies the contents of the payment slip and validates the bank's signature.

2. Verifies that the payment slip has not been deposited previously.

3. Looks in its database to verify that the corresponding part of the payment slip has not been spent previously.

If the first two conditions are fulfilled, the payee is entitled to be credited for the amount of the payment. A payee is responsible for checking all received payment slips against his local

T. Pilioura 209 copies of the blacklist (database containing the IDs of the spent payment slips) during the payment phase. If a blacklisted slip is detected, the payee aborts the transaction. If a payee fails to check received payment slips against the blacklist, then he will have to accept responsibility for them as the clearing centre will reject them. When the clearing centre detects double spending, the payment slip will immediately be added to the blacklist.

4.3.2 CAFE features Authentication

CAFE wallets can be configured to be used with a PIN. In this case the buyer is assumed to always be the legitimate user of the device.

During the withdrawal phase, the card and the bank mutually authenticate each other through the terminal. Similar authentication procedures take place between the payer and the payee as well as between the payee and the bank during the payment and the deposit phases respectively.

Message integrity

The observer part of the smart card ensures the correctness of all transactions performed by the user. A user will not be able to successfully complete a payment transaction without the co-operation of the observer.

Double-spending prevention

Protection against double spending is only guaranteed as long as the tamper resistance is not compromised. As far as this is true CAFE offers two levels of double spending detection.

First, a payee is responsible for checking all received payment slips for double spending. If he fails to do it, then CAFE has a cryptographic fallback mechanism that allows the financial institutions to detect double spending of electronic currency (after it has been spent) and blacklist the corresponding payment slips. The banks distribute these lists to all the merchants in the system. This detection is achieved at a cost of maintaining a database of recently spent payment slips by the financial institutions.

Loss-tolerance

If a user loses his wallet, the bank can recover the money from a backup and the deposit transcripts. This is done by regular backups during a withdrawal transaction. If a user wants to recover lost money, he reveals the identity of the payment slips stored after the last withdrawal. This enables the bank to track these payment slips.

Payment confidentiality

The purse will blind/neutralise any communications that may disclose secret information about the user to the outside world. Furthermore, all communications between the wallet and the outside world are done exclusively through the purse, guaranteeing that the observer cannot divulge any secret information to the bank without the user's knowledge.

Payer anonymity

The wallet endorses each payment by giving it a cryptographic signature. As a fall-back mechanism, the money that the wallet uses is in an encrypted format where the identity of the payer is encoded into the coin's number. This is done in such a way that the payer's identity can only be recovered if the coin is double spent.

Payer untraceability

Under normal circumstances, payments cannot be linked to a user even if there is collaboration between the merchants and the banks.

Online verification

The system is capable of performing oftline transactions, thus eliminating the need to connect to central servers. Note that the transactions are only oftline during purchasing, withdrawals of electronic money into the wallet are, of necessity, online transactions. Also it may be decided that payments over a certain threshold must be confirmed online.

Divisibility

The signed payslip (step 5 in Figure 4) can represent any denomination of currency according to the information that the merchant's terminal passes to the card (step 1 in the same figure).

Change-return capability

The merchant's terminal tells the card the amount that it has to pay and then this information is encoded by the card into a payment slip (step 4 in Figure 4). So the payer pays the exact amount required for the purchase, which means that change return capability does not hold for this system.

Multiple currencies

The CAFE wallets have several pockets for different currencies. Like cash, the users may either exchange currency at the bank (lowering the amount in one pocket and increasing in another) or pay in nonlocal currency if the merchant accepts it.

Transferability

The device receives its coins by withdrawing them from a bank account via an Automated Teller Machine (ATM). It is thus "prepaid" and the coins in the machine do not exist as currency anywhere else. When the user spends money the device transmits one or more coins to the seller's device and marks them as spent within the device. The seller now has the value of these coins. However, they must be deposited with an issuer for that value to be realised.

Thus, the primary flow in the CAFE system is that of withdraw-pay-deposit and the individual coins do not remain in circulation in the same way that real cash tokens do. Thus, transferability does not hold for this system.

Status

The CAFE project was completed on February 1996. The first prototypes of the electronic wallets are available and in a trial stage.

4.4 Mondex

The concept of the Mondex [8] card was developed at NatWest, a major U.K. banking organisation, in 1990. The technology was developed with a number of manufacturers involved in the production of secure hardware, including Hitachi Corporation. In July 1996, a separate company, Mondex International was formed to promote the technology through a series of trials in many different locations around the world.

T. Pilioura 211

4.4.1 The Mondex model

The card is initially loaded by contacting a bank using either a Mondex Automated Teller Machine (ATM) or using a specially adapted telephone. These access devices do not need to know how the chip-to-chip protocol works, but rather they incorporate an Interface Device (IFD) that contains a control processor that mediates in the dialogue between the card and the bank. At the bank, a form of money safe called a Mondex Value Box is installed. This is a hardware device that can hold large numbers ofMondex cards and acts as a store of value for dialogues with the issued card population. Transfers to and from the Value Box are monitored by a software system referred to as the Value Control and Management System, and the movements will then be reflected in the bank accounts of the cardholders.

Figure 5 shows this process taking place. A Mondex card is inserted into an ATM (or adapted telephone) whereupon chip-to-chip dialogues take place between the IFD and the card under the control of the ATM device. The Mondex IFD then establishes a dialogue with the bank. Once the cardholder's account number has been established, and the card identity verified, value is transferred from the cards in the bank's Value Box by chip-to-chip protocol to the destination chip residing in the card. The Value Control and Management System will inform the bank's accounting systems to debit the cardholder's bank account for the amount.

Bank's Accounting Systems

Value Control &

Management Sys1em

I

I

•••

ATM

~­Mondex CFO

Figure 5 Loading a Mondex card with value

Spending is a similar process, where retailers are equipped with a device called a Value Transfer Terminal. Once again, this contains an IFD device that facilitates the transfer from the customer card to the retailer card. There is no need for an online dialogue with the bank to verify the transfer. At a later stage, the retailer may contact the bank, transfer the value to the bank's Value Box, and simultaneously have the amount credited to his account.

The Mondex Internet transaction runs as follows:

1. On completion of his selection of products and confirmation of this to the vendor, the client will be asked to insert his Mondex card into a card reader attached to his computer.

2. On confirmation that another valid device exists at the other end of the link, value is transferred from the client's card to the vendor's card.

3. The customer receives the information (graphic, text, sound clip or video) that he ordered.

Physical goods can also be ordered and paid in the same way.

4.4.~ Mondex features Authentication

The security scheme relies on a digital signature, which is generated by the chip on the card.

This digital signature can only be recognised by other Mondex enabled participants in a transaction.

Message integrity

Because Mondex employs state of the art hardware technology, which would need to be duplicated in any attempt for forgery, it is assumed that such fraud would be uneconomical.

Further, Mondex plans to issue regular and "sporadic" upgrades to the chip, so that any successful forgery would rapidly be rendered obsolete. In addition, Mondex plans to use transaction sampling to maintain a picture of the flow of value, and use this to identify fraudulent and illegal use of Mondex value at an early stage. Clearly, for this to be possible, the Mondex system cannot be anonymous.

Furthermore, Mondex chips have been designed to withstand normal extremes of cold and heat, damp, X-rays or electric interference.

Double-spending prevention

In each Mondex transaction messages passed between cards include data that are wholly unique for all time and cannot be repeated. This feature prevents a potential fraudster from using any given message to "repeat" a transaction and send a single $5 to two different people.

Loss-tolerance

If the card is lost, the value stored in it cannot be recovered. However, Mondex allows cardholders to lock value in their cards, preventing other people from spending the money on the card. This facility enables banks to operate a return and reward system to support the return of cards to their rightful owners (where capable of being identified), something which never can happen with the lost ten pound or hundred francs.

Payer anonymity and untraceability

The card maintains a purse narrative that remembers the last 10 transactions in which the card took part and the retailer's hardware keeps record of the last 300 transactions. This limits the anonymity and augments the traceability of the system.

Software and hardware

The system uses special purpose hardware on smart cards to ensure its cryptographic security.

This is the case even in the proposed Internet transactions. In those cases there is simply a Mondex compatible card reader interface attached to the computer. When a transaction is required, the computer talks to the card through this interface.

Multiple currencies

Mondex is a multicurrency purse capable of handling different currencies simultaneously (up to five).

Transferability

Mondex is the only system that enables offline transferability: the payee can use the amount received to make a new payment himself, without having to go to the bank in between.

T. Pilioura 213 Purse-to-purse transfer

Mondex enables purse-to-purse payments. Using a Mondex Wallet, two cardholders can transfer cash between their cards. With a Mondex Telephone, purse-to-purse payments can be made across the world.

Status

The Mondex project is at a much more developed stage than CAFE including manufacturers making and selling the necessary equipment to engage in Mondex transactions, and a number of successful pilot schemes.

4.5 NetBill

NetBill [9][10] implements a check-like debit payment model. It is a payment system which uses a mixture of symmetric key and key pair cryptography. It is aimed at payment for information-based goods such as library services and journal papers. The NetBill system itself charges for transactions, and requires the user to have a pre-funded NetBill account from which all payments will be made.

4.5.1 The NetBill model

The participants in the system consist of customers, merchants and a NetBill server that maintains accounts for both customers and merchants. These accounts can be linked to conventional accounts in financial institutions. When a customer purchases goods his NetBill account is debited by the value of the goods and the merchant's account is credited by the same amount. A customer's NetBill account can be replenished by transferring funds from his bank. Similarly, funds in a merchant's NetBill account are deposited into the merchant's bank account. NetBill guarantees that a customer pays for only the goods that he successfully receives.

NetBill provides transaction support through libraries integrated with different client- server pairs. The client library is called the checkbook and the server library is called the till.

The checkbook and till libraries in turn communicate with the client and merchant applications, respectively.

The basic protocol is outlined as follows (Figure 6):

1. The consumer and merchant authenticate each other and establish a symmetric session key to protect the privacy of subsequent messages.

2. The consumer requests a price offer for the desired item. At this stage a bid for the item can also be included as well as personal information (such as student ID and frequent buyer ID) in order to qualify for special prices.

3. The merchant replies with a price quote.

4. If the customer accepts the price quoted, he instructs the checkbook to send a purchase request to the merchant's till. Alternatively, the customer may configure his checkbook to send a purchase request automatically ifthe price is below a specified amount.

[ l] Authentication phase [2] Request for quotation

[3] Quotation [ 4] Purchase request

8

Encryp~dgoods

[6] Signed EPO [9] Key to unwrap goods

Account

fund~

I ^Co~=er's I

Settlement system Figure 6 The NetBill transaction protocol

()

Merchant's bank

5. The till, on rece1vmg the purchase request, fetches the goods from the merchant's application. It encrypts them with a one-time key and computes a cryptographic checksum on the result. The till then forwards the result to the customer's checkbook but the decryption key will only be sent after completion of the payment.

6. The checkbook, on receiving the encrypted message, verifies the checksum by applying the secure hash algorithm (SHA) to the goods and checking that it matches that computed by the merchant. This gives the checkbook confidence that it has received the requested goods intact. Note at this point that the customer cannot decrypt the goods; neither has the customer been charged for them. The checkbook returns a signed (with the customer's private key) electronic payment order (EPO) to the merchant's till. The EPO consists of two sections, the first of which contains details about the transaction and is readable by both the merchant and the NetBill server. The second part contains payment instructions (such as the customer account number) and can only be read by the NetBill server. At any time before the signed EPO is submitted, a customer may abort the transaction without danger of the transaction being completed without his will. The submission of a signed EPO marks the « point of no return » for the customer.

7. Upon receiving the EPO, the till verifies all its contents, appends the key for decrypting the goods, endorses the EPO with a digital signature and forwards the endorsed EPO to the NetBill server. The endorsement process involves concatenating the merchant's account number, a memo field and the key used to encrypt the goods and then signing the result with the merchant's private key.

T. Pilioura 215 8. The NetBill server verifies that the price, checksums, and so forth are in order and debits

the customer's account for the appropriate amount. It logs the transaction and saves a copy of the one-time key. It returns to the merchant a digitally signed message containing an approval or failure message. The NetBill server includes some account status information with the receipt. If there is not enough money in the consumer's account, the transaction will be rejected and the key never delivered, preventing the consumer from using information that has not paid for.

9. The merchant's application unwraps the receipt, keeps a copy and re-encrypts it using the session key he shares with the customer (established during the authentication phase).

Then the merchant forwards the receipt to the customer's checkbook. In the unlikely event that the merchant or client machine goes down after the consumer has been charged but before the key is delivered, the consumer can request a copy of the receipt - which contains the key- from the NetBill server.

4.5.1 NetBill features Transaction cost

The transaction cost can be considered as medium due to the requirement for extensive network traffic during the transaction.

Authentication and payment confidentiality

In the course of a NetBill transaction, the parties involved identify themselves. The scheme used in NetBill is a modified version of the Kerberos scheme called Public Key Kerberos. In NetBill, before a transaction occurs, the customer contacts directly the merchant (and not a special-purpose server as in Kerberos scheme) and establishes a ticket for the communication between the customer and the merchant as well as an encryption key that will be used to secure the subsequent dialogs with the merchant. Similarly, the merchant server will establish a ticket and an encryption key for the communication between the merchant and the NetBill server and the customer will maintain a ticket and an encryption key for the communication (via the merchant) with the NetBill server. The period of validity of the ticket is configurable, but would potentially span many transactions.

Message integrity

All network communication between the customer and the merchant is encrypted to protect against adversaries.

Nonrepudiation

There are many variations within NetBill some of them allow disputes of all kinds to be settled.

Anonymity

The system also allows for easy use of pseudonyms for anonymity but in any case, the NetBill server knows both parties' identity and transaction amounts.

Status

The system is currently in its Alpha Trial at Carnegie Mellon campus and uses fake money.

4.6 NetCheque

NetCheque [11] and NetCash are developed at the Information Sciences Institute at the University of Southern California. NetCheque is a distributed accounting service supporting the credit-debit model and consisting of a hierarchy of NetCheque servers (banks) that are used to clear checks and settle interbank accounts. This hierarchy allows for scalability of the system. It also allows users to select the bank of their choice based upon criteria such as trust, proximity, reliability and so forth.

As a distributed accounting service, properly signed and endorsed cheques are exchanged between banks to settle accounts through a hierarchy, as shown in Figure 7. In addition to improving scalability and acceptability, clearing between servers allows organisations to set up accounts in their own in-house accounting servers with accounts corresponding to budget lines. Authorised signers write cheques against these accounts, while the organisation maintains a single account with an outside bank, integrating its own internal accounting system with the external financial system.

Merchant

Figure 7 Hierarchy of NetCheque servers 4.6.1 The NetCheque model

Customer

A NetCheque account is similar to a conventional bank account against which account holders can write electronic checks. An electronic check is like a conventional paper check in that it contains the customer's signature. Unlike a paper check, it has to also be endorsed by the merchant before the check is paid.

A NetCheque consists of the following fields: amount of the check, unit of currency, date, account number, payee(s), signature of the customer and the endorsement(s) by the merchant and the bank(s). The last two fields are verifiable by the bank against which the check was drawn.

To write a cheque, a user generates the cleartext portion of the check, specifying an account against which the cheque is to be drawn, the payee, the amount, and the currency unit. Defaults for the account and currency unit are read from the user's chequebook file.

Then, the user obtains a ticket form a Kerberos server that is used to authenticate him to his bank (B) and allows him to share a session key with the bank. He then generates a checksum on the contents of the cheque and places it in an authenticator. He encrypts the authenticator with the session key that he shares with his bank and appends the ticket and the authenticator to the cheque.

T. Pilioura 217 The deposit cheque function reads the cleartext part of the cheque, obtains a Kerberos ticket to be used with the payer's bank, generates an authenticator endorsing the cheque in the name of the payee for deposit only into the payee's account, and appends the endorsement and the ticket to the cheque. An encrypted connection is opened to the payee's bank (A) and the endorsed cheque is deposited. If the payee and the payer both use the same bank, the response will indicate whether the cheque is cleared.

If different banks are used, then the merchant's bank sends an indication to the merchant that the cheque has been for collection. The payee has the option of requesting that the cheque be cleared in real time, though we expect there may be a charge for this service, or batch processed by the banks. If the cheque has to be cleared through multiple banks, each bank attaches its own endorsement to the check, similar to the endorsement attached by the merchant. Once the check has been cleared by the customer's bank, the attached endorsements can be used to trace back the path to the merchant's account and eventually credit his account.

In some cases the payee and payer's accounting servers can settle the check directly, bypassing higher levels of the hierarchy. This is possible when the cheque is drawn on an accounting server that is trusted to properly settle accounts.

4.6.2 NetCheque features Transaction cost

This is pretty much the same as for a paper cheque except that it is assumed that the system is sufficiently economic to handle micropayments.

Authentication

In the NetCheque system, the Kerberos scheme is used to build authenticity. This doesn't use public keys for the certificates, but it has the same effect. The central Kerberos server must be online to generate a transaction key that is used between the two parties. This certifies them to each other because Kerberos sends the transaction key to each party encrypted with a different key known only to that party.

Nonrepudiation and Payer Traceability

Trust in this system emerges from a central server that can track all transactions.

Payment confidentiality

The first five fields of the check (presented in the section 4.6. I) are in cleartext and are readable by the bearer of the check.

Payer anonymity

Though NetCheque does not itself provide anonymity it may be used to facilitate the flow of funds between other services that do provide anonymity.

Online

NetCheque requires a Kerberos system to provide authenticity and this requires a central Kerberos server that generates Kerberos tickets. These Kerberos tickets are valid for a short period of time and this limits the amount of offline behaviour that is possible.

4. 7 CyberCash

CyberCash Inc., Reston, VA provides consumer software, merchant software and a gateway to support the secure communication of credit card transactions over the Internet. Customers are given CyberCash Wallets. Merchants use the Secure Merchant Payment System (SMPS).

The CyberCash Gateway Servers are operated by CyberCash and in the future by banks. The system relies on the use of existing financial networks that are totally independent of the Internet for communicating between the CyberCash Gateway Server and the banks or credit institutions.

4.7.1 The CyberCash model

A CyberCash [12] transaction can be described in nine steps (Figure 8):

1. The consumer requests the item desired by selecting it with a Web browser.

2. The merchant's server sends the wallet software a cleartext signed payment-request message that describes the purchase and indicates which credit cards the merchant accepts.

3. The wallet software thereupon displays a window that lets the consumer select which credit card to use, and approve the purchase and the amount. Then a credit card payment message, including a signed and encrypted description of the transaction, along with the consumer's credit card number is sent back to the merchant.

4. The merchant forwards the payment message, along with the merchant's own signed and encrypted description of the transaction, to the CyberCash gateway.

5. There, CyberCash decrypts and compares the two messages and their signatures. If they match, it submits a conventional authorisation request to the merchant's bank.

6. The merchant's bank then forwards the transaction to the customer's bank that sends an approval or denial back to the vendor's bank.

7. That response is then sent back to the CyberCash server.

(3] Credit card payment

[6) Settlement &cquUer bank Figure 8 The CyberCash Transaction Model

T. Pi/ioura 219

8. CyberCash then sends the approval or denial response back to the vendor.

9. In the case of approval the merchant's software confirms the purchase to the conswner's wallet software (credit card response).

Steps 1,2,3 and 9 take place on the Internet and involve a combination of public key and symmetric key cryptography. Steps 4, 5, 7 and 8 take place over dedicated lines. Step 6 takes place on the existing financial networks. CyberCash claim a complete transaction time of 15- 20 seconds.

4.7.2 CyberCash features Transaction cost

The system is not economic for micropayrnents because of the use of credit cards as the grounding financial instrwnent.

Authentication and nonrepudiation

The system uses 56 bit DES private-key to encrypt all the messages between wallets, merchants and CyberCash Gateway servers. The DES key, which is unique for each transaction, is then encrypted using RSA public key technology. Finally, a digital signature is appended for source authentication and nonrepudiation purposes.

Message integrity

The credit card information and the details of the purchase are encrypted for message integrity purposes. The greater the nwnber of bits used by the encryption algorithm, the more difficult it is to unscramble or crack the message.

Payment confidentiality

In the second step of a CyberCash transaction presented in section 4.7.l the merchant's software sends the wallet software a cleartext signed payment request message with the purchase details. This means that an observer can see the item purchased and the amount of the purchase.

For the rest of the transaction, since the information is encrypted under CyberCash's public key, the merchant does not actually see the conswner's credit card number - a procedure that in theory cuts the risk that customer credit card numbers will be abused. In practice, so many catalogue companies organise their customer marketing records by credit card numbers that an acquirer usually authorises CyberCash to provide them to merchants on request.

Software-only

CyberCash uses a special-purpose software, which, like a physical wallet, can be used by the consumer to register several credit cards.

4.8 SET

SET [13] [14] was developed by VISA and MasterCard, with participation from leading technology companies, including Microsoft, IBM, Netscape, SAIC, GTE, RSA, Terisa Systems and VeriSign. SET is a standard for safeguarding credit card purchases made over open networks.

1.1 J Request transaction

.. .

-

~ [2] Acknowledge request

~

Consumer

- -

damj -

-

^..

&rue; .. ~ [6] Verifv customer data

:j,1 ' J9) Request payment

• r.

-

The operation of the SET protocol relies on a sequence of messages (Figure 9). In the first two, the consumer and merchant signal their intention to do business and then exchange certificates and establish a transaction ID number. In the third step, the consumer purchase request contains a signed hash of the goods and services order, which is negotiated outside the protocol. This request is accompanied by the consumer's credit card information, encrypted so that only the merchant's acquiring bank can read it. At this point, the merchant can acknowledge the order to the customer, seeking authorisation by the bank later (steps 5 and 6) or perform steps 5 and 6 first and acknowledge the order later. Steps 7 and 8 give the consumer a query capability, while the merchant uses steps 9 and 10 to submit authorisations for capture and settlement.

4.8.2 SET features Transaction ^co.~t

Each purchase request transaction requires the exchange of a lot of messages between the customer and the trader and between the trader and the payment gateway and clearly this is not going to be economical for micropayments.

Authentication

By using a combination of RSA public key and DES symmetric key cryptography systems, along with a "trust hierarchy" of digital certificates SET aims to authenticate the identities of the parties involved in the transaction to each other.

Nonrepudiation

SET is signature based which provides potential dispute handling.

Payment confidentiality

In the SET protocol the bank card company gets involved in the middle of the transaction, essentially acting as a middleman. Theoretically, when the customer enters his card number in an online SET transaction, the commerce site might never see the customer's actual credit card number. Instead, that information would go to the financial institution, which would verify the card and the amount and then make the payment to the commerce site.

T Pilioura 221 Anonymity

The seller's knowledge of the buyer is only partial, as the account details are encrypted and are only visible to the payment gateway.

Status

The first live SET transaction was performed in Denmark on the last day of 1996 in an IBM pilot scheme. SET is still in testing status and the first applications based on SET are expected to appear by the end of 1998. It is expected that this protocol will supplant other schemes, and become a standard for all network transactions involving credit cards in the near future.

4.9 FirstVirtual

One of the earliest credit card-based payment systems launched for the Internet was the product of a company called First Virtual Holdings, Inc. based at San Diego.

4.9.1 The FirstVirtual model

Consumers and vendors establish an account with FirstVirtual [12] and fax or telephone their credit card numbers to it. Each account is assigned a Virtua!PIN, which is then used to identify the consumers and the vendors during transactions. The transaction sequence runs as follows (Figure 10):

1. Initially, the buyer browses the FirstVirtual Web server or another Web server where a FirstVirtual merchant is selling goods. The buyer selects the item he wishes to purchase.

The buyer is asked to enter his Virtua!PIN, which is forwarded to the merchant.

2. The vendor emails the buyer's Virtua!PIN, his own VirtualPIN and a description of the purchase to FirstVirtual.

3. If the VirtualPIN is valid, FirstVirtual informs the merchant that he can continue the transaction.

4. Then the information goods are sent directly to the customers.

5. The merchant forwards information about the transaction to the FirstVirtual Internet Payment System Server.

6. First Virtual automatically sends an email to the buyer asking if he is willing to pay for the information.

7. The buyer sends confirmation to FirstVirtual by return mail indicating "accept'', "reject"

or "fraud".

• Accept, in which case the payment proceeds; FirstVirtual submits the consumer's credit card number through its acquirer, and the consumer's card is charged. After holding the funds for 90 days, the company transfers them to the merchant by means of an automated clearinghouse.

• Reject, indicating that the goods either were not received or that the buyer is not satisfied to pay for them;

• Fraud, which means that these goods were not ordered by the buyer. Upon receipt of this message, the FirstVirtual server will immediately blacklist the VirtualPIN, so that the fraudulent use of this VirtualPIN cannot be continued.

[2] Account ID Account OK!

Transaction Details

Figure 10 Buying with FirstVirtual 4.9.I FirstVirtual features

Authentication

First Virtual guarantees to the merchant the validity of the customer's credit card and to the customer that the merchant actually exists since both the merchant and the customer have to be registered with FirstVirtual and are therefore identifiable. But on the other hand, no encryption means no digital certificates, which allows us to say that the authentication control of this system is only partial. For example, a stolen credit card number could be used to set up VirtualPINs associated with e-mail addresses controlled by the attacker, which may allow long periods where bogus transactions can be carried out.

Message integrity

First Virtual uses no encryption and relies upon the security of electronic mail system to keep

trnn~~ctions correct and accurate.

It is quite clear that if a VirtualPIN becomes compromised by attackers eavesdropping on network traffic, bogus purchases can be made from the moment of the compromise until the time the VirtualPIN is blacklisted. Since payment authorisation requests are sent to the buyer by e-mail, this time period could range from a few minutes to perhaps a day or so.

Denial of service or masquerade attacks on the e-mail system could prolong this period significantly.

Experience with the first years of operation of the system has shown a very low fraud rate. The First Virtual system is based on what they call the Green Commerce model. This means that the risk of non-payments is carried by the vendor, although the risk of non- payment is minimised.

The company delays payment to merchants for 90 days, so that consumers have plenty of time to discover fraudulent charges on their credit card statements, in which case FirstVirtual can reimburse the credit card with the funds it is holding.

In summary, we can say that the system is not entirely fraudproof, but in the context of its target market this is not of such great importance.