Strong Loss Tolerance of Electronic Coin Systems - ECON @ TU Wien

Strong Loss Tolerance of Electronic Coin Systems BIRGIT PFITZMANN Universita¨t des Saarlandes and MICHAEL WAIDNER IBM Research Division

Untraceable electronic cash means prepaid digital payment systems, usually with offline payments, that protect user privacy. Such systems have recently been given considerable attention by both theory and development projects. However, in most current schemes, loss of a user device containing electronic cash implies a loss of money, just as with real cash. In comparison with credit schemes, this is considered a serious shortcoming. This article shows how untraceable electronic cash can be made loss tolerant, i.e., how the monetary value of the lost data can be recovered. Security against fraud and preservation of privacy are ensured; strong loss tolerance means that not even denial of recovery is possible. In particular, systems based on electronic coins are treated. We present general design principles and options and their instantiation in one concrete payment system. The measures are practical. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General—security and protection; C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications; D.4.5 [Operating Systems]: Reliability—fault tolerance; D.4.6 [Operating Systems]: Security and Protection—authentication; cryptographic controls; H.4.3 [Information Systems Applications]: Communications Applications; K.6.5 [Management of Computing and Information Systems]: Security and Protection General Terms: Algorithms, Reliability, Security Additional Key Words and Phrases: Byzantine faults, electronic cash, payment systems, privacy

1. INTRODUCTION E-cash (electronic cash) systems have three basic transactions. A withdrawal involves a future payer and the issuer of e-cash, called bank in the This work was supported in part by the DFG (German Research Foundation) and mainly done while B. Pfitzmann was with the University of Hildesheim and M. Waidner was with the University of Karlsruhe, Institut fu¨r Rechnerentwurf und Fehlertoleranz. Authors’ addresses: B. Pfitzmann, Universita¨t des Saarlandes, Im Stadtwald, D-66123 Saarbru¨cken, Germany; email: [email protected]; M. Waidner, IBM Zurich Research Laboratory, Sa¨umerstrasse 4, CH-8803 Ru¨schlikon, Switzerland; email: [email protected]. Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and / or a fee. © 1997 ACM 0734-2071/97/0500 –0194 $03.50 ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997, Pages 194 –213.

Strong Loss Tolerance of Electronic Coin Systems

•

195

following, and loads e-cash into the payer’s purse. Typically it debits a bank account of this payer. A payment involves a payer and a payee and transfers e-cash from the payer’s purse into the payee’s till. A deposit involves a payee and an acquirer of e-cash, also called bank in the following, and turns e-cash back into “real” money, typically on a bank account of the payee. Typical applications of e-cash are buying bus tickets, paying calls at public phones, and low-value payments over the Internet. An e-cash system is called offline if payments only involve a purse and a till and online otherwise. For payments in real shops and in particular in public transport, being offline is still an important requirement, and even some Internet payment systems try to avoid the communication overhead of online systems. Purses for offline e-cash are traditionally implemented on smartcards. However, our measures, as in fact all really secure payments, assume that the purse has a secure I/O channel to the user. This suggests the use of mobile user devices with a small user interface, e.g., Pfitzmann et al. [1997]. With real cash, particularly coins, payers do not have to identify themselves to payees, and banks cannot trace who paid whom, at least not on a large scale. E-cash should offer at least the same degree of untraceability.1 E-cash should also be secure for all parties. Roughly this means that no party should lose money and that the security of any party should rely as little as possible on the dependability of others. In particular, payers and payees should not unnecessarily be forced to trust the employees and equipment of their banks. Disquieting court cases resulting from systems that do not have this multiparty security can be found in Anderson [1994]. There are also important differences between real and e-cash. In particular, received real cash can be spent again immediately, whereas e-cash typically has to be deposited in between, i.e., is not transferable. 1.1 Loss Tolerance: Requirements and Fault Model Loss tolerance means that payers can be correctly reimbursed for e-cash they had in lost, stolen, or broken purses. (For tills and the bank’s central devices, standard fault tolerance measures can be used [Lee and Anderson 1990].) We make the following requirements on a loss tolerance scheme: (1) Security of the bank: Even if arbitrarily many users cheat and “lose” their devices according to an optimal strategy, they cannot obtain altogether more money than they possessed. This requirement has to comprise the situation that payees “lose” their tills. (2) Security of users who do not lose their devices: Nobody should lose money by loss tolerance measures for other payers, nor by provisions for loss tolerance for their own purse if this purse does not get lost. 1

Most e-cash systems do not offer untraceability for payees, assuming that the payee in systems without transferability is usually a retailer or another well-known party. Moreover, a person’s total in- and outflow of money is typically not secret. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

196

•

Birgit Pfitzmann and Michael Waidner

(3) Loss tolerance: The owner of a lost purse gets the lost money back after a bounded period of time. We concentrate on strong loss tolerance, where this is guaranteed in the same sense of multiparty security as the other requirements.2 (4) Untraceability of payers who do not lose their purses: The loss tolerance measures should not impair the privacy of people who do not lose their purses. Slightly weaker versions will also be considered. (5) Partial untraceability of owners of lost purses: Only a restricted number of payments made with a lost purse should become traceable. Requirements (4) and (5) apply to untraceable cash schemes only. Since these requirements are somewhat flexible, we specify in the theorems what precise versions our protocols fulfill. Requirement (3) would have to be slightly weakened for transferable e-cash; in particular, a payment between two purses that are both lost immediately afterward cannot be reconstructed correctly. We model the loss of a purse as a crash failure, i.e., the purse behaves correctly until the loss and then stops completely. This benign fault model is not in contradiction with security against malicious attackers: it is only made for a payer’s own purse when the security of this payer is considered, i.e., in Requirements (3) and (5). 2. PRINCIPLES OF COIN CONSTRUCTIONS We primarily consider untraceable offline e-cash systems, the hardest class to make loss tolerant. For a comparison, note that in traceable credit card-like systems the mere loss of a payer’s device does not even imply a loss of money, and in traceable online e-cash systems the amount of e-cash in each purse at any time is in principle known to the bank. Untraceable online e-cash systems are briefly considered in Section 3. Constructions of offline e-cash fall into two main classes: balance and coin systems. In the former [Even et al. 1984], each purse simply handles a balance denoting the total amount of e-cash it currently contains. These systems rely heavily on the tamper resistance of the purses, which is not always justified [Anderson and Kuhn 1996]. We presented loss tolerance for balance systems with and without untraceability in Waidner and Pfitzmann [1990], concentrating on problems arising from transferability and without achieving strong loss tolerance. In coin systems, e-cash is represented by individual coins stored in the purse. A coin is some data digitally signed by a bank and worth a fixed amount of money. Thus users cannot forge new coins, independent of the tamper resistance of their devices. For untraceability, the coins are signed using a blind signature scheme [Chaum 1985]. This means that the bank 2 Our measures can be simplified if one is satisfied with weak loss tolerance, where this is only guaranteed if the bank is honest. In other words, bank insiders can embezzle lost money. We then require at least the security of owners of lost purses against bank insiders: They should not lose more money by the loss tolerance measures than what was in the lost purse.

ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

