What a working NFC authentication system contains, and why its tag cannot be cloned or replayed

01 / FIELD NOTE

Keep the decision tied to the operating context.

Product verification by tap sounds simple until the question is made explicit: how does the phone, or the system behind the phone, know that the thing it tapped is the genuine thing rather than a copy that answers the same way? A printed mark verifies nothing, because any mark can be reproduced. NFC shifts the question into the radio domain, where the answer is a cryptographic exchange: the tag demonstrates, with each tap, that it holds a secret only the genuine tag was given. That demonstration is what the word authentication means here, and none of it is in the physical mark.

The hardware that makes the demonstration possible is a secure chip with three properties. It holds a secret key in protected storage that no interface exposes; it computes on that key inside the silicon; and it carries a permanently assigned identifier that was etched during manufacture and cannot be rewritten. Because the key never leaves the chip, copying the tag is not a matter of reading its memory — there is nothing to read. The shortest answer to "why cannot this tag be cloned" is that what would have to be copied is not stored anywhere a reader can see.

The per-tap behaviour is the second pillar, and it exists to defeat replay. If the tag always answered the same way, an adversary could record a genuine answer and replay it later, from a copied tag, and a system that checked only the answer would accept the copy. The chip answers instead with a message that changes on every tap: an internal counter increments each time the tag is interrogated, and the message is built from that counter and the current interaction. Two taps never produce the same answer, and a captured answer is already stale.

The changing answer is carried in a practical form: the tag produces a dynamic Uniform Resource Locator that embeds the authentic-looking session data of this tap, and the phone opens that address in its browser. From the phone's point of view the interaction is a tap and a page; the complexity sits in what the page's server does with the data. No application installation is required on the consumer side, which is why the mechanism can reach a market rather than a pilot.

The verification server is where the secrets resolve. The server holds the keys that correspond to the keys embedded in the shipped tags, so it can reverse the chip's computation: it reads the session data out of the address, recomputes what a genuine tag with this identifier should have produced at this counter value, and accepts only on a match. This is also the point at which a replay is caught: the server records the counter values it has already seen, and a tag that presents an old value is refused, because a genuine tag's counter only moves forward. The server, not the phone, is the party that decides authenticity.

Encoding is where the security is actually provisioned. A secure tag must be written with its key, and a system that encodes thousands of tags has to manage which key went into which identifier — a ledger that maps identity to secret, held in the server, never in the field. This is the part of a deployment that is genuinely different from writing an address to a label: the encode step creates the trust anchor of the whole chain, and a mis-keyed tag authenticates as itself forever. Provisions from factory to production line use the same mechanic — the key is provisioned once, and all later behaviour subtracts from it.

Tamper-aware variants extend the model from "this tag is genuine" to "this product was not opened". A variant tag is constructed so that opening the packaging breaks the antenna structure permanently; the next read sees a different, damaged response, and the system records a tamper event. The value is that the first-open state is carried by the physics of the tag, not by a promise in a database, so a refilled or reopened unit carries its history into its own identifier. The same per-tap protocol continues to authenticate the tag; the tamper bit is an additional fact the system reads and records.

What the mechanism cannot promise is the boundary of its own reach. The system authenticates the tag and the record it anchors; it does not photograph the product, does not confirm what surrounds the tag, and the strength of the whole chain is the weakest of its parts — a key provisioned carelessly, a batch of tags encoded with one shared secret, an integration that accepts answers without checking the counter. The question this note answers is what has to exist for a tap to mean something. The operational discipline of keeping secrets secret is the answer's unglamorous second half.