Touch and go

Every time you tap your card on a London Underground barrier, something genuinely interesting happens in about 300 milliseconds. I spent several years working on that something. This is what it looks like from the inside.


The Oyster card tap. The contactless payment at a coffee shop. The phone held briefly to a reader and then away. These are interactions so smooth and unremarkable that they have become effectively invisible — part of the furniture of daily life in a way that almost nothing else involving cryptography has managed. That invisibility is, in a sense, the point. Good security infrastructure does not draw attention to itself.

I worked on contactless payment architecture for Transport for London, and the thing I find myself wanting to say about it — more than anything technical — is that the engineering underneath that unremarkable tap is genuinely worth knowing about. Not because it is flawless, but because of what it got right, and why getting it right mattered at the scale TfL operates.

What happens in 300 milliseconds

When a contactless card or device touches a reader, several things happen in rapid sequence. The reader powers the card via the electromagnetic field — the card has no battery; it is drawing power from the reader. The card and reader negotiate a protocol. The reader issues a transaction request. The card performs a cryptographic operation — signing transaction data with a key that never leaves the card — and returns a cryptogram. The reader forwards that cryptogram to the back-end for verification. The gate opens or stays closed.

All of this in under 300 milliseconds, for millions of transactions a day, across hundreds of stations, with the kind of reliability that commuters depend on in the way they depend on the trains themselves. The engineering challenge is not primarily cryptographic — the EMV standard provides the cryptographic framework — but operational: keeping the key management infrastructure, the back-end verification systems, and the reader firmware all consistent and correct at that scale.

The key that never leaves

The security property that makes contactless payment trustworthy at scale is a deceptively simple one: the card's private key never leaves the card. The cryptogram the card produces is verifiable by the back-end, but it cannot be forged without the private key, and the private key is held in hardware that is designed to be extremely resistant to extraction.

This means that a compromised reader — a reader that has been tampered with or is maliciously logging transaction data — cannot produce valid future transactions. It can observe what passes through it, but it cannot mint new valid cryptograms. The attack surface for reader-side compromise is therefore limited in a way that older magnetic stripe systems were not. A skimmed magnetic stripe gave you the data you needed to clone the card. A skimmed contactless transaction gives you a one-time-use cryptogram that is already spent.

The cryptogram is spent the moment it is verified. Capturing it in transit gives an attacker a receipt, not a key. This is the design choice that makes contactless payment scale to millions of daily transactions without becoming a fraud catastrophe.

What the scale taught me

Working at TfL scale — one of the busiest transit systems in the world, with contactless payment handling a substantial fraction of all journeys — taught me something about the relationship between security design and operational reality that I have not found in any textbook.

Security properties that are correct in theory can be undermined in practice by implementation choices made under operational pressure. Key rotation schedules that are theoretically sound become problematic when they interact with the practical realities of updating firmware on thousands of readers distributed across a city. Error handling that is technically correct can produce user-visible failures that erode trust in the system in ways that matter more than the security property it was protecting.

The most important security decisions, at that scale, are not the cryptographic ones. Those are largely settled by the standards. The important decisions are about failure modes, about how the system behaves when something goes wrong, and about how those failures are detected, logged, and recovered from. Security is not a property of the happy path.

Why the tap still interests me

I no longer work on TfL contactless infrastructure, but I still find myself noticing the tap. Not with anxiety — the engineering underneath it is genuinely good — but with the particular appreciation you develop for systems that work reliably, at scale, without drawing attention to themselves.

NFC authentication is a thread I have continued pulling in different directions since. The provenance authentication work for Whitby Jet uses the same underlying technology in a very different context. The NTAG 424 DNA chip implements AES-128 CMAC in hardware, the same family of ideas as the EMV cryptogram, applied to physical objects rather than financial transactions. The principles travel.

The tap that opens the gate and the tap that authenticates a piece of Jet are, at some level of abstraction, the same question: are you who you say you are, and can you prove it? The answer, in both cases, is a short cryptographic proof that the verifier can check without ever having seen the secret. Same question. Same elegant answer. Different context.


The PING of a contactless transaction is measured in milliseconds and secured by a key that never travels. The system works because the right secret never leaves its home — it only answers questions about itself, without ever revealing itself in full.

Three hundred milliseconds. Millions of times a day. The gate opens. The engineering underneath is worth appreciating, even if you never have to think about it again.