197

Fig. 1. Lifecycle of a coin in a system with identification of double-spenders. Only the transformed (white) version of a coin is acceptable for payments and deposits. All transactions may be interactive.

does not see the coin in its real form during signing (Figure 1). Hence, when a payee deposits a coin, the bank cannot link it to the payer who withdrew it. Different coin types, e.g., different denominations, can be distinguished by different keys used for signing. We assume that the keys are independent, and the coin types can therefore be treated as different systems implemented in the same purse. So far, a payer might try to spend the same coin more than once because it is merely signed digital information and can be copied. Countermeasures are online verification, identification of double-spenders, and combination with tamper resistance. Online verification was assumed in all the early proposals for untraceable coin systems, e.g., Chaum [1985], Damgård [1990] and Pfitzmann and Waidner [1992]. To identify double-spenders, identities are coded into coins such that they are perfectly hidden if the coin is spent once (so that honest payers remain untraceable), but revealed if a coin is spent twice [Brands 1994; Chaum et al. 1990; Ferguson 1994; Franklin and Yung 1993]. For this, the purse receives a challenge C from the till in each payment and has to send a response R; see Figure 1. From two challenge-response pairs for one coin, the bank can compute the identity. Moreover, the bank requires the identity of the payee (or the till) and a value Time, which can be the real time or a sequence number for this payee, to be encoded into the challenge C in a predefined way, i.e., it only accepts deposits where this is fulfilled. Thus even a collusion of payers and payees cannot perform two payments and deposits with the same challenge and response. Identification of double-spenders alone may be unacceptable to banks because it does not guarantee that the money can be recovered. Combining it with tamper-resistant purses does not change the cryptographic protocols and gives the banks the optimal level of security achievable with offline payments. A variant called wallet-with-observer protocols separates the ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

198

•


purse into one part trusted by the user and another part that is tamper resistant against the user and trusted by the bank [Chaum 1992]. 3. HIGH-LEVEL DESCRIPTION This section contains a description of our loss tolerance measures for untraceable coin systems, independent of cryptographic details, i.e., on the level of Figure 1. One measure that depends on cryptographic details is postponed to Section 5, which will also map the informal terms from this section to one concrete payment system. It should then be no problem for the reader to perform the same mapping for other payment systems. The measures include several options. The choice among them should be based on the infrastructure available in concrete applications and as far as possible on the wishes of the individual users. Loss tolerance for purses has to be based on distributed recovery [Waidner and Pfitzmann 1990]: loss or theft of purses cannot be prevented by internal fault tolerance measures, and external measures such as two-outof-three purse systems seem impractical, apart from the fact that the user would usually lose all the purses at the same time. In the following, we concentrate on offline untraceable coin systems. For online untraceable coin systems without tamper resistance, e.g., an Internet payment system running on normal personal computers, one can simply advise users to make local backups and accept that attempts at double-spending (which are never successful in an online system) are usually not fraudulent, but the result of the use of a backup. A disadvantage is that stolen backup information can be used for paying, i.e., Requirement (2) is not entirely fulfilled, but this may be acceptable in many scenarios with normal personal computers. To avoid it or to relieve users from backups, one can use the following measures, omitting all parts that solve specific offline problems. 3.1 Overview In offline systems, we use backups that are not sufficient for paying. Instead, after a loss, the owner of the purse and the bank carry out a recovery protocol. At the end, the user obtains the lost money on his bank account.3 Our backup information essentially consists of the signed coins in the version after transformation (white in Figure 1), but not with all the secret information needed to compute responses R. As this backup information is 3

Even if we relaxed Requirement (2) so that stolen backup information could reduce the security of a payer, using backups for paying would be unacceptable in systems where double-spending is to be prevented by tamper resistance. It would also be unacceptable in systems with double-spender identification: As we cannot expect people who lost their purse to remember precisely which coins they had already spent, reclaiming spent coins must not lead to a proof of double-spending. In all known systems, we cannot even “legalize” such doublespending by additional measures because a proof of double-spending does not indicate which coins were double-spent and how often.



•

199

sensitive from the point of view of privacy, it must either remain with the user or be encrypted. In the first case, the user needs a second device for the backups; in the second case, he at least has to store or remember a key. After a loss, the owner of the purse and the bank carry out a protocol RECLAIMING to establish which coins were in the lost purse at the last backup. However, the user may have spent some of them. This can only be found out via the tills. Essentially, the user will therefore get all the money back that nobody else deposits. We call the corresponding protocol parts SETTLING and reserve the word “recovery” for the entire process of reclaiming and settling. A user is not reimbursed money that a thief or dishonest finder has spent—this would contradict the security of the bank. Hence all technical loss tolerance measures only work for money that is protected by user identification, such as PINs, or where the purse has only been mislaid or stopped working. The user identification does not contradict untraceability if it is made exclusively by the payer’s own purse. 3.2 Storing Backup Information Backup information can either be stored in a backup device owned by the purse holder or in the device of another party. The most natural choice of such a party is the bank; the backup information should then be stored there automatically during each withdrawal. In the following, we only treat this case and assume that all e-cash is withdrawn from an account (and not, say, paid with real cash). The advantages of backups at the bank are transparency, i.e., that the user is not involved in each backup and that backup information is produced as soon as possible. A disadvantage is that encryption typically only yields computational privacy. Strong encryption is needed because the information remains sensitive for a long time, and attackers can keep copies even when the backups should have been deleted.4 The measures with backup devices are a subset of those with backups at the bank; details can be found in Pfitzmann and Waidner [1995]. The only constraint on the encryption system is that one should be able to decrypt encrypted messages individually and in a different order. The encryption key will typically be generated by the purse and output either to a second device of the user or on paper. The only possibility where the user need not store anything is that the purse derives the key from a passphrase the user can remember; the user has to weigh the risk of a bad key against that of a stored key being stolen. For efficiency, we use incremental backups: during each withdrawal, individual backups of new coins are made, and the purse tells the bank which old backups can be deleted because the coins have been spent. Thus 4

