«Payment Systems (Ch. 17 of Course Material “Security”) Birgit Pfitzmann Dept. of Computer Science Saarland University pfitzmann ...»
UNIVERSITÄT DES SAARLANDES
FACHBEREICH 14, INFORMATIK
(Ch. 17 of Course Material “Security”)
Dept. of Computer Science
Version Feb. 2, 2000
© Birgit Pfitzmann, Saarbrücken 1999-2000
Version 23. März 2000
17 Payment Systems
A. Flow Models
B. More Scientific Treatment
C. Classification by Assumed Environment and Communication.............6 D. Other Functional Properties
17.1.2 Integrity and Availability Goals
17.1.3 Confidentiality Goals
A. Confidentiality of Payment Data Against Outsiders
17.2 Non-Anonymous Online Systems
17.2.1 Cryptoless Systems
17.2.2 Secure Symmetric Channels Only
17.2.3 Real Symmetric Systems
17.2.4 Simulating Paper System with Signatures
17.2.5 Micropayments with One-Way Chains
17.3 Anonymous Online Systems
17.3.1 Anonymous Accounts
17.3.2 Anonymously Transferable Standard Values
17.3.3 Schemes with Blind Signatures
A. Basic System in
B. Cryptographic Realization
C. Adding Security in Disputes
D. Recipient Anonymity
E. Maximum Anonymity
17.4 Non-Anonymous Offline Systems
17.4.1 With Signatures
17.4.2 With Symmetric Authentication
17.5 Anonymous Offline Systems
17.5.1 Relying on Tamper-Resistance
17.5.2 Basic Ideas for Systems with Doublespender Identification
A. Basic Ideas
B. On the Challenges
C. Realization Ideas for the Responses
17.5.3 Brands’ System
A. Schnorr Signatures Revisited
B. Chaum-Pedersen Signatures Without Blinding
C. Blind Chaum-Pedersen Signatures
D. Ideas for Encoding Identities into Coins
E. The Complete System
Version 23. März 2000 Contents iv Index
Version 23. März 2000 17 Payment Systems 1 17 Payment Systems* In contrast to most of the system classes in Chapters 2 to 6, there is in principle an enormous number of subclasses of payment systems with somewhat different properties. I.e., even the definitions, if there were any, would be different, not just the degrees of security and the realizations.
On the other hand, most of the systems that are currently known in practice (e.g., have at least been used in a field trial) come from very few of these classes. Moreover, you sometimes only need to change the actual implementations a little bit to get a different class. Hence there is a certain temptation to present only the most usual systems. But as you can also find those in about one new book every two weeks, I decided that a university course should try to look at a somewhat wider picture.
17.1 Properties We first consider the functionality of payment systems, i.e., what you can do with them (similar to first only showing the algorithms of cryptographic systems in Chapter 2, before making more precise definitions of the security). Afterwards, we first consider security against fraud, i.e., integrity and to some extent availability goals, and finally privacy, i.e., confidentiality goals.
17.1.1 Functionality A. Flow Models A standard way to give an overview of payment systems is shown in Figure 17.1 (see, e.g., [BüPf_89, AJSW_97]). These figures give a good first impression if one does not question the
meaning of the arrows in them too much:
A. A cash-like system is a bit like real cash, i.e., coins and bank notes:
1. In a transaction called withdrawal, you get the “cash” from a bank, who subtracts the value from your account.
2. In the actual payment, you hand such money over to the recipient.
3. In a deposit, the recipient puts money into his bank account.
4. In digital systems, a settlement (or clearing), i.e., some interaction between the two banks, might finally be needed (in contrast to real cash).
B. In a cheque- or credit-card-like system,
1. the payer first gives something to the recipient (payment),
2. then the recipient hands that in at his bank (this is called capture or deposit; in a real credit-card system the actual institution doing this is called acquirer), * This is the last chapter of a course primarily intended for third-year undergraduate students. The course is called “Security”, but is actually mainly on cryptology, and most other chapters are German slides. In comparison to an overview paper, I’ve used fewer references, historical notes etc.
Thanks to Michael Waidner and Ahmad-Reza Sadeghi for interesting discussions.
Version 23. März 2000 17 Payment Systems 2
3. this bank turns to the payer’s bank and demands real money (clearing),
4. and the payer’s bank indicates to the payer that the money has now been deducted (indication).
C. In a money-transfer- or remittance-like system, the payer sends a transfer order to his bank, who does the settlement with the bank of the recipient, which then indicates to the recipient that money has arrived.
D. In a debit order system it is the other way round: The recipient tells his bank that he wants money, and the bank gets it from the proposed payer’s bank, which tells the proposed payer that money has gone. Here the proposed payer is obviously allowed to protest. Typically, to restrict misuse, there is also a previous phase where the payer allows a specific recipient to make such debit orders (e.g., for phone bills).
Figure 17.1 Standard payment models in a “money-flow” representation In all these systems, a receipt for the payment may be given — this should be possible in a fair way (i.
e., the payer gets the receipt if and only if the recipient gets the money), but actually not many current systems have it. On the other hand, some descriptions of payment systems already include a description of how the money can be more or less fairly exchanged for digital goods. However, it better to consider fair exchange of money for goods as a different kind of system with its own Version 23. März 2000 17 Payment Systems 3 goals, and usually it is also better to separate the modules in the implementation. (Not all goods are digital, nor are they always sent at the same time as the payment, and you don't want to think about the same exchange questions again for each payment system.) B. More Scientific Treatment If one looks more closely at the arrows in Figure 17.1, some of them seem to represent a flow of “real” money (typically the settlements, which are usually assumed to be between two normal bank accounts), some a flow of “electronic money” (in particular the withdrawal), and some a simple message (e.g., the indications to the payer). Thus it would be pretty hard to define a formal notion “a cheque-like payment system is … ” based on such a figure, in contrast to the figures in Chapter 2 where all elements were clearly either algorithms and messages.
One problem is that “money flow” is not defined at all, and it depends on cultures and communities (bankers, politicians) what is considered “money”. For instance, you can lead long discussions whether you really get “money” into your hands if you withdraw electronic cash or whether the “money” is still at the bank and will only leave the payer’s bank at the moment of
settlement. Such discussions are interesting for economic and legal purposes. Some examples:
• Do issuers of electronic cash need to be banks in a legal sense?
• Should one get interest on electronic cash if it is actually only a representation of money in a bank account?
• Who loses the money if some devices fail?
• In the cheque-like model, is a “credit” in the usual sense given, or are you only allowed to spend as much money as you have?
However, for building the technical systems, you don’t need to decide most of this. Hence it is useful to have a more technical view without unclear notions like “money”. There are two possible things that one can consider instead: The in- and outputs to the system, or the message flows inside the system. For a high-level view, it is better to consider in- and outputs first, because individual transactions like “payment” may internally consist of an exchange of several messages. Nevertheless, in simple non-anonymous systems the message flow is typically very similar to the “money flow” above, except for the withdrawals and settlements.1 The main in- and outputs between a digital payment system and its environment are shown in Figure 17.2.
1 Actually, you can already guess that all systems except the cash-like ones can be built pretty much like their nondigital counterparts and following Figure 17.1., because the main elements are signed messages. The difference with cash is that physical cash is supposed to be hard to copy, while digital information is not. So here, even if you don’t care about anonymity, you need special measures. We’ll come back to this soon.
Version 23. März 2000 17 Payment Systems 4
Figure 17.2 Main in- and outputs of payment systems In Figure 17.
2, the bold-face inner boxes are the actual digital payment system; for illustration some environment is also shown: Often the payer and possibly the recipient program would have a direct GUI (graphical user interface), while the bank programs will interact with the old system that handles the normal bank accounts.
The most important inputs are:
• pay by a payer: Here the payer authorizes the digital system to make a certain payment.
• allow by the payer’s bank: Here the bank indicates to the digital system that the payer has enough real money that can be used for one or more digital payments.
The main outputs are:
• ok at the recipient: This indicates that he now has received money, so that he can deposit or spend it.
• subtract at the payer’s bank, which indicates that real money must in fact be taken from the payer (typically from the normal account, but it could also be cash),
• add at the recipient’s bank, which indicates that real money must be given to the recipient.
The remaining in- and outputs shown in Figure 17.2 mean the following:
• receive at the recipient is useful if he is not supposed to accept arbitrary payments made to him, in particular in systems with automatic generation of receipts.
• ok at the payer indicates that the initiated payment was successful (similar for all other transactions)
• withdraw and deposit are specific inputs of certain classes of systems (mostly cash-like) and start withdrawals and deposits.
These were the money transfer in- and outputs; there may be others for purely informational purposes (“how much money do I still have”), for general administration (initialization etc.), and for disputes.
Version 23. März 2000 17 Payment Systems 5 Now you might say that notions like “authorizes to make a payment” mean just as little as “money flow” above, and you are right. I.e., unless you add a specification with what outputs the system should react to what inputs, you haven’t gained much by considering the in- and outputs, except being nearer to an API (application programming interface). Such a specification can in fact be made for in- and outputs, see [PfWa_96], but it is still non-trivial to get complete (e.g., with all possible disputes that can occur afterwards) and anyway it would lead too far here.
Of course, before really writing such a specification, one must first define what parameters all these in- and outputs have. The most important ones are amounts of money and names of partners.
Different payment models, similar to Figure 17.1, can now be distinguished by the order in which the in- and outputs occur, in particular how they are grouped into transactions. The classes get a bit
finer than above:
• Pay-now systems have just one money-transfer transaction, called a (pay-now) payment. It is started by inputs pay, receive, and allow from the three respective participants, and yields all the four outputs (subtract and add at the two banks and ok for payer and recipient) if all inputs fitted together.
Compared with Figure 17.1, this is a subclass of cheque-like systems where the capture happens immediately, integrated with the payment.
• There are also cheque-like systems where the capture is delayed. Then one can distinguish
• reservation systems: Here allow already occurs in the payment and the money is at least temporarily reserved for this recipient (i.e., a subtract also occurs). Digitally there is then no need to wait with the deposit — there is an online connection to a bank anyway.
• pay-later systems: Here allow only occurs during the deposit. This is the class of standard credit-card systems. However, in the digital world pay-now systems would be more secure without much more trouble, because in pay-later systems the recipient has no guarantee at the end of the payment that he will really get money.
• Pre-paid systems (or “stored-value” or “cash-like”) are those with a specific withdrawal transaction. It has an input withdraw that does not specify a recipient, and leads to the outputs subtract and ok. The payment transaction has the remaining two inputs, pay and receive. We now
have to subdivide:
• In deposit-now systems, the payment transaction already produces all the remaining outputs add and ok. Real-world examples are phone cards if one distinguishes between the phone as the recipient and the phone company as the recipient’s bank.
• In deposit-later systems, the payment transaction only produces the outputs ok for payer and recipient, but not add. There is a special transaction deposit for that, where the recipient inputs deposit and the output add occurs, and ok for the recipient. Real-world examples are cash and traveler cheques.