«Payment Systems (Ch. 17 of Course Material “Security”) Birgit Pfitzmann Dept. of Computer Science Saarland University pfitzmann ...»
Where there are withdrawals and deposits, they may be over arbitrary sums, i.e., just as with cash, they are typically for many payments together.
For a concrete general API for payment systems (i.e., in a programming language, here Java), see [AASW_98].
Version 23. März 2000 17 Payment Systems 6 C. Classification by Assumed Environment and Communication Practically, one can also distinguish
• Internet versus shop payment systems,
• and systems with online versus offline payment transaction.
These distinctions are related to specific security measures, in particular measures against doublespending of the “same” digital money. This is quite fundamental and therefore already discussed here, not only in the sections on realizations.
Environment. In practice currently a system either assumes that payers have smartcards and carry them into shops, or that they have PCs which stay at home. (However, this distinction will almost certainly vanish in the future.) Moreover, it is often assumed that the smartcards are secure even against their user (but see Chapter 12), while this is not assumed for PCs.
Obviously, for a really secure digital payment system, just as for any other cryptographic system, one has to assume that all devices are at least secure for their users. However, considering that this assumption is currently not fulfilled for either smartcards or PCs (see Chapter 12) against a moderately determined attacker (and breaking a payment system, even only on the payers’ side, may well be worth a certain investment), it is reasonable not to rely entirely on such a system, i.e., limit the amounts that can be paid with it or allow refusals of payments that would digitally be nonrepudiable (e.g., with digital signatures). This is, e.g., done in the SET credit-card standard (but unfortunately not in the filed trials, it seems).
Communication during payment. Some advantages of offline payments are obvious: lower communication cost and less time-critical transaction handling at the banks. In some shop payment scenarios, online payments would still be almost impossible, e.g., in buses. (In Internet scenarios “offline” is not so important, but still standard with credit-card payments.) The problem is whether one can give the recipient a final, non-revocable output ok in an offline payment. This presupposes that the payer’s bank has input allow at some point. Hence an offline system with ok during the payment must certainly be prepaid. But even then, in any purely digital system the payer could make a backup before each payment and reset his system to this backup after the payment. In this way, an arbitrary number of payments to different recipients are possible with the “same” money.
This is called the double-spending problem.2 There are three kinds of solutions:
2 If the payer already knew the recipient when withdrawing money, the system could somehow make the representation of this money specific to this recipient. Then the recipient only needs to check that he does not receive the same money twice. This is called “designated payee”-systems, and they are obviously easier to design than others. (E.g., phone cards are of this type, and there are also some theoretic proposals.) However, such systems are not real payment systems because they are not universal (see below).
Version 23. März 2000 17 Payment Systems 7
• Online payments. Therefore the main arrow (undashed bold-face) in the online payment in Figure
17.3 means that the most important message flow is that the recipient needs a guarantee from the payer’s bank that the money is new. Physically, however, the message is usually sent via either the payer (with a freshness measure) or the recipient’s bank (dashed bold-face arrows). In addition, the payer’s bank needs to know that the payer really wants to pay to this recipient (undashed thin arrow); again the message may be sent in another way (thin dashed).
• If one really wants to prevent double-spending with offline payments, one has to rely on the payer’s device to prevent the resetting to a previous state, i.e., it must be tamper-resistant against the payer. This is what typical current smartcard systems do assume.
• Another possibility is to rely on detecting and punishing double-spending afterwards. This can even be done in anonymous payment systems — there are tricks that achieve that the anonymity automatically gets lost for double-spent money. However, a doublespender of a really high amount may simply flee the country, and, worse, doublespender detection is digital and will therefore point back to the person from whose device the double-spending was done. Hence a clever doublespender would do it from stolen devices. Thus it can only be used in a legally relevant way if one has highly secure devices where thieves quite certainly have no access.
The second and third measure, which are both not perfect, should usefully be combined.
D. Other Functional Properties
• Universal? I.e., can you make all kinds of payments with this system? The two properties make payment-like systems much easier to design, but also non-universal, so that they are no longer not
• The recipient is always known at withdrawal time. However, anything called “money” should be spendable everywhere; objects spendable only in one place are called vouchers.
• Even stronger: The recipient is always equal to the (one and only) bank. Phone cards are of this type because the phone companies can issue them themselves.
• Open? Can all potential payers and recipients take part? Typically this is a buzzword for nondigital properties: no need for creditworthiness, ease of use (children, handicapped persons), no Version 23. März 2000 17 Payment Systems 8 large infrastructure investments for payers and recipients. An interesting question is whether the system allows everybody to be a recipient, too. Often normal people are only allowed to pay.
Other questions are openness for all potential banks and for different software and hardware producers. This is mainly a matter of standardization.
• Does the system offer receipts for payments? Fairly, i.e., the payer will in some way obtain a receipt if and only if the recipient obtains the money? (Typically, the enforcement somehow goes via the bank, which can see whether a payment took place or not, even in the anonymous case.)
• Is there a personal log? (No problem digitally, but the fact that one cannot see one's previous payments is a major disadvantage of smartcards for normal users.)
• Undo? (Typically not — one has to make separate payment back. It is technically difficult because you cannot “give a message back”.)
• For prepaid systems: loss tolerance? I.e., can one get money back if one loses one’s device or data? (In non-prepaid system this is typically clear because the “money” stays at the bank; one only loses one of several ways to access it.)
• For offline systems: transferability? I.e., can you use received money to pay again without having to deposit it at the bank and withdraw it again? This property, which is perfectly normal for real cash, is not given in typical digital payment systems, and quite hard to achieve in a secure way.
17.1.2 Integrity and Availability Goals In systems like payment system, integrity and availability roughly means security against fraud.
The general goal in payment systems is multi-party security, i.e., such requirements from all parties should be considered, and nobody should be required to trust other parties unreasonably. Note that with classical payment systems it was clear that this also concerned the banks, at least that the bank could be held accountable for any irregularities, because everybody held evidence in form of signed statements. The same security is also desired for digital payment systems, but many current proposals ignore it.3 Some proponents argue that fraud by bank insiders (quite a common event in the paper world) becomes less likely in computerized systems due to computer security. However, most banks still use unprotected systems on main-frames with online access and with constant changes. (At least one hears this from many sources — typically the measures are kept secret, which in itself is not a good sign.) Moreover, one only needs to look at how banks handled the security of the PINs of Eurocheque cards... (see Chapter 12).
More technically, the main integrity requirements are that nobody wants to lose money (where desired payments obviously are not counted as “losing”). We don’t go into details here of how this 3 However, recall that ignoring certain security problems is fine in situations of mere risk management, i.e., if a bank decides not to take an expensive measure and rather to bear the risk itself. For example, banks also typically do not verify the handwritten signatures on small money orders, but they bear the risk of acting upon a recognizably forged signature.
Version 23. März 2000 17 Payment Systems 9 can be expressed in terms of the in- and outputs from Section 17.1.1B (see [PfWa_96] in case of interest).
Moreover, payers may also want to be able to specify exactly to whom they pay that money. Not all system proposals currently guarantee this. In systems where double-spending is only detected afterwards the banks require that doublespending can indeed be detected and a responsible user be identified (so there is a special output for this).
For several of the in- and outputs, corresponding disputes are necessary, and all parties require that they win legitimate disputes.
• For example, the usage of receipts at the in-/output level is that if you successfully made a payment (signaled by the payer’s ok), you can later convince anyone of it in a dispute.
Correspondingly, the recipient wants that this convincing only works if he really received this payment (signaled by the recipient’s ok).
• Similar disputes are needed for the outputs that concern account balances. For example, a payer may deny that a subtract occurred which shows up on his statement of account, and will require to win a dispute if he did not make a corresponding input pay or withdraw.
The technically optimal trust model is that for each of these requirements only the participant himself and, for the correct output in a dispute, the arbiter in this particular dispute is trusted.
17.1.3 Confidentiality Goals The essential goal with digital payment systems should be to offer about as much privacy as previous payment systems do. This would mean that small payments can be made confidentially and anonymously. For example, with real cash, nobody can collect data on what books a person buys, which buses she takes, what bathroom articles she uses etc. The importance of privacy in such actions is typically not so much in each single purchase (although there are also some sensitive ones among them), but in the fact that very complete user profiles can be generated from them.
Before looking at different models, note some principle limits: For payments over networks, the overall privacy cannot get better than the privacy of the network connection. There are ways to communicate anonymous ly in principle and even in practice (mainly mixes, see [Chau_81], which is also the principle underlying the best remailers), but they are currently not in wide-spread use.
Similarly, for payments in shops you cannot get more anonymous overall than you are in the shop.
However, such outside knowledge is typically not entered into a digital system and thus not available on a large scale. Hence in the shop case it makes sense to pay anonymously even in a neighborhood shop where you are known.
Technically, we can classify the privacy of payment systems as follows:
ordering goods preceded the payment, and the confidentiality should be consistent among all related steps. Then the payment protocol will simply run over that channel.4 B. Anonymity The rest of this section therefore concerns anonymity towards the partners, who do know some
payment data. The following criteria can be used for classification:
• Who is anonymous? In most proposals, it is only the payer (“payer anonymity”), but technically it can also be the recipient or both. The reason why one usually only makes the payer anonymous is a catalogue-like scenario where merchants have far fewer reasons to be anonymous than buyers. However, other scenarios for payments are conceivable. In particular, with coin-like payment systems, i.e., if the money comes in certain “pieces” of fixed amount, one is used to change in the current world, but if a payment system offers payer anonymity only, one cannot give change because then the payer from the main payment would be the non-anonymous recipient.
• In what actions? Typically, payers are only anonymous in payments, but not in withdrawals of money. In other words, most proposals assume that there are normal non-anonymous accounts and all digital money must at first be taken from such an account. Technically, however, the accounts could usually just as well be anonymous; see Section 17.3.1. (Of course, the bank would not give credit on such accounts.) Some proposals do not need accounts at all; see Section 17.3.3.
• Relative to what other actions is the anonymity?
• Unlinkability. This is the real anonymity in this respect, i.e., no relation between this anonymous action and other actions can be found out.
• Linkability. Here several actions are each anonymous, but one can see a relation. The relation is almost always that one can see that several actions were made by the same person.
Typically one can see some kind of pseudonyms in anonymous actions (e.g., a key used or a card number). Unlinkability then essentially means that the same pseudonym is used only once (transaction pseudonym), in contrast to many times (long-lived pseudonyms). It is clear that the same pseudonym should be used for several steps of the same business transaction (e.g., an order, a payment, and a delivery of goods). But different business processes, even with the same partners, can be unlinkable.