Information-theoretically secure encryption with one-time pads is conceivable. The user would need real backup devices for long keys, but the backups themselves would still be done transparently and immediately after withdrawals. The two user devices would only have to be connected occasionally for key exchange. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

200

•


the backup of each coin gets a cleartext sequence number seq_no. Neither party will have to trust the other to perform incremental backups correctly. The user can exchange a new encryption key with his purse at any time. The purse makes a nonincremental backup at the next withdrawal, i.e., it first sends backups of all the remaining coins with the new key. The user has to store the old key until the next withdrawal is confirmed in a statement of account. 3.3 Reclaiming After a loss, some organizational measures are necessary before the technical protocol RECLAIMING can start: the user has to retrieve the decryption key, obtain a new purse or another device that can carry out protocols, and provide it with some information. The bank requires a signature that the user wants a recovery. For partial untraceability (Requirement (5)), the user cannot simply give the decryption key to the bank because a dishonest bank might not have deleted the old backup information. The easiest solution is that the new purse obtains the backup information from the bank, verifies that it is correct, decrypts it, and returns it to the bank, who also verifies it.5 The procedure needs additional measures to combine strong loss tolerance and security for the bank (see Section 5). Transparent techniques, i.e., without a user action at each backup, cannot prevent the bank from giving the new purse out-of-date backup information. We will guarantee that the user does not lose money by this, but partial untraceability will only mean that at most the coins present after one withdrawal, not necessarily the newest one, are traced. Anyway, if the bank did this, the users would often notice it and sometimes be able to prove it externally. To increase untraceability, the user may also be allowed to tell his or her new purse not to reclaim certain coins that he or she remembers to have spent. A user might know a coin by its denomination, date of withdrawal, or withdrawal sequence number. At the end of RECLAIMING, the bank has a list Reclaimed_list(IdPurse) of valid coins considered lost by this purse. For strong loss tolerance, the payer must have a confirmation by the bank on this list. 3.4 Settling and Expiry In the protocol SETTLING, the owner of a lost purse should get all those coins from Reclaimed_list(IdPurse) back that nobody has deposited. For strong loss tolerance, the bank has to prove that the other coins were deposited. Settling can only be done securely after a time tdeposit_expiry where reclaimed e-cash can no longer be spent or deposited, even if the user only

5

Alternatives with pseudorandom updates of the key do not make much difference.



•

201

pretended the loss.6 Hence, coins must either expire for offline spending by themselves at some point, or reclaimed coins must be blacklisted. (Direct deposits of a coin into one’s account and online payments can still be allowed later; they fail if the coin was reclaimed.) Thus all devices need partially synchronized clocks, i.e., with an upper bound D on the difference between two local times. This is no serious restriction, e.g., D 5 1 day is good enough for our purpose. If purses have no real-time clock at all, it is even sufficient if the users enter certain deadlines, e.g., the beginning and end of daylight savings time, with a difference of at most D. By forgetting they only endanger their own security. In the following, we concentrate on the case with expiry.7 Each coin type has attributes tX_expiry for X 5 withdrawal, payment, and deposit, and each device tries to transfer a coin in a transaction X before its local time is tX_expiry 2 D, whereas the partner device accepts until its local time is tX_expiry. The period during which a payer can spend a coin should be at least several months, whereas the additional period during which a payee can deposit it may be rather short, e.g., a week if payees are simply shops. Additional margins are needed for the lengths of transactions and for transactions in which the bank has to do something if its local time is at most a value t, so that its transaction partner has time to appeal to a court and so that the court can decide before its local time t 2 D. 4. SKETCH OF A CONCRETE COIN SYSTEM To present a concrete version of our ideas, we consider the efficient payment system by Brands [1994]. The security of this system as a whole has not been proved, but many subproblems have been, and a proof of any of the efficient schemes seems to be beyond currently known methods. 4.1 Cryptographic Preliminaries The system is based on the assumption that it is infeasible to compute discrete logarithms in certain families of large groups. A discrete logarithm is a value x with gx 5 h, where g and h are given elements of the group and in which the group is written multiplicatively. We omit details of cryptographic definitions of infeasibility for brevity. In the given scheme (like in several others, e.g., DSS [NIST 1992]), the order of each group, i.e., the number of its elements, must be a prime number q. The best-known choice of such groups is made by generating a 6

Nevertheless, banks will often be willing to give money back to users directly after RECLAIMING as preliminary recovery. This can be helped by quick deposits, i.e., if each coin has to be deposited within a short period after the actual payment. Details of the timing and the risk analysis can be found in Pfitzmann and Waidner [1995]. 7 Blacklists, if used for all lost coins, would typically cause a much higher data volume than online verification. Hence they are only useful in applications where expiry and real-time communication are problematic, whereas bandwidth at certain times and storage in tills are abundant. Secure timing and disputes are described in Pfitzmann and Waidner [1995]. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

202

•

Birgit Pfitzmann and Michael Waidner Signer 5 bank (Secret: x)

Public: q, p, g, h 5 gx

1. Message

m

— m 3

2. Signature commitment 3. Random variant

z ;5 m x

— z 3

w random mod q a ;5 g w , b ;5 m w

— a, b 3

r ;5 w 1 cx

4c— — r 3

4. Challenge

5. Response

