Home // About // Previous // Next

A proposal for a privacy friendly digital euro, using the existing payment infrastructure

Some years ago I wrote about privacy-friendly ticketing for public transport. Today I want to show how similar techniques can also be used to implement a privacy-friendly contactless payment system. The idea is inspired by recent payment wallets and banking apps that allow users of smartphones to make contactless payments at point of sale terminals in physical shops. The system I describe here does exactly the same, but now in a privacy-friendly fashion: it prevents banks or shops to profile you based on your payments. The core is a special wallet app on a smartphone (to protect privacy), leveraging the existing payment infrastructure (to enable a smooth and gradual roll-out of the system). In particular I would propose this as a possible implementation of the ‘digital euro’.

Outline

In the proposal to be described below, your bank or credit card company no longer sees the payments you make at a store linked to your fixed account or credit card number. Also shops no longer receive such a fixed and unique number that they could use to link all your earlier transactions. The core idea is to use your smartphone to anonymise your payments, using a special wallet app on your smartphone.

Moreover, the system is implemented in such a way that it seamlessly integrates with the existing payment infrastructure. No (fundamental) changes are necessary to the banking, payment or clearing and settlement infrastructure. Any shop that accepts contactless payments by smartphone should be able to accept anonymous payments created with this system, without any changes to their terminals or other point-of-sale equipment. As a result, the traditional chicken-or-egg dilemma that one face when entering a two-sided market (buyers need shops where they can pay with a new payment technology, but shops will not offer the option to pay with this new technology if there are no buyers that use it) disappears.

I would like to stress that this idea is very similar to earlier proposals and already existing technologies, and in that sense is barely new (except for the trick to integrate it into the existing payment infrastructure).

Preliminaries

The system relies on three different, existing, technologies: blind signatures to create unlinkable digital cash, contactless payments and tokenisation, and sender anonymous communication. These are briefly explained first.

Blind signatures to create unlinkable digital cash

Central to the system are unlinkable digital banknotes, created using a blind signature scheme. Blind signatures (originally invented by David Chaum) allow a bank to sign a digital banknote containing serial number, without learning the serial number. The signature guarantees that the banknote is authentic (and thus prevents forgery), while the blind signature guarantees privacy: when a banknote with a certain serial number is spent (the serial number is always revealed when the banknote is spent), the issuing bank does not know which of the banknotes it ever signed was the one containing that serial number. This makes it impossible for any party to link the person buying the banknote with the person spending the banknote.

To prevent someone to spend a banknote twice (after all, digital banknotes can in principle be copied many times), the merchant (accepting the banknote) must immediately deposit it at the bank in exchange for real money. The bank then registers the serial number of the banknote as spent. If another entity submits the same banknote (now being spent a second time), the bank detects this and rejects the banknote.

A concrete implementation of these ideas was already developed by Chaum’s own company DigiCash back in the ’90-ies, and now is available for online payments in GNU Taler.

Contactless payment and tokenisation

Modern smartphones have an NFC interface with which one can make contactless payments, just like one can do with contactless payment cards. A dedicated wallet app on the smartphone (the one offered by Apple or Google, so not the wallet app discussed above) is needed to perform the payment. One can put an existing credit card or link a banking card to this wallet. What happens in the background is a process called tokenisation: a payment token (as defined in the EMV standard) is created that represents the credit card or banking card. This payment token is stored in the wallet and subsequently used in later payments. Such a payment token looks like a credit card number (except that it may be slightly longer) and is issued by a Payment Token Service. This service records the link with the actual credit card or payment card, to allow a payment terminal to contact the actual issuer (bank or credit card company) to verify that a customer has enough funds for a purchase being made.

Sender anonymous communication

The system assumes the use of secure, sender anonymous, communication channels between entities. Sender anonymity means that the receiver cannot identify the sender. In practice this means the IP address of the sender is hidden from the recipient. Tor could be used for this purpose, or a system like Private Relay recently announced by Apple. The receiving end of the connection is always authenticated. Without sender anonymity at the network layer (and recall that by default the Internet is not sender anonymous), any privacy preserving protocol using this network is usually broken by de-anonymising users using this additional information at the network layer.

The system

The system works as follows. Central component is a smartphone wallet app W, that stores a certain amount of cash as these special, unlinkable, digital banknotes. The wallet app functions pretty much like a traditional wallet containing ordinary cash. The wallet does not contain any identifying information.

A user can at any time buy digital banknotes from a banknote issuer I, increasing the wallet balance, paying for them using any means of payment available. Typically this involves a banking app installed on the phone. This means that the bank knows how many banknotes you buy, and could rate limit it to a maximum amount per day. This is an important feature for regulators. Also the wallet can be programmed to not allow the balance to grow beyond a certain limit. (For this to offer any real protection, wallets will have to be certified to ensure that they actually enforce this check.)

To pay for goods in a store the user uses the wallet app, as it would normally pay contactlessly by tapping the payment terminal T with the phone. In the background, and completely transparent to both the user and the terminal, the following steps are executed.

