About a week ago I sat down with Michal Bajor, a senior security engineer at Resonance Security, to discuss things we both consider interesting topics within computing and security.
One problem we discussed was the idea of an ideal offline electronic cash from a purely technical perspective. We chose to ignore all the economic and political issues surrounding replacements Central Banks proposed for physical cash.
This article summarizes some of the things we considered. Unfortunately, I can’t remember exactly who said what, so let’s just attribute everything to both of us.
Background
One of the claims made by the European Central Bank about the digital euro, which is meant to be an electronic replacement (sorry, analog) for cash, is that “… it would be available both online and offline.”
This is not a trivial requirement. I don’t think it can be achieved.
Cash, like all physical objects, is strictly bound by the laws of physics. Objects cannot be spontaneously created out of thin air, and they can only exist in one place at a time. This much is obvious even to children, but it is a surprisingly useful feature of the real world. If have a five euro note and I give it to a shopkeeper, I no longer own it — it is in the till rather than my wallet.
Making identical copies of physical objects is hard, especially if people have spent centuries adding features to those objects to prevent casual duplication.
Another useful feature of cash is that once it has been issued and distributed, it is decentralized. If I have a five euro note in my wallet, short of a police raid, a mugging, or carelessness on my part, I get to decide when and where I transact with it. That transaction can take place anywhere — in a shop, on my driveway, or even halfway up Mount Everest.
In the digital world, on the other hand, duplication is easy. Despite numerous attempts by the music, film, and software industries using digital rights management and software keys, digital products such as mp3s, video files, and executable binaries continue to be illegally copied and shared.
This ease of copying things results in the “double spend” problem for digital money. How does one make a digital construct behave like a physical object so that only one person can own it at a time?
That is the core problem when designing and implementing offline digital cash.
Framing the problem
Before you can meaningfully discuss a problem, you need to be sure that both of you are considering the same issue under the same restrictions, and that means starting with some definitions to ensure that the digital solution has all the important features of paper notes and metal coins, while remaining digital.
It must be software-based only
The first is that the electronic cash we are considering should be electronic, not physical. That means it must be implemented in software only, so the code to hold and transact with the electronic cash can be run on standard smartphones and laptops.
This is a significant restriction, but a necessary one. If you start talking about the equivalent of scratch cards with bar codes, RFID cards with balances stored in a secure memory sector, or some kind of esoteric banknote with an embedded chip, then you are no longer talking about the kind of electronic cash Michal and I were considering.
Instead, you’re either just talking about a more complicated kind of physical cash, or you are going to require everyone to trade in their phones for new tamper-proof payment devices that will eventually be hacked.
It must work when both parties are offline
The first thing to note is that the payer does not care if the payment goes through or not. If they are buying a coffee, for example, as long as the system is accurate, the payer either ends up with a paid-for coffee, or a free coffee. The payee, on the other hand, is the party most concerned with the payment system working.
If both parties who are transacting are online, then the solution for electronic cash is technically trivial — the payer can submit their payment to the network, and the payee can then check on the network that the payment has been made. We already have such payment systems, both centralized ones (for example, payment processors like PayPal, credit card companies, or banks with their debit cards), and decentralized ones(for example, blockchain systems such as Bitcoin).
If the receiving party is online, then the solution is, similarly, relatively technically trivial. The payer can authorize the transaction offline, and the payee can present the transaction to the system on behalf of the payer, wait for it to be validated and accepted, and then verify that the payment has indeed gone through.
Again, this works in centralized systems, for example, using chip-and-pin and a point-of-sale terminal (provided the terminal is trusted), and in decentralized systems like Bitcoin where a valid digital signature on a transaction acts like a signed cheque.
If the transmitting party is online, then there are also possible solutions. Here’s a simplified explanation of one: if an offline receiver has a list of known validator public keys for a blockchain, then the online payer can submit a payment transaction, and wait until the transaction is signed by one of the validators. The payer can then present the signed transaction to the receiver, which can verify that the transaction signature is valid and made by a known validator, hence proving that the payment is valid.
Just to make it clear: we are looking for a solution that matches the diagram below, in which both the payer and the payee know that the transaction has taken place without a payment network being involved at the point of the transaction.
Note that it is perfectly fine if setting up the offline digital payment involves some online activity before and/or after the transaction takes place. The acid test is whether the two parties can walk out into the forest with no network coverage, transact, and then return to civilization safe in the knowledge that a fair value transfer happened.
Incomplete solutions
Bitcoin
Satoshi Nakamoto solved the problem of decentralized cash when connected to a computer network, namely through Bitcoin. In Bitcoin, asymmetric key cryptography is used to provide authentication for transferring digital assets from one person to another, and there is a ledger residing on a multitude of computers communicating with each other through a peer-to-peer network, with the ledger keeping track of exactly who owns what at what time.
With a market capitalization of $1.25 trillion and over a hundred million users, Bitcoin is not a failure. The problem is that Bitcoin doesn’t satisfy the offline requirement. You can present a signed transaction to the payee, but the payee needs to check the Bitcoin ledger to be sure that the payer’s Bitcoin address has enough of a balance to cover the payment.
And so although Bitcoin provides a fully software-based solution, it can only handle “payer is offline” cases at best.
Ripple’s XPOP
Ripple has presented another partial solution to offline payments, namely one where the payer is online, and the payee is not, through XPOP. There is a fair amount of misinformation online, claiming that XPOP allows Ripple to conduct fully offline transactions — it doesn’t. Instead, a more complicated version of the “payee is offline” case examined above is used.
Again, we have a fully software-based solution, but it can only handle “payee is offline” or “payer is offline” cases, but not both at the same time.
Chaumian eCash
The cryptographer David Chaum has been working on the problem of digital cash for four decades now. Although his eCash 2.0 does work offline, it manages this through the use of scratch cards with erasable bar codes on them. Thus Chaumian eCash 2.0 can manage the fully offline case but fails to meet the requirement of being software-based only.
One of the problems I immediately see with erasable bar-codes is that surveillance cameras are so good these days that a simple spycam videoing the bar code from afar before it is erased would allow a malicious third party to redeem the barcode before the merchant gets home and can do so.
That is without even considering how awkward transactions are, involving:
- connecting two phones,
- scratching off a foil covering with a coin (will people even be carrying those), and then
- licking a Q-tip you happen to have in your pocket and using it to erase the bar code.
Other partial or failed solutions
When I posted a video about offline digital cash on LinkedIn and YouTube stating the problem, I received four direct messages within a day, proposing solutions. All of them relied on:
- enhancements to physical cash (creating a digital twin in the virtual space and linking them through a bar code or something similar), or
- specific locked-down hardware, such as a trusted execution environment
The first solution seems pointless to me, as we can already use the serial numbers on banknotes to track them in databases if we want to, making the proposed improvements no more than part of the effort to reduce counterfeiting.
The second solution comes with a hefty price tag to produce and distribute new hardware to everyone. Perhaps that could be overcome by only issuing devices to people in remote areas with no mobile phone coverage, such as some of the rural counties in the UK, or the Sahara desert.
Conclusion
So, I hear you ask, what is the solution? The sad thing is, Michal and I don’t have one. And after thinking about it for a long time, I am left with the sense that truly offline digital cash could be such an intractable problem that proving it is simply not possible may be easier than trying to invent it.