Fig. 2.

Recipient 5 purse s random mod q with s Þ 0 [and t mod q; later t 5 0] m9 ;5 msgt z9 ;5 zsht 5 m9x u, v, random mod q a9 ;5 a u g v b9 ;5 (b su a tu )m9 v c9 ;5 hash(m9, pk9, z9, a9, b9) [pk9 explained later] c ;5 c9u 21 Verify g r 5 ah c m r 5 bz c r9 ;5 ur 1 v

Blind signature scheme.

prime q, then a second prime p with qu( p 2 1), and using the unique subgroup G q of order q of Z*p . Here, Z*p is the multiplicative group of integers modulo p. A random element of G q can be generated by raising a random element g9 of Z*p to the power ( p 2 1)/q. For simplicity, we use this special case in the following. In a group of prime order, every element g Þ 1 is a generator, i.e., its powers g x cover the entire group. More precisely, the exponentiation exp: x 3 g x is an isomorphism from the additive group of integers modulo q to G q. Additionally, the scheme relies on a family of hash functions hash, which map strings of arbitrary length into the groups G q . These functions must be at least one-way, i.e., it should be infeasible to find a string s with hash(s) 5 s9 for given s9. In fact, much stronger assumptions are made about hash, essentially that it behaves like a random function within this protocol. 4.2 The Blind Signature Scheme The blind signature scheme used in Brands’ payment system was defined in Chaum and Pedersen [1993] as an extension of Schnorr [1991] and Chaum et al. [1988]. The bank chooses an instance of the discrete logarithm problem, i.e., primes q and p, a generator g of G q , a number x modulo q, and h ;5 g x . The secret key is x, and the remaining parameters are published. Figure 2 shows how a message is signed. m corresponds to the gray version of the coin in Figure 1 and m9 to the white version. The other transformations between values without and with a prime are corresponding transformations of the signature. The value z 5 m x is called a signature commitment on m because, like a signature, it can only be computed with the secret key, but the recipient cannot verify its correctACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

203

ness on his own. The rest of the message exchange is intended to convince the recipient that z is correct. The transformed version of a coin fulfills analogous verification equations as the original version (see Step (5)), i.e., all values except g and h get primes. If this protocol is used in a withdrawal, it must be accompanied by a withdrawal order signed by the purse, which later enables the bank to prove that it was allowed to debit the account. 4.3 Encoding Identities into Coins To encode identities into coins for double-spender identification, two further random generators g 1 and g 2 of G q are chosen in advance for the entire system.8 For one payer, the bank always signs the same message m, which is constructed as follows: (1) The purse chooses a secret random number i (mod q) and gives h 1 ;5 g i1 to the bank. We call i the identity proof of the purse. (2) The purse proves to the bank that it knows i with h 1 5 g i1 (using an interactive protocol, a simpler version of Figure 2). If another purse already uses h 1 , the bank asks the current purse to repeat its choice. (3) The payer signs, e.g., with a handwritten signature, that m 5 h 1 g 2 will be used for his withdrawals. If the bank can later determine i with g i1 g 2 5 m, this counts as a proof that a coin from this purse was spent twice. As m is constant, Parts 1 and 2 of Figure 2 have to be performed only once for all the withdrawals performed by one purse. The identity is preserved through the blinding transformation as follows. For payments, the purse will have to know a representation of m9 as m9 5 g x11 g x22 . Under the discrete logarithm assumption, it is infeasible to compute two different representations of the same number m9 [Bos et al. 1988; Chaum et al. 1992; Pedersen 1992]. Hence, if one believes that the blind s t signature protocol can only be used for messages m9 5 m s g t 5 g is 1 g 2 g , the purse must choose t 5 0, x 1 5 is, and x 2 5 s. Thus the invariant of all its coins is x 1 /x 2 5 i. 4.4 Payments The idea behind the payment protocol (Figure 3) is that each response yields two linear equations about four variables, two of which are x 1 and x 2 . One response, i.e., two equations, does not reveal anything about the identity proof i 5 x 1 /x 2 , whereas two responses yield four linearly independent equations and thus all the variables. 8

Everybody now has to trust the randomness of q, p, and g 1 . In practice, one can generate them from old tables of random numbers using a standardized deterministic procedure. If one believes that computing discrete logarithms is infeasible for the bank even if it chooses the group and the generator (and for our application that the assumption about Schnorr identification in Lemma 5.3.3 still holds), it may still generate all these parameters alone. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

204

•

Birgit Pfitzmann and Michael Waidner Purse (Secret: x 1 , x 2 , y 1 , y 2 , m9, z9, pk9, a9, b9, c9, r9)

1. Send coin

Public q, p, g, h, g 1 , g 2 — m9, z9, pk9 3 — [a9,b9,]c9,r9 3

2. Challenge

If possible, verify Id Payee , Time

3. Response

R ;5 (sig1, sig2) with sig 1 :5 Cx 1 1 y 1 sig 2 :5 Cx 2 1 y 2

Fig. 3.

4C— or 4 IdPayee , Time —

—R 3

Till Verify: c9 5 hash(m9, z9, pk9, a9, b9) g r9 5 a9h c9 m9 r9 5 b9z9 c9 m9 Þ 1 C :5 hash9(m9, pk9, Id Payee , Time) Verify 1 g sig 2 5 m9 C pk9 g sig 1 2

Payment protocol.

