11-07-2012, 10:36 AM
Basic Security of the ecash Payment System
Basic Security of the ecash Payment System.pdf (Size: 225.81 KB / Downloads: 105)
1 Introduction
Behind the scenes banks, credit-card companies, and other financial institutions
have been processing transactions electronically for several decades now. Two
important developments that will open up the field of electronic payment systems
are now taking place. First, the prospect of electronic commerce over the
Internet is creating a large demand for electronic payment methods for open
networks. Second, the introduction of nation-wide electronic purse schemes is
creating many more places and situations where smart cards can be used for
cost-effective off-line payments.
In this paper we will describe several aspects of the ecash system, mostly
security related, and discuss its place among other payment technologies. Ecash
finds its roots in the work by Chaum (see, e.g., [Cha83,Cha90]), who invented
the notion of electronic (or digital) coins as well as the basic protocols for electronic
cash. Electronic coins possess similar properties as metal coins, among
which is the unique feature that a payment transaction leaves no trace about
the identity of the payer. Currently, ecash technology (as provided by DigiCash,
see http://www.digicash.com for more details) is used by a number of banks
around the globe. These banks issue ecash to their customers, who can then
spend it at affiliated merchants on the Internet.
We will focus on the core protocols that make up the ecash system. For
brevity, we will omit a lot of details and alternative approaches that are taken
into account in the actual system. We do, however, consider some future extensions
such as the extension to off-line ecash, where the use of smart cards and
the Internet are combined into a highly versatile and secure privacy-protecting
payment system.
? Version of April 1997. Appears in B. Preneel and V. Rijmen (eds.) State of the Art in Applied Cryptography,
Course on Computer Security and Industrial Cryptography, Leuven, Belgium, June 3–6, 1997, vol. 1528 of
Lecture Notes in Computer Science, pp. 338–352. Springer-Verlag.
2 Characteristics of Electronic Payment Systems
Although more and more consensus is building up as to which properties are required
of a payment system, we are not going to list and describe these properties
one by one in this paper. Instead, we take a bottom up approach, and describe
some of the basic characteristics of payment systems. From these characteristics
one can then infer the possibilities and impossibilities for the numerous variations,
and what their impact is on the performance and flexibility of the system.
Payment by instruction vs prepaid electronic cash In so-called payment
by instruction type of systems, a payer basically orders the bank to move a sum
of money from her account into a payee’s account. Examples in this category are
credit and debit cards as well as many forms of cheques. The moment at which
the money is actually moved from the payer’s account into the payee’s account
depends on the system, but at all times banks and credit card companies will
try to prevent discrepancies between accounts.
The central security aspect in these systems is to ensure that only legitimate
account holders are able to issue payment instructions. Of course, digital
signatures are the solution for doing this over a large, open network such as
the Internet. Since digital signatures only make sense if there is an infrastructure
for certifying public keys, a lot of effort is devoted to just this. See, for
instance, the SET (Secure Electroncic Transaction) proposal, a joint effort by
MasterCard, VISA, and other influential partners, which specifies a hierarchy of
certification authorities on top of the payment protocols, as laid out in the iKP
system [BGH+95].
Prepaid systems are conceptually close to electronic equivalents of cash. Telephone
cards, smart card based systems, as well as ecash fall into this category.
The user’s account is debited as soon as the card or device is reloaded with
electronic cash. During payments the electronic cash is released again, and only
then the payee’s account will be credited. In the mean time the issuer keeps a
float corresponding to the outstanding cash.
The central security aspect in this type of system is to ensure that cards
or representations of cash cannot be forged. When forgery happens, the float
will ultimately be insufficient to credit all of the payees’ accounts for received
payments. Of course, it should also be ensured that only legitimate account
holders can reload cash from their accounts. However, this security aspect is
now limited to the infrequent withdrawal protocol, and is no part anymore of
the more frequent payment protocol.
On-line vs off-line In the field of electronic payment systems, the notions online
and off-line refer to a specific property of the payment protocol. Although
the payment protocol is functionally a protocol between two parties (payer and
payee) many payment systems require that the payee contacts a third party (e.g.,
the bank or the credit-card company acting as an acquirer) before accepting a
payment. If that is the case, the system is called an on-line payment system; the
communication between a payee and its acquirer may be using any communication
medium (not necessarily the Internet). If such a contact with a third party
is not required during the payment protocol, the system is called off-line. In an
off-line system payees are required to contact their acquirer on a regular basis
for clearing all received payments.
Secret key vs public key authentication A basic requirement of a payment
protocol is that it allows a payee to receive payments from any payer. A payment
can be seen as some sort of authentication of the payer towards the payee
(to show that the payment is authentic). Authentication can be based on secret
key cryptography or on public key cryptography. In the latter case, the payee
only needs to have a public key available in order to verify incoming payments.
Although the costs of equipping smart cards with crypto co-processors are expected
to become marginal, it is important to note that the property of public
verifiability can be obtained using simple smart cards only, provided one applies
a method of what we call signature transport. In such a system, signatures are
created by the issuer only, and later endorsed by the payer during the payment
protocol, depending on a challenge from the payee. The trick is to achieve that
sufficiently many payments can be made between successive reloads, which requires
optimal use of the limited amount of EEPROM available on simple smart
cards. The added advantage is that the secret key for creating signatures is only
used by the issuer.
In case authentication is based on secret key (symmetric) cryptography, however,
the payer and payee must have a shared secret key available in order to
complete a payment. A straightforward solution is to give all users the same
secret key, but this is generally considered insecure, as this would mean that
breaking a single smart card (i.e., extracting its secret key) will suffice to break
the complete system. The standard solution is therefore to break the symmetry
between payers and payees by equipping the merchants with a highly secure
tamper-proof box called a SAM that contains a master key. The payers’ keys
are derived from this master key in a process called diversification by applying
a cryptographic hash (e.g., SHA-1) to the concatenation of the master key and
the payer’s card number. The idea is that the SAM is more difficult to break
than a smart card, and also that it is possible to routinely check (as part of the
maintenance) if the SAMs have not been tampered with.
In the EMV standard (developed by Europay, MasterCard, and Visa) a first
step is made toward including public key authentication. To prevent frauds in
which cards with fake card numbers are introduced, each card carries a fixed
RSA certificate that shows the validity of the card number. At the start of each
payment, the certificate can be verified against the public key stored in the POS
terminal. The remainder of the payment protocol again relies on a secret master
key stored in the SAM of the POS terminal.
Counters vs coins A direct way of representing electronic cash is to use a
counter stored on a smart card. Clearly, this is an efficient and flexible method,
and any amount can be paid from the card as long as it does not exceed the
value of the counter. A more involved way is to represent electronic cash by a
set of electronic coins. As with ordinary coins, each electronic coin has a fixed
denomination. Now, any amount can be paid as long as it can be obtained as a
sum of the denominations of a subset of the available coins. By using a suitable
distribution of the coin denominations upon reloading, possibly as a function of
the expected spending pattern, it can be prevented in most cases that a payment
cannot be completed although the total value of the coins is sufficient.
The CAFE project (see, e.g., [BBC+94]) relies on a compromise between
these two basic methods. For each payment the required amount is debited from
a counter but at the same time one special coin is used up. The special coins have
no value by itself. Upon reloading the counter is credited with the withdrawn
amount and the supply of special coins is replenished.
As we will explain later on in this paper, an important property that separates
coins from counters is that electronic coins are the only way to achieve a system
that is secure (in the bank’s interest) and at the same time protects the users’
privacy in a strong sense. Security-wise the nice thing about coins is that no
party except the bank is able to create coins. Hence, the only way to attack the
system is to duplicate coins that are already in circulation, but this is easily
stopped by keeping track of spent coins.
Software-only vs tamper-resistant hardware Assuming that payers and
payees need some computer device to take part in the electronic payment system,
an important distinction is whether the device contains tamper-resistant
hardware or not. If no part of the device is supposed to be tamper-resistant (that
is, the security of the system does not rely on such an assumption), we call it
software-only. Smart cards and SAMs are examples of tamper-resistant devices.
Some advantages of a software-only system are that it can be distributed
easily and at low cost, it can be run on any computer hence there is plenty of
computing power and disk storage available, and users do not have to acquire
special hardware. Important advantages of the use of tamper-resistant hardware
are that storage and use of secret keys is protected well, and that critical parts
of the system run in a secured environment.
3 Money Flow
We briefly describe the money flow in the ecash system. Where appropriate we
will distinguish between the ecash bank (or issuer/acquirer) and the ecash mint.
The mint is the component of the ecash system where coins are created and where
the databases of spent coins are held. So-called ecash accounts form the interface
between the bank and the mint. In practice, several ways will be provided to
transfer money to and from an ecash account. For example, an ecash issuer may
provide a home-banking application that allows its customers to move money
between their bank accounts and their ecash accounts. Another possibility is
that the bank accepts credit card payments, by means of which users can feed
their ecash accounts.
We concentrate on the basic operations that manipulate ecash coins. Other
important ingredients of electronic commerce protocols, such as certificates and
receipts, are omitted as these parts are more or less independent of the way the
core protocols are implemented.
Withdrawal By means of the withdrawal protocol, users are able to convert
money from their ecash accounts into ecash coins. Access to the ecash account
is only possible if the user is able to sign the withdrawal request, where the
signature is checked against the public key registered with the ecash account.1
The coins obtained in a withdrawal are stored on the user’s hard disk. By default
the coins are stored in a password-encrypted manner to prevent them from being
stolen (copied).
Payment To pay a certain amount, a set of coins is selected such that the values
add up to the required amount. In the on-line ecash system, this set of coins is
then encrypted for the bank, using the bank’s public key, to prevent that the
shop or anybody else can steal (copy) the coins. The shop deposits the payment
at the bank, who credits the shop’s ecash account if all coins are valid and none
of the coins has been spent before. Accepted coins are added to the database of
spent coins so that double-spending will be detected.
Payment deposit In the on-line ecash system this protocol is part of the payment
protocol as executed by the shop. In an off-line ecash system this protocol
is executed at a later moment, preferably in batch mode. An important property
of the payment protocol is that the payment deposit is made specific to the
payee. That is, a payment deposit for a specific payee cannot be deposited to
any other account than the account of the specified payee.
Coin redemption It is possible to return coins directly to the mint without
using them in a payment. A natural restriction is that the number of coins
that a user redeems is not allowed to exceed the number of coins that has been
withdrawn by the user; a more refined way is to monitor this per coinage and
per denomination. This protocol is used when expired coins are refreshed, or to
improve the distribution of the coin denominations.
1 A simple way to set up ecash clients is to assume that the software and the bank’s
public key are presented to the user securely (e.g., on a sealed floppy disk). The user
also gets an account number and a PIN code from the bank. At home the user installs
the ecash client, generates its own private key/public key pair, and registers it with
its ecash account by sending it to the bank together with the PIN code (everything
encrypted with the bank’s public key). The user’s private key can be stored in a
password-encrypted manner on the hard disk.
Recovery If desired, users are able to resurrect coins that have been lost, for
instance, because of a hard disk crash. By means of a special recovery protocol executed
between the user and the mint, all the coins that have been withdrawn by
the user since the previous checkpoint can be reconstructed. The reconstructed
coins are then redeemed at the mint, which will only accept those coins that
have not been spent before.
4 Cryptographic Primitives
RSA signatures For authentication of messages we currently use the RSA
public key cryptosystem. Each participant picks its own RSA key pairs at random.
The public key consists of a modulus n = pq of prescribed size, where p, q
are two randomly generated primes of equal size, and an exponent e, which is
co-prime with (n) = (p − 1)(q − 1). The private key d is the multiplicative inverse
of e modulo (n), that is, the unique number d satisfying de 1 mod (n),
which we denote by 1/e.
To sign a message m 2 ZZ
n, where the signer has private key d and public key
(e, n), the signer computes the signature s = md mod n. To verify the signature
we check that se m mod n; this identity must hold as we have the identity
mde m mod n, since m(n) 1 mod n for all m 2 ZZ
n. Actually, it can be
proved that mde m mod n for all m 2 ZZn.
For various reasons (e.g., because RSA signatures as described above can
be existentially forged: select an arbitrary s and take m = se mod n, then s
is a valid RSA signature on the “message” m), the actual message is usually
first transformed into a related message by applying a one-way hash and/or
redundancy-adding function f to it and then signing the result f(m). In the
next section we will see an example of such a function f.
Hybrid encryption The RSA cryptosystem can be used for encryption as well.
To encrypt a message m, 0 m < n, for a receiver with public key (e, n), the
sender computes the ciphertext c = me mod n and sends c to the receiver. To
decrypt the message, the receiver uses its private key d to compute cd mod n,
which is equal to mde mod n = m.
In practice, the use of public key encryption is often limited to the encryption
of session keys. A symmetric encryption algorithm is then used to encrypt the
actual message with the session key. In the ecash system, we also use such a
hybrid encryption method (or, “envelope method” as it is sometimes called),
where we combine RSA with 3-DES (with 112 bit keys). For reasons of efficiency,
it is often advantageous to use public exponent e = 3; encryption of the session
key then amounts to two modular multiplications, and poses no security risk as
long as some well-known attacks are taken into account.