Thread by @pankaj

“Networkless Mobile Payments With Minimal Changes in Trusted Execution Environments” just got published tdcommons.org/dpubs_series/4…

So I am excited to finally talk about this foundational work that I & a small team have been doing in Google Pay along with our Android Security team.

All digital payments today are built on the fundamental assumption of Internet connectivity. Basically, every payment transaction needs to ring up one or more remote servers every time.

The server checks for stuff like fraud and double-spend and enables book-keeping and is essential for overall security. This is also true for decentralized blockchain networks. Servers and connectivity are a must.

Requiring always on Internet connectivity hampers the objectives of universal access and financial inclusion – which is rapidly becoming a top objective of central banks and govts around the world, and esp in emerging markets.

In contrast when physical cash exchanges hands, no server needs to be contacted, making physical cash a highly robust, decentralized, peer-to-peer, instant and final settlement mechanism.

If electronic payments have to realize the true vision of Digital Cash and achieve as much ubiquity and robustness, they will need to work without the Internet as well. The fintech community definitely needs to find a solution in the long term.

I and a small team have been thinking about this problem for the last 1.5+ years in the context of mobile payments. The problem is really challenging because in the absence of ability to contact a server, double spend becomes a huge, seemingly unsolvable issue.

Double Spend: You can transfer a digital packet of tokens representing cash from your phone to another’s, but as data is infinitely replicable, you can also copy the same digital tokens in your phone ad infinitum, create money at will and send to other receivers.

In the absence of a trusted remote server, something else (your phone) needs to be trusted by the payments system… But phones can be easily hacked and are not trustable. This has led folks to propose hardware only smart card type solutions.

But some (not all) modern phones also ship with hardware-backed Trusted Execution Environments (TEEs). Many sensitive applications today run in the TEE as Trusted Applications (TAs) such as DRM manager, password and biometrics manager, etc.

One approach is to put the full payments protocol in the TEE. e.g., this paper by Visa research arxiv.org/pdf/2012.08003…
But putting the entire app/protocol in TEE is infeasible IMHO – TEEs are severely memory constrained in general, and esp to minimise attack surface area.

We have been working on a different approach – one that adds new but really simple but foundational cryptographic primitives to the Android keystore / keymaster – so that the TEE changes required are minimal.

The new crypto primitives are very simple and allow new types of “Limited Use” / “Single Use” keys on which a max usage count can be set. This is enforced by hardware wherever implemented by the TEE vendor, and by Android Keystore when hardware doesn’t yet have that capability.

These APIs are now available for preview at developer.android.com/reference/andr… and will be available in Android 12 later this year. Besides enforcing no double spend, I expect these will have wide ranging use cases in other domains as well.

With these primitives, the rest of the offline payments protocol is still non-trivial (and left as an exercise to the builder). But it doesn’t have to be housed in the TEE. That makes it feasible.The overall protocol and set up was described ...

in our first publication tdcommons.org/dpubs_series/3… last year. It involves mirroring physical world use of an ATM and wallet to the digital world – you download tokens from your account when online, put them in your wallet app and then use them offline until they run out.

There is a lot more work to be done in this area and many practical questions still remain. So we are far from done. Hopefully, these primitives in Android will help everyone to build on them and “not roll out their own offline crypto protocols”.

Thanks to the team esp @dilipp and @abhibera for sticking with the problem and turning back from various false dead-ends before arriving at this simple, elegant solution. It has certainly been one of the most challenging and rewarding problems in my career.

Checkout our pub: “Networkless Mobile Payments With Minimal Changes in Trusted Execution Environments” at tdcommons.org/dpubs_series/4… for details.

To reiterate, lot more work needs to be done for full scale real-world solution, but we hope this is a significant step forward.

/fin

PS
1/ Should have done a blog post instead of a 19-tweet long tweet storm :)