The two additional secret variables y 1 and y 2 for this purpose are chosen in withdrawal and encoded as pk9 5 g y11 g y22 , the unexplained value in Step 4 of Figure 2. The pair (m9, pk9) can be seen as a special public key of the owner of this coin, and answering the challenge C means signing C with the corresponding secret key ( x 1 , x 2 , y 1 , y 2 ). Here, hash9 is another hash function. One can omit a9 and b9 in the first message because the till can compute the only acceptable values from the second and third verification equations. 4.5 Deposit and Double-Spender Identification In a deposit, the till forwards all its information from a payment, including IdPayee and Time. The bank first verifies the validity of the coin just as the till did in the payment. Second, it prevents double-depositing by verifying that the challenge C was constructed correctly and that the payee has not deposited the same coin with the same challenge before; this is simple because of the value Time. Third, it detects double-spending by entering the coin into a data structure check_table, say a hash table, for comparison with previous deposits by other payees. This can be done offline. Coins stay in this table until they expire. If the coin is already in the table, the bank retrieves the corresponding responses R and R*, computes the identity proof as i 5 (sig 1 2 sig *1 )/(sig 2 2 sig *2 ), and looks up which purse m 5 g i1 g 2 belongs to. 5. LOSS TOLERANCE FOR BRANDS’ SYSTEM We now describe one precise instantiation of our loss tolerance measures for Brands’ payment system. Note, however, that the protocols are still idealized in some aspects that are not specific to loss tolerance. In particular, in signing, we omit the key used if it is clear from the context, a type field indicating the protocol step to which the signature belongs, and measures to avoid replay. We also do not present the exchange of new encryption keys. Further, we do not mention all local actions to tolerate interruptions of transactions, although interruptions are considered in the overall structure of the transactions. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

205

5.1 Main Additional Measures Before presenting the protocols and showing their security, we briefly address the main measures not yet mentioned in Section 3. For partial untraceability, each withdrawal will start with a withdrawal order indicating the sequence numbers seq_no of all the coins that will be in the purse after this withdrawal if no interruption occurs. These numbers, in the sequence of all coins withdrawn by this purse, were already needed for incremental backups. Additionally, the purse will sign the backup information for each coin when it is ready. The guarantee that the user does not lose money if the bank declares an old withdrawal order to be the newest one is already given: deleted withdrawals cannot appear on statements of account, and thus the coins withdrawn in them cannot be deducted from the account. Without additional measures, however, the bank could embezzle one coin (where coins are not restricted to small denominations) by claiming that the coin was sent, but that the withdrawal was interrupted before the purse sent the backup information. As this claim might be true, and the purse might have spent the coin, such a withdrawal cannot simply be declared invalid. Instead, we will integrate storing the backup information atomically into the withdrawals. The final problem is that upon receiving a decrypted coin in RECLAIMING, the bank might say that it was already reclaimed for another purse. Again, this may or may not be true. We will prevent such conflicts by allowing every user to reclaim a coin if he or she can show the blinding factor that links it to his or her purse, and we will show that it is infeasible for cheating users to reclaim the same coin for two purses in this way. (Such techniques are called “substantiating being the payer” in Chaum [1989], but showing the blinding factor is not enough in those systems.)9 5.2 Protocols The following protocols combine the described measures. MODIFIED WITHDRAWAL (1) The purse sends a signed withdrawal order that indicates the sequence numbers of all the coins that should be in the purse after this withdrawal. The bank deletes backups with sequence numbers not indicated here. 9

Two alternatives may be generalizable to other systems than this measure. Both fulfill only a slightly weaker version of Requirement (3): stolen backup information allows reclaiming for wrong purses. First, the user may sign with a secret key specific to the coin for which purse is reclaimed. This must not be the normal key used in payments because such a signature together with that from a payment would wrongly allow double-spender identification. Hence the system must be modified so that a coin contains an additional key. In the second alternative, the purse sends a one-way hash value of the coin, obtains a promise by the bank that no coin with this hash value has been reclaimed before, and then sends the coin itself. This solution requires more complicated timing; see the deposit protocol in Bu¨rk and Pfitzmann [1989, Sec. 4.3]. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

206

•


(2) In the withdrawal of an individual coin having sequence number seq_no, the purse prepares encrypted backup information before Step 4 of Figure 2. More precisely,

ciph ;5 encrypt~s, u, v, pk9!, ack ;5 sign ~ seq_no, a, b, c, ciph ! , and the message sent in Step 4 is

~c, ciph, ack!. (3) In Step 5, the bank verifies the signature ack, computes r, stores

backup ;5 ~seq_no, a, b, c, ciph, ack, r!, debits the account, and sends r to the purse. The main point about this protocol is that the purse prepares backup information before it has a coin usable for paying, and the bank makes both the backup information and the coin valid in the same step by adding r. Reclaiming starts with the organizational measures mentioned in Section 3.3. The specific information the new purse needs for recovery are the public key and the value m of the old purse and the decryption key. Then reclaiming proceeds as follows: RECLAIMING (1) The bank sends the last withdrawal order from the lost purse. For each sequence number seq_no indicated there, the bank sends the value backup if the corresponding withdrawal took place and was not interrupted before the money was deducted from the user’s account. (2) The new purse verifies the signature by the lost purse on the withdrawal order. It only accepts values backup having correct sequence numbers. The user verifies now or later that no more recent withdrawals made by the lost purse turn up on the statements of account, nor withdrawals of coins whose sequence numbers were indicated in the last withdrawal order, but for which backup was not sent. (3) For each value of backup it received, the new purse acts as follows: (a) It verifies that ack is a valid signature by the lost purse. (b) It verifies that r is correct, just as in Step 5 of Figure 2. (c) It deciphers ciph and recomputes

settling_info ;5 ~m9, z9, pk9, c9, r9! just as in Figure 2. (d) It sends settling_info and s to the bank in a signed message. (4) The bank verifies this signature, the validity of the coin (like the till in the first step of a payment), and that m9 5 m s , where m is the message ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

207

used in withdrawals made by the lost purse. It then looks whether the same coin is already present in Reclaimed_list(IdPurse). By “the same coin” we mean one with the same values m9 and pk9. If yes, it shows the purse’s signature from Step (3d) of the old execution of RECLAIMING to prove this fact. If the user claims that the previous execution was interrupted, the bank sends its own signature from Step (4) of that execution again. Otherwise, it inserts settling_info into Reclaimed_list(IdPurse), stores the purse’s signature there, too, and sends and stores a signature sign(settling_info, IdPurse) as confirmation that this coin is considered lost by this purse. Note that the bank does not verify in Step (4) that settling_info has anything to do with backup. A court settles a dispute about this protocol as follows. The court’s inputs are the identities of the account and the purse, the public keys of the old and new purse, and the identifier of the last withdrawal that appeared on the statement of account. DISPUTE ABOUT RECLAIMING —The bank has to show the corresponding withdrawal order. —The new purse and the bank repeat the steps of RECLAIMING, sending their messages via the court. The court tests all the signatures, performs the verifications of Step (2) and Step (3b), and verifies that m9 5 m s . —If the value of m is disputed, the bank has to show the user’s signature on it (from Step (3) in Section 4.3). —If everything is correct, the court enforces that the user obtains the signatures that these coins are considered lost by this purse. We now describe a simple settling protocol that is entirely executed after the time tdeposit_expiry.10 SETTLING —The bank looks up each coin from Reclaimed_list(IdPurse) in check_table. —If the coin is not found there, the bank gives its monetary value irrevocably back to the owner of this purse. This is done by a statement of account indicating precisely which coin was reimbursed. —If the coin is found, the bank proves this to the owner of the purse by showing the challenge-response pair from the deposit. Note that the bank never checks whether the same coin is in more than one list of reclaimed coins; thus, if this happened in spite of the measure of having to show the blinding factor, the bank would have to reimburse the

10

If the bank offers preliminary recovery, it may instead decide to keep the status of reclaimed coins up-to-date by modifying check_table and the deposit protocol so that deposits of reclaimed coins are noticed at once. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

208

•


owners of both purses. Of course, we will show that this will not happen to an honest bank if the cryptographic mechanisms are secure. The bank stores current backups and lists of reclaimed coins as long as check_table for this coin type (and its risk in losing them is less than with check_table). The payer can delete the bank’s confirmations on the list as soon as he or she has the money back or proofs that the coins were deposited. A court decides a dispute about SETTLING as follows: DISPUTE ABOUT SETTLING —The payer shows the signed confirmations by the bank to prove that certain coins were in Reclaimed_list(IdPurse). Now the bank either has to reimburse the value of these coins or to prove the deposit by showing the court a valid challenge-response pair. Whether the bank has already reimbursed the value of a coin can be decided by the statements of account. 5.3 Security We now demonstrate the security of the described protocols. We need one explicit assumption about the payment system (i.e., it is not known to follow from the assumption that the payment system is secure); the same assumption was derived from a more basic one in Brands [1994, Prop. 7]. Blind Signature Assumption. It is infeasible for any number of colluding participants (not including the bank) to obtain valid signatures on k different coins, unless they carry out at least k withdrawals. THEOREM 5.3.1. Under the assumptions made in Brands [1994], the described loss tolerance measures fulfill all the requirements in Section 1.1 with the following precise versions of Requirements (4) and (5): —Requirement (4): The untraceability of a payer who does not lose his or her purse is only reduced as follows. It is at most as secure as the encryption system, i.e., typically only computational instead of information theoretic. Furthermore, if someone steals the decryption key and colludes with the bank, the untraceability is lost. —Requirement (5): By the recovery for a lost purse, at most the coins that were present after one withdrawal are traced. Furthermore, if the bank cheats by not making this the last withdrawal, it typically suffers a financial loss, and the owners of the purses can prevent the tracing of coins that they remember to have spent. We extract two cryptographic lemmas from the proof of this theorem. Informally, the first one shows that s is a proof to which purse a coin belonged. LEMMA 5.3.2. Under the discrete logarithm assumption, it is infeasible for any number of colluding participants (not including the bank) to show ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

209

nonzero values s and s* with

m9 ;5 m s 5 m* s*,

(*)

where m and m* are the messages that the bank signs in the blind signature protocol with two different purses. PROOF. First recall that the bank enforces m Þ m* (see Section 4.3). This implies s Þ s* in Eq. (*) because otherwise exponentiating with s21 would yield m 5 m*. (Here we need the fact that the exponents are numbers modulo a prime q, so that every nonzero element has an inverse.) Furthermore, the bank has enforced m 5 g i1 g 2 and m* 5 g i* 1 g 2 , where i s and i* are known to the purses. Equation (*) therefore implies g is 1 g2 5 i*s* s* g 1 g 2 and thus that the discrete logarithm of g 2 with respect to g 1 can be computed efficiently as (i*s* 2 is)(s 2 s*) 21 . Thus, fulfilling Eq. (*) is as difficult as computing discrete logarithms. e The second lemma will be used to show that no cryptographic properties are endangered when s becomes known to parties who would not have known it in the system without loss tolerance. We refer to Schnorr’s identification protocol [Schnorr 1991]. In our context, it can be described as the signer’s part of Figure 2 if one omits everything to do with a specific message, i.e., m, z, and b. By its security, we mean the weak statement that it is impossible for anyone else to find out the secret x. LEMMA 5.3.3. Under Brands’ assumptions, it is infeasible for an attacker to find out the identity proof i of a correct purse even if he or she knows the values s, u, and v used in the withdrawals of any number of coins, in addition to all the data the payees and the bank obtain about coins. PROOF. We first show this without u and v. We only need the assumption that Schnorr identification is secure even in parallel executions, a condition implicitly needed in Brands [1994, Prop. 16]. We assume that there is an attacker algorithm A that contradicts Lemma 5.3.3 and show how to construct an equally successful, almost equally efficient attacker algorithm A Schnorr against parallel Schnorr identification. In more technical terms, we perform a blackbox reduction between the two problems, the usual type of reduction between interactive algorithms (e.g., see Goldreich and Oren [1994]). Without loss of generality, we assume that the data that A obtains about each coin are s, m9, pk9, and a response R on a challenge C, where A can choose C after it knows the values s, m9, and pk9 about all the coins. The remaining values that the purse outputs—c, z9, a9, b9, c9, and r9— can be omitted because we can first assume that A obtains u and v instead, from which all others can be derived, and then simulate the choice of u and v, which is random and independent of anything else, inside A. k The algorithm A Schnorr first obtains an input g i1 and values a k 5 g w 1 (k 5 1, . . . , K) from K parallel executions of Schnorr identification. To prepare a suitable input for its subroutine A, it sets m ;5 g i1 g 2 . Then it ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

210

•


