«Payment Systems (Ch. 17 of Course Material “Security”) Birgit Pfitzmann Dept. of Computer Science Saarland University pfitzmann ...»
We add the following measures:
a) Withdrawal order: We require that the withdrawal order, i.e., the message in Step 3 of the withdrawal, is signed and includes the coin. (To protect only from attacks by outsiders, a similar order with symmetric authentication would be sufficient.) Hence it might be sign(skaccount, (“coin withdrawal”, N, seq_no, amount, blindcoin)), where skaccount is a non-anonymous key belonging to the account number N, and seq_no a sequence number.
In a dispute about a statement subtract on the account, the bank has to show this withdrawal
• If the payer claims that this withdrawal order is replayed, the dispute can be solved with the sequence number like any other dispute about a normal account (see Section 9.3).
• If the payer claims that the bank did not sign the coin, the bank has to sign it again and send blindsig via the court to the payer. The court tests the signature.10
b) Coin keys: What can we do if the bank refuses to deposit a coin, saying that this coin is already in the database, but the payer disagrees and says he never spent it before? The bank might have to prove that the coin’s value was added to some account, but what if the payer says this is not the recipient for whom he intended the coin? The problem is that a possibility for the payer is missing to specify the destination of a coin in an unforgeable way. (Clearly he cannot sign this under his normal identity because the payment should be anonymous.) The solution is to introduce “coin keys”, i.e., a specific key with which only the owner of the coin can sign. (This is similar to the pseudonyms under which one owns standard values in
Section 17.3.2.) Hence we modify the protocols as follows:
• gencoin: We choose coin as the public key of a signature scheme, say (skcoin, pkcoin) ← gensig(l); coin := pkcoin.
• Payment: In Step 7, the payer not only sends (coin, sig), but also a transfer order, e.g., sign(skcoin, (“pay”, NR, “for”, ref)).
Here NR is the account number of the recipient, and ref may be some reference string used to link this payment to something else (as a precaution for disputes between payer and recipient).
No freshness measure is necessary because each coin is only spent once.
Both the recipient in Step 8 and the bank in Step 9 can verify this signature with respect to coin = pkcoin.
c) Deposit confirmation: In Step 10, the bank not only tells the recipient the result, but gives a signed deposit confirmation (containing the coin, the transfer order and the current time).
In a dispute, the bank can now prove any earlier deposit of a coin using the transfer order. This is secure for the payer if the signature scheme is secure, because he never reveals any information about skcoin except for this one signature.
The scheme is also secure for the recipient because he only gives out a receipt or goods after Step 11, and at that time he has the deposit confirmation which he can use if the money is not added to his account.
If the recipient refuses a receipt, the payer can get (and even enforce) a confirmation by the bank that his coin was deposited. If it was not, he can at that point pay it to himself instead.
D. Recipient Anonymity We now show how to modify the scheme such that it provides recipient anonymity instead of payer anonymity. The basic idea is that now the recipient must transform the coin. Figure 17.6 shows the resulting scheme. It is very similar to Figure 17.5, only coin generation, blinding and unblinding have been moved from the payer to the recipient. The payer simply forwards the blinded coin to the bank (Steps 3-5) and the blind signature back (Steps 7-9). The bank does not notice the difference at all.
Version 23. März 2000 17 Payment Systems 24
Figure 17.6 Basic blind RSA signatures used for recipient anonymity
Properties of the scheme are:
• It is not prepaid, because the payer does not know in advance to whom he will pay (compare “universality” in Section 17.1.1D).
• To avoid linking by the times of withdrawal and deposit, the recipient should therefore defer the deposit. As he is now the only person knowing the unblinded coin, the payer cannot doublespend it in the meantime. In terms of Section 17.1.1B, we therefore get a reservation system (which made not much sense without the anonymity).
• To provide security in disputes about deposits, the recipient should again produce the coin with a coin key.
E. Maximum Anonymity We now show that one can combine the different types of anonymity of the schemes from Section 17.3.2 and 17.3.3A-D into a scheme where nothing at all is linkable (beyond what is naturally linked by events outside the payment scheme).
The basic idea is not to pay a received coin into an account, but to immediately exchange it for a new coin. Technically, this is based on the recipient-anonymity system.
We will immediately look at a payment, assuming that the payer P has an undeposited recipientanonymous coin (as in Subsection D) with a coin key. Let us call this coin1 := pkcoin,1 with the secret coin key skcoin,1 and the signature sig1.
Version 23. März 2000 17 Payment Systems 25
• The recipient generates a new coin, i.e., a key pair (skcoin,2, pkcoin,2). He sets coin2 := pkcoin,2, blinds it into blindcoin2 and sends this to the payer.
• The payer, instead of a deposit order for his old coin to an account, signs an exchange order, e.g., sign(skcoin,1, (“exchange”, blindcoin2)).
• Upon receiving (coin1, sig1) and the exchange order, the bank makes the usual tests: It verifies both signatures (i.e., that the coin is valid and the exchange order was given by the coin owner) and checks in its database that the coin was not deposited or exchanged before. If all is ok, it gives a signature blindsig2 on blindcoin2 and sends this back to the payer.
• The payer now forwards blindsig2 to the recipient, who can unblind it. Then he is in the same situation as we assumed before a payment.
Now there is neither the linkability between successive owners of the same coin that existed with standard values, because the coin is exchanged in each step, nor does all money have to be paid into an account between any two payments. (Hence this is more like metal coins, while standard values were more like banknotes and “coins” with blind signatures have no real analog among classical payment systems.) Note, however, that everything is still online to prevent double-spending. Hence there is not the full independence that one was used to with metal coins (pocket-money, tips etc.).
One can also use exchange transactions to change one coin anonymously into several coins of smaller value or vice versa.
Version 23. März 2000 17 Payment Systems 26 17.4 Non-Anonymous Offline Systems As explained in Section 17.1.1.D, the main problem with offline operation is to prevent or handle doublespending. Typical non-anonymous offline systems rely mostly on (hopefully) tamper-resistant user devices, e.g., smartcards, for this purpose.11 Then the “electronic money” on the user devices does not need a complicated representation like coins, but can simply be held in a balance variable.
Thus the user device is a bit like a “pocket bank” handling one electronic account and taking care that only permitted operations on the account are carried out.
In addition to the tamper resistance, the devices also need cryptography because they must recognize when they talk with other secure devices and are therefore allowed to change their balance.
The main disadvantage is that tamper resistance is very doubtful, see Chapter 12. Another disadvantage is that two different parties, the user and the bank, must trust in the same user device.
For instance, the banks might prefer the design to be secret, while for the users’ security public verification would be better.
17.4.1 With Signatures Conceptually, the easiest way to realize a balance-based system is to use a signature system [EvGY_83]: Each device D generates a key pair (skD, pkD). The bank gives an attribute certificate certD on pkD with an attribute like “this is one of my secure devices”. For the offline operation, each device contains its own certificate. Each device has a balance balD initialized with 0.
• In a withdrawal, the device gets a signed fresh message (e.g., using a nonce) from the bank that it can now increase its balance, e.g., m = sign(skB, (“increase”, D, nonce, amount)).
• In a payment, the main message m is from the payer’s device P to the recipient’s device R. It contains the identities of both devices and the amount x of the payment. Again, a freshness measure is necessary. E.g., in a prior message, R could send P its identity and a nonce, and then m = sign(skP, (“pay”, P, R, nonce, amount)).
It must also attach the attribute certificate certD.
Before sending off m, the payer’s device P sets bal P := bal P – x. After receiving m, the recipient’s device R sets balR := balR + x. This must happen in this order; otherwise the two parties could deliberately lose the message to increase their joint amount of money.
We don’t go into details of enforcing receipts and of disputes about withdrawals and deposits here.
This is a prepaid deposit-later system (like all offline systems). It can be transferable without additional cryptographic problems, i.e., devices may be used for both paying and receiving, and received money can be added into the same balance from which one pays.
1 1 There are almost no proposals that one should entirely rely on punishing double-spenders afterwards. One reason is that in particular in a network scenario, one can do a lot of double-spending in a short time. Another is that most of the systems are not entirely secure against theft (of a computer or card), and measures against double-spending typically also limit the amount a thief can spend.
Version 23. März 2000 17 Payment Systems 27 One well-known system in field trials might be of this type, Mondex. They keep their specifications secret, even the high-level descriptions. It is assumed that the field trials are simple systems as in Section 17.4.2., but that they hope to progress to an asymmetric system because they at least considered transferability by giving the users not only smartcards, but real devices that can interact. The EMV (Europay, Mastercard, Visa) standardization efforts for an offline systems allow either signatures or symmetric systems, but they do not define a full system. The implementation CLIP by Europay is asymmetric.
17.4.2 With Symmetric Authentication In practice, the typical offline systems do not yet use signatures, but only symmetric cryptography.
Apart from the standard disadvantages of offline systems that there are no proofs, this leads to a technical problem: How can one distribute the keys?
a) One can give all the devices the same key. If the devices really were perfectly tamper-resistant, this would be no problem. (E.g., the payment messages similar to Section 17.4.1 contain the device names, hence a cheating user cannot make two devices increase their balance by sending the same message to both of them. Actually, even nonces alone would ensure this.) However, nobody trusts at least smartcards that much.
b) It is not possible to have a different key for each pair of devices (as one would usually expect in a symmetric system): All payer devices should be able to talk to all recipient devices. This is offline, so one cannot use the standard technique with a central server and master keys (see Section 8.2.1). And there are so many devices that one cannot assume that the keys are distributed in advance.
c) Hence the usual solution is as follows: The recipient devices (point-of-sales terminals, more expensive and hopefully more tamper-resistant) all get the same key K, which is called a master key. However, the payer devices are not allowed to see K. Instead, each one has its own device key kD. The trick to allow these devices to communicate is to derive the device key kD from the device number nD with a secret operation involving the master key, e.g., f(K, nD) where f is a one-way function. (A pseudo-random function seems useful cryptographically.) Hence each recipient device, once it gets the number nD of a payer device, can use the master key to derive kD. Then they can use kD to communicate securely in the usual way (i.e., a symmetric version of Section 17.4.1).
This solution was adopted in most trials with smartcards (e.g., Danmønt and Proton) and standardized as “CEN Intersector Electronic Purse” (CEN is a European standardization organization, composed of national bodies like DIN). The German Geldkarte is such a system.
Obviously the systems with master keys only in special recipient devices cannot be transferable.
Hence it is assumed that Mondex (cf. Section 17.4.1) had the same key in all devices and that this is why they kept the design secret.
17.5 Anonymous Offline Systems Now we combine both technical difficulties, anonymity and offline operation.
Version 23. März 2000 17 Payment Systems 28 17.5.1 Relying on Tamper-Resistance If one fully relied on tamper resistance, one could use the system from Section 17.4.2a, where all devices have the same key. If they also have no numbers etc., such a system can be anonymous.
(Recall that unique use of a message “pay” can be guaranteed by nonces alone.) However, as mentioned above, one typically does not trust the devices so far, i.e., one wants to have some fall-back mechanism by shadow accounts where the bank monitors the balance on each card in order to detect doublespending. This means that whenever the devices have contact with the bank (for withdrawals or deposits), they send all their transaction records to the bank, who sorts them by accounts and checks whether no device spent more money than it withdrew. This cannot be done without device identifiers.
Anonymity also aggravates the problem with tamper-resistant devices that the banks might want to keep the design secret — how does one know that the devices do not contain trapdoors that transfer the identity after all?