• The terminal starts a normal contactless payment (based on the EMV standard). This sends the payment amount to the smartphone.
• The wallet checks that its balance is sufficient to pay for the requested amount.
• Using its unlinkable digital banknotes, the wallet pays the amount to the acceptor A.
• The acceptor records all banknotes it receives as spent. (Note that there is only one acceptor, keeping track of all spent digital banknotes. Expiry time on banknotes can be used to prune records from this ever-growing database.)
• The acceptor then request the Token Service Provider C to issue a fresh (never used before) payment token back to the wallet for the amount due. Think of this payment token as a one time credit card for the exact purchase amount.
• The wallet now finishes the EMV payment with the terminal using this payment token. (Note that this requires that the previous steps have been executed fast enough not to trigger any EMV payment time-out.)

While this steps are executed, real funds are transferred from the user bank account, through the payment provider bank account, to the merchant bank account. These steps are not shown in the figure.

Properties

The system outlined above has the following properties.

privacy

As the banknotes are unlinkable, created with the blind signature scheme, a banknote in a wallet cannot be linked to the bank account used to buy it. Therefore the payment token bought with these notes cannot be linked to this bank account. Hence the final payment using this payment token cannot be linked to the user making the payment. This all relies on the use of sender anonymous communication during each of these steps.

security

As banknotes are signed, they banknotes cannot be counterfeited. As they are also immediately deposited and centrally registered as spent, they cannot be double-spent.

full merchant accountability

There is no wallet-to-wallet payment: all payments exchange digital cash for a payment token, which is processed using the traditional payment infrastructure. As such, nothing changes in terms of merchant accountability (and auditability).

money laundry prevention

Because there is no wallet-to-wallet payment, wallets limit the amount of digital cash they can contain, and banks furthermore can rate-limit the amount of digital banknotes bought each day, the system proposed here prevent money laundering.

Challenges

We tried to implement a proof of concept of this idea, using the fact that both Apple and Google offer their own wallet apps, to which you can add your own credit card manually. Also, some banks and other companies offer an API for requesting a (one time) credit card, typically to be protect your privacy (and security) when making online purchases. Of course these cards are linked to an account, but if one account could issue an unlimited number of such credit cards, then this account could be the named token issuer account and we would be all set.

Unfortunately life wasn’t that simple:

1. We need access to the low-level EMV transaction between the wallet and the payment terminal to obtain the transaction amount for which a token needs to be issued
2. Manually adding a credit card cannot really be automated. There are APIs for adding payment tokens the Apple and Google wallet, but access is restricted to payment service providers.

Of course we could try to become a payment service provider recognised by Apple and Google to get access to the API. But even then there are some nasty details to flesh out. For example

• How many different payment tokens can a single issuer issue? Payment tokens look like credit card numbers, except they are sometimes 20 digits long (with the first few digits indicating the issuer). Is this enough to handle billions of transactions per day? (Yes, we want to scale ;-)
• In any case, payment tokens should have limited validity for fraud prevention purposes. (Note also how this helps recycle payment tokens.) Luckily the EMV standard specifies that this expiry time of a payment token is part of the transaction. It needs to be checked whether these are always properly passed on and verified.
• Payment is a very heavily regulated market. Can we stay under the radar? Can we afford to? Would we even want to?

A digital euro?

Perhaps not.

The European Central Bank (ECB) is looking into the development of a a ‘digital euro’, officially called a Central Bank Digital Currency (CBDC). One of the main reasons is that with the increasing use of digital payment schemes (through cards issued by private banks and credit card companies), the use of cash is declining. As a result the amount of publicly issued money (cash) in circulation is declining while the amount of privately issued money (on private bank accounts) is increasing. This threatens monetary sovereignty of the euro area.

If the provider in this scheme (issuing and accepting blind digital banknotes) would be the ECB, then in essence the digital banknotes in circulation would be the digital equivalents of traditional physical Euro banknotes issued by the ECB. And would count as public money. As a result, the decline in public money would be stopped and perhaps even increase.

In any case, the proposal presented here would ensure that the digital euro truly preserves privacy. Moreover, it would guarantee that the digital euro does not become ‘programmable’ (in the sense that the ECB or the person paying with it could determine what the money could and could not be spent on). This is an idea I would totally abhor but that apparently was floating around earlier. Luckily the ECB now agrees: programmable money is not in line with the guiding principles of the digital euro endorsed by the Governing Council.

Conclusions

We have shown how, by cleverly composing existing technologies, a contactless payment scheme can be built that is as privacy friendly as traditional cash while being as user friendly as contactless payments. And all this without changing the existing payment infrastructure.

Given the hurdles outlines above, and also because we want to preempt any regulatory pressure, cooperation with a bank, credit card company or payment service provider is necessary to make it all happen. Interested? Contact me ;-)

(Note: the ideas here can easily be extended to also implement online payments on the web.)