chooses values s k and y 2,k randomly for k ;5 1, . . . , K and computes m9k ;5 m s k and pk9k ;5 a k g y22,k . It starts A with the inputs m and all the values s k , m9k , and pk9k . The interactive subroutine A now iteratively outputs a challenge C k for some k and waits for a response R k , which should consist of sig k,1 5 C k is k 1 w k and sig k,2 5 C k s k 1 y 2,k . To compute this, A Schnorr continues the kth execution of Schnorr identification by sending c k ;5 C k s k as its challenge. Thus it obtains the response r k 5 w k 1 c k i. This is exactly the desired sig k,1 . As A Schnorr can compute sig k,2 on its own, it can now give R k to A. When A has obtained all the K responses, it should output the value i, and if it does, A Schnorr also outputs it. Finally, we show that u and v can be computed efficiently from the remaining data and therefore do not make any difference. The bank has the data c and r from the withdrawal and c9 and r9 from the deposit, and given s, it knows that this withdrawal and this deposit belong together. This yields u 5 c9c 21 and v 5 r9 2 ur. e PROOF SKETCH OF THEOREM 5.3.1. Requirement (1) is the security of the bank. If no tamper resistance is used to prevent double-spending, the usual cryptologic aspects of the bank’s security are not weakened because the bank does not perform any new computations with its secrets. Moreover, the Blind Signature Assumption guarantees that “coins” with just settling_ info are no easier to forge than coins that one can pay with. Next, we show that the bank does not lose money by accepting the same coin in more than one recovery, or a deposit and a recovery. The use of check_table in SETTLING and the timing obviously prevent a deposit and a recovery. Step (4) of RECLAIMING prevents two recoveries for the same purse, and by Lemma 5.3.2, it is infeasible even for colluding payers to reclaim the same coin successfully for two purses. We also have to show that the bank’s security is not weakened by the fact that it now needs a valid value backup to prove the validity of a withdrawal. The only problem would be if the payer could spend the coin although he or she had not sent valid data ciph and ack. In this case, the payer has at most received the “random variants” a and b from the bank on his or her own can generate values having the same probability distribution. Thus the bank is as secure as if the withdrawal had not started at all. If tamper resistance is used (see Section 2), we show that doublespending does not even become easier if a payer sees the values s, u, and v in the backups. If he or she could double-spend with these data, he or she could also compute the value i of his or her purse, just like the bank in Section 4.5. As the only other data a cheating payer obtains about his or her coins are those the bank also sees, this would contradict Lemma 5.3.3. In Requirement (2) the payees’ security is obviously unaffected because there are no new steps at which deposits can be rejected and because the timing is secure. Similarly, none of the new steps have any effect on the owners of other purses. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

211

It remains to be shown that the security of a payer is preserved even if someone finds the decryption key and colludes with the bank to obtain the encrypted backup information. We have to show that the thief cannot (a) make withdrawals from the payer’s account, (b) make payments or deposits with the payer’s coins, (c) wrongly brand the payer a double-spender, or (d) reclaim the payer’s coins. Option (a) is clear: no information about the key needed to sign withdrawal orders is in the backups. Lemma 5.3.3 applies to the thief; this immediately excludes (c). If the thief could make payments or deposits (even if only for one challenge), this would yield double-spending together with the payments that the payer makes. Thus i could be computed, which contradicts Lemma 5.3.3 again. This proves (b). For (d), first note that the thief cannot reclaim the coins under the payer’s name (which, although of no direct advantage to the thief, might put the payer in an embarrassing position) because this requires a signature by a real purse of the payer. If the thief could reclaim the coin in another name, this would not prevent the honest payer from reclaiming it, too. (However, this would harm the bank and was shown to be infeasible under Requirement (1).) Requirement (3) is strong loss tolerance. First note that all the information the owner of a lost purse divulges about a coin in RECLAIMING would also be known to a thief of the decryption key colluding with the bank. Thus the proof of Requirement (2) excludes the majority of ways to cheat a payer. It remains to be shown that each unspent coin having a sequence number seq_no for which the bank deducted money from the account can be reclaimed successfully. Let us fix such a value seq_no. First, the bank has to send some correct withdrawal order as the last one. As the coin with seq_no was unspent at the time of the loss, it is either indicated in this withdrawal order or was withdrawn later. The latter case can be excluded because it would be declared invalid in a dispute. Thus the bank is forced to send a value backup for this coin, and this value must pass the tests in Steps (3a) and (b) of RECLAIMING. These tests ensure that backup contains the values (s, u, v, pk9) that the lost purse used for seq_no and the values a, b, and c from the same withdrawal. Thus the new purse can reconstruct the correct values settling_info and s, and they pass the initial tests in Step (4). Now the bank could only wrongly refuse recovery by showing the challenge-response pair from a deposit or a signature by the same payer under a previous attempt at reclaiming; see the two disputes. This falls under the types of cheating called (b) and (d) which were shown to be infeasible above. The only problem would be if an honest payer constructed the same coin twice, but this only happens with an exponentially small probability. In Requirement (4) the untraceability of people who do not lose their purses is only restricted by the backup information at the bank and by the decryption key. Hence it is obviously as good as the security of the encryption system if the decryption key remains secret and is lost if someone obtains both the backup information and the decryption key. For Requirement (5) the new purse only decrypts coins having sequence numbers that were present after one withdrawal, and if this is not the ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.

212

•


newest withdrawal, the bank cannot deduct money for coins that were withdrawn later. Thus it loses money if any of them were spent. The information divulged for a reclaimed coin is only settling_info and s (and the correct values, as we saw under Requirement (3)). To show that the other coins remain untraceable, we use the fact that the untraceability in Brands’ system is information theoretic, i.e., independent of the computing power of the attacker, and that the coins are unlinkable—i.e., even if it becomes known by context information who made some of the payments, this does not help in tracing other payments [Brands 1994, Prop. 11]. Thus the pairs (m, m9 5 m s ) for some coins do not help in tracing other coins. An information-theoretic attacker can compute s from such a pair, and hence divulging s for some coins during reclaiming does not help tracing other coins either. e 6. CONCLUSION We have shown how untraceable prepaid electronic coin systems can be made loss tolerant, sketched a number of options among which a suitable system for a given application can be chosen, and presented one set of protocols in some detail. Loss tolerance removes an important disadvantage that these systems would otherwise have in comparison with credit systems or traceable prepaid systems. Two small disadvantages are that the loss tolerance measures are not entirely transparent—a user at least has to store some information at the start of the system and to retrieve it after the loss of a purse—and that backup information for a certain user poses a certain risk to this user’s untraceability. However, no other security properties need to be weakened. Moreover, the efficiency of the systems is not significantly reduced; one can easily see that all the complexity parameters (except in the alternative with blacklists) are dominated by the complexity of the system without loss tolerance. The loss tolerance measures can be adapted to many variants of the payment systems. The report [Pfitzmann and Waidner 1995] sketches how efficiency can be improved if purses use pseudorandom numbers instead of real random numbers in withdrawals; extensions to more than one bank, divisible coins, transferability, and wallet-with-observer protocols; and loss tolerance measures for related systems without untraceability and socalled balance-and-cheque protocols. ACKNOWLEDGMENTS

We thank Matthias Schunter and an anonymous referee for detailed and helpful comments. REFERENCES ANDERSON, R. AND KUHN, M. 1996. Tamper resistance—A cautionary note. In the 2nd Usenix Electronic Commerce Workshop. USENIX Assoc., Berkeley, Calif., 1–11. ANDERSON, R. J. 1994. Why cryptosystems fail. Commun. ACM 37, 11 (Nov.), 32– 40. ACM Transactions on Computer Systems, Vol. 15, No. 2, May 1997.


•

213

BOS, J., CHAUM, D., AND PURDY G. 1988. A voting scheme. Unpublished manuscript. CWI, Amsterdam. Presented at the rump session of Crypto ’88. BRANDS, S. 1994. Untraceable off-line cash in wallet with observers. In Crypto ’93. Lecture Notes in Computer Science, vol. 773. Springer-Verlag, Berlin, 302–318. ¨ , H. AND PFITZMANN, A. 1989. Digital payment systems enabling security and unobBURK servability. Comput. Sec. 8, 5, 399 – 416. CHAUM, D. 1985. Security without identification: Transaction systems to make Big Brother obsolete. Commun. ACM 28, 10 (Oct.), 1033–1044. CHAUM, D. 1989. Privacy protected payments—Unconditional payer and/or payee untraceability. In SMART CARD 2000. North-Holland, Amsterdam, 69 –93. CHAUM, D. 1992. Achieving electronic privacy. Sci. Am. (Aug.), 96 –101. CHAUM, D. AND PEDERSEN, T. P. 1993. Wallet databases with observers. In Crypto ’92. Lecture Notes in Computer Science, vol. 740. Springer-Verlag, Berlin, 89 –105. CHAUM, D., EVERTSE, J.-H., AND VAN DE GRAAF, J. 1988. An improved protocol for demonstrating possession of discrete logarithms and some generalizations. In Eurocrypt ’87. Lecture Notes in Computer Science, vol. 304. Springer-Verlag, Berlin, 127–141. CHAUM, D., FIAT, A., AND NAOR, M. 1990. Untraceable electronic cash. In Crypto ’88. Lecture Notes in Computer Science, vol. 403. Springer-Verlag, Berlin, 319 –327. CHAUM, D., VAN HEIJST, E., AND PFITZMANN, B. 1992. Cryptographically strong undeniable signatures, unconditionally secure for the signer. In Crypto ’91. Lecture Notes in Computer Science, vol. 576. Springer-Verlag, Berlin, 470 – 484. DAMGÅRD, I. B. 1990. Payment systems and credential mechanisms with provable security against abuse by individuals. In Crypto ’88. Lecture Notes in Computer Science, vol. 403. Springer-Verlag, Berlin, 328 –335. EVEN, S., GOLDREICH, O., AND YACOBI, Y. 1984. Electronic wallet. In Crypto ’83. Plenum Press, New York, 383–386. FERGUSON, N. 1994. Single term off-line coins. In Eurocrypt ’93. Lecture Notes in Computer Science, vol. 765. Springer-Verlag, Berlin, 318 –328. FRANKLIN, M. AND YUNG, M. 1993. Secure and efficient off-line digital money. In the 20th ICALP. Lecture Notes in Computer Science, vol. 700. Springer-Verlag, Berlin, 265–276. GOLDREICH, O. AND OREN, Y. 1994. Definitions and properties of zero-knowledge proof systems. J. Cryptol. 7, 1, 1–32. LEE, P. A. AND ANDERSON, T. 1990. Dependable Computing and Fault-Tolerant Systems. Vol. 3, Fault Tolerance—Principles and Practice. 2nd ed. Springer-Verlag, Vienna, Austria. NIST. 1992. The digital signature standard proposed by NIST. Commun. ACM 35, 7 (July), 36 – 40. PEDERSEN, T. P. 1992. Non-interactive and information-theoretic secure verifiable secret sharing. In Crypto ’91. Lecture Notes in Computer Science, vol. 576. Springer-Verlag, Berlin, 129 –140. PFITZMANN, A., PFITZMANN, B., SCHUNTER, M., AND WAIDNER, M. 1997. Trusting mobile user devices and security modules. IEEE Comput. 30, 2 (Feb.), 61– 68. PFITZMANN, B. AND WAIDNER, M. 1992. How to break and repair a “provably secure” untraceable payment system. In Crypto ’91. Lecture Notes in Computer Science, vol. 576. Springer-Verlag, Berlin, 338 –350. PFITZMANN, B. AND WAIDNER, M. 1995. Strong loss tolerance for untraceable electronic coin systems. Hildesheimer Informatik-Berichte 15/95, Inst. fu¨r Informatik, Univ. Hildesheim, Hildesheim, Germany. Available as http://www.semper.org/sirene/publ/PfWa_95StrongLossTol. ps.gz. SCHNORR, C.-P. 1991. Efficient signature generation by smart cards. J. Cryptol. 4, 3, 161–174. WAIDNER, M. AND PFITZMANN, B. 1990. Loss-tolerance for electronic wallets. In the 20th International Symposium on Fault-Tolerant Computing (FTCS 20). IEEE, New York, 140 –147. Received July 1995; revised February 1997; accepted April 1997
