There are two fundamentally different things sold under the label “NFC tag.” One stores a fixed URL that any counterfeiter can copy in 60 seconds. The other generates a unique cryptographic fingerprint on every single tap, one that changes each time, is tied to the chip’s secret key, and that a backend can verify instantly. Here is what that actually means, technically.
The Core Distinction: Static Storage vs Dynamic Cryptographic Output
A basic NFC tag is essentially a small read-only memory chip with an antenna attached. It holds a data record — usually a URL — and transmits it to any reader that comes within range. The output is always the same. It has no concept of time, identity, or sequence. This makes it trivially clonable: read it once, write the same URL to a blank NFC sticker, and the new tag is functionally indistinguishable from the original.
A secure NFC tag has an onboard cryptographic engine. On every tap, it generates a fresh output that is mathematically derived from its secret key, its unique chip identifier, and an internal tap counter that increments with each interaction. The output cannot be predicted without the key. It cannot be replayed — the counter ensures yesterday’s output is invalid today. And it cannot be reproduced by copying the chip — the secret key is stored in protected memory that cannot be externally read.
The right mental model: A basic NFC tag is like a door with a key hanging next to it. A secure NFC tag is like a door that generates a new one-time code every time you approach it — and the only way to generate the right code is to already be inside. The code itself reveals nothing about how to generate the next one.
How App-Less NFC Authentication Actually Works: The SUN Model
In brand protection deployments, NFC authentication needs to work without any app download — the consumer simply taps the product with their phone and the browser opens a verification page. Understanding exactly how this works technically is important because it differs from the “reader-issued challenge-response” model that is common in contactless payment and access control.
The mechanism used for app-less web NFC authentication is called SUN — Secure Unique NFC message generation (also marketed as SDM, Secure Dynamic Messaging, by some chip vendors). The chip itself generates the dynamic authentication data, appended to a URL, which the phone opens as a normal web link. The browser never sees a cryptographic exchange it just opens a URL. The security work is done by the chip before the phone is even involved, and validated by the backend after the URL is received.
Step 1: Tap detected, dynamic URL constructed
When the phone’s NFC field powers the chip, the chip constructs a dynamic URL by appending a Secure Unique NFC (SUN) message to a base URL configured at provisioning time. The SUN message contains three components derived from the chip’s internal state: the chip UID (its fixed identifier), the current tap counter value, and an AES-CMAC — a cryptographic authentication code computed over those values using the chip’s secret key.
Step 2: Phone opens the URL in the browser
The phone reads the NFC data record and opens the URL in the default browser — the same action as scanning a QR code. No app is launched, no APDU exchange takes place, and no cryptographic operation runs on the phone. The phone is simply a transport layer: it receives the dynamic URL from the chip and passes it to the backend over HTTPS. The security work is entirely on the chip and the backend.
Step 3: Backend validates CMAC and counter
The backend receives the URL parameters and performs two checks. First, it looks up the secret key associated with the received UID and independently recomputes the expected CMAC over the UID and counter values. If the recomputed CMAC matches what the chip sent, the message is cryptographically authentic — only a chip with the correct secret key could have produced it. Second, it checks that the counter has advanced beyond the last recorded value for this chip, confirming the tap is fresh and not a replayed old message.
Step 4: Verification result and scan event logged
The backend returns a verification result to the browser — authentic, tampered, or unknown — along with any product content the brand wants to display. It also logs the scan event: chip UID, counter value, timestamp, and location data where available and consented to by the user. This scan event record is the source of grey market detection intelligence and first-party behavioral data.
What the phone does and does not do: The smartphone in app-less NFC authentication is a passive relay. It powers the chip via the RF field, receives the dynamic URL the chip generates, and opens it in a browser. No cryptographic operation runs on the phone. No challenge is generated by the phone. The security properties come entirely from the chip’s key-protected computation and the backend’s validation not from anything the phone contributes.
What the Chip Actually Computes: Inside the AES-CMAC
A 128-bit symmetric secret key stored in protected memory on the chip. It is used by the AES engine to compute the CMAC but is never included in any output. The key cannot be read through the NFC interface. Because it is symmetric — the same key held by the chip and the backend — it is correctly called a secret key, not a private key. Private and public keys are concepts from asymmetric cryptography (ECC, RSA); AES-128 uses a shared symmetric secret.
Chip identifier, binds the message to this specific chip
The chip’s unique identifier, assigned at manufacture. Including the UID in the CMAC input ties the authentication message to one specific chip — a CMAC generated by chip A cannot be mistaken for a valid CMAC from chip B, even if both use the same key. In practice, each chip has a diversified key (derived from a master secret and the UID), so the keys differ anyway.
Monotonic tap counter, prevents replay of old messages
An integer stored on the chip that increments by one on every tap. Including the counter in the CMAC input means every tap produces a different CMAC, even from the same chip. Crucially, the backend checks that the counter value received is greater than the last counter value it recorded for this chip. This prevents replay attacks: a captured URL from a previous tap carries an old counter value that the backend will reject.
The authentication tag, what the backend validates
AES-CMAC (Cipher-based Message Authentication Code) takes the input data and the secret key and produces a fixed-length output — typically 8 bytes (64 bits) truncated from a full 128-bit AES block for URL efficiency. This output is unpredictable without the key, different on every tap (because the counter changes), and verifiable by any party holding the same secret key. It provides integrity and authenticity: the backend can confirm both that the message has not been altered and that it came from a chip with the correct key.
Why “cloning” a secure NFC tag is cryptographically infeasible: To clone a secure NFC tag — to create a tag that generates valid SUN messages — an attacker needs the chip’s secret key. The key is stored in protected non-volatile memory on the chip with no external read interface. Without the key, an attacker can copy the chip’s static UID and a previously observed counter value, but cannot compute a valid CMAC for any new counter value. The backend rejects any message where the CMAC does not match the expected value for the current counter, making even a partially cloned tag immediately detectable.
The Four Security Properties That Matter
- Tap Uniqueness
Because the counter increments on every tap and is included in the CMAC input, every tap generates a different authentication message. There is no single “correct response” a counterfeiter can memorise, photograph, or copy. Even recording thousands of genuine tap outputs does not help — the next output will be different. - Replay Prevention
The backend tracks the last-seen counter value for every chip. A replayed message — the URL from a previous tap sent again — carries the old counter value and is immediately rejected. The counter only ever increases, so there is no valid previous state that a replayer can exploit. - Key Non-Extractability
The secret key is stored in protected memory with no external read interface. There is no NFC command, maintenance protocol, or debug mode that outputs the key. Physical extraction attempts — decapping, microprobing — are addressed by the chip’s hardware design, though the specific countermeasures vary by chip family and should be verified against the chip’s published datasheet rather than taken on vendor claims alone. - Binding to a Specific Chip
The UID is included in the CMAC input and the key is typically diversified per chip (derived uniquely for each UID). This means a CMAC from chip A is not a valid CMAC from chip B. A counterfeiter cannot produce valid messages for any chip except one where they already hold the specific secret key.
What Secure NFC Does Not Protect Against — and What Does
Relay attacks
An attacker places one device near a genuine chip and another near a verification reader in a different location, proxying the interaction in real time. The genuine chip generates a valid SUN message; the attacker relays it before the counter becomes stale. The cryptography validates correctly because it came from a real chip — the attack bypasses chip security entirely.
System-level mitigation: Location data (where consented and available — browser geolocation is not guaranteed and requires user permission), timing analysis, and velocity checks can flag implausible interactions. NFC’s 4 cm read range creates a practical constraint: relay attacks require physical proximity at both ends simultaneously.
Rather than cloning the cryptographic identity, an attacker physically removes a genuine NFC chip from an authentic bottle and embeds it into a counterfeit one. The chip is genuine, generates valid SUN messages, and passes authentication — because it is the real chip.
System-level mitigation: Tamper-evident integration — where the chip carrier destroys the chip circuit on removal, as in Selinko’s tamper-proof NFC solution — makes physical chip transplanting detectable or operationally impractical. The chip must be permanently bonded to the product it authenticates.
Backend compromise or key management failureIf the secret keys stored in the backend are compromised — through a server breach, insecure key handling, or insider access — an attacker with the keys can generate valid SUN messages without any chip. The chip’s cryptographic security is only as strong as the key management practices around it.
System-level mitigation: Secret keys stored in and operated by Hardware Security Modules (HSMs) — dedicated cryptographic appliances that perform AES operations internally and never expose key material to the application layer. Access controls, audit logs, and key diversification (unique keys per chip, derived from a master secret) limit the blast radius of any single compromise.
Grey market diversion of genuine products
A genuine bottle with a genuine chip, sold outside its authorised channel, will authenticate as genuine — because it is. Chip cryptography cannot distinguish an authorised sale from an unauthorised one. Grey market diversion is a logistics and commercial problem, not a cryptographic one.
System-level mitigation: This is where the scan event record earns its commercial value. Geographic scan data — where available and consented — combined with territory allocation records at the backend, enables detection of scan patterns inconsistent with authorised distribution. The chip’s SUN messages generate the data; the backend’s intelligence layer reads the pattern.
Key Management: What Actually Determines Long-Term Security
- Provisioning
Keys written at manufacture under controlled conditionsSecret keys are written to chips during manufacturing in a controlled environment. The provisioning process uses a secure channel between the key management infrastructure and the chip. After provisioning, the key cannot be read back through any interface.
- Diversification
Unique key per chip, limits compromise scopeRather than one master key across all chips, each chip receives a key derived from a master secret and the chip’s UID. If a single chip’s key is ever compromised, it does not affect any other chip in the deployment. The master secret remains in the HSM; individual chip keys are derived on-demand during validation.
- Backend storage
Hardware Security Modules, keys never in plaintext in application layerSecret keys are stored in and operated by HSMs — dedicated hardware that performs cryptographic operations internally and never exposes key material to the application server, operating system, or network. A breach of the application layer does not expose keys because they are never present there.
- Key rotation
Possible in some configurations but operationally hard at scaleSome chip families support updating the secret key over a secure NFC channel using an existing valid key. This is technically possible but operationally challenging across large deployed populations — it requires every chip to be tapped through a secure update process. It is a real capability in specific configurations, not a standard operational practice for most brand protection deployments at scale.
What to Actually Verify When a Vendor Claims "Secure NFC"
- Does the chip generate a different output on every tap?
If the URL or data transmitted by the chip is the same on every read, it is not using dynamic cryptographic authentication. Ask to tap the same chip twice and compare the outputs. - Does the chip use AES-CMAC or equivalent for the dynamic message?
Ask specifically. “Encrypted” and “secure” are not synonyms for AES-CMAC-based SUN generation. Ask which chip family is used and look at its published datasheet. - Does the backend validate the CMAC on every tap or only on first registration?
Validation only at registration leaves the system vulnerable to replay attacks after that point. Every tap should validate the full CMAC and counter state. - How does the backend detect counter anomalies?
What happens when the same chip UID is submitted with a lower-than-expected counter? The backend should reject it as a potential replay and flag it — not silently accept it or simply log it without alerting. - Where are the secret keys stored in a database or an HSM?
Keys in an application database are one breach away from a systemic compromise. HSM-backed key storage is the correct answer. - What is the chip certification?
Ask for the chip manufacturer’s datasheet and the relevant security certification. Claims about tamper countermeasures should be verifiable against the chip family’s published security documentation, not taken solely from vendor marketing materials. - Does the GPS / location claim require user consent?
Browser geolocation requires explicit user permission and is often unavailable or low-precision. Location intelligence in scan events should be stated as “where available and consented” any vendor claiming automatic GPS on every tap is overstating what the web platform provides.
How These Security Properties Translate to Brand Protection Value
- Counterfeit Resistance: Cloning the cryptographic output is infeasible. A fake tag cannot generate valid SUN messages without the chip’s secret key.
- Replay Prevention: Counter-based freshness detection means a captured URL from a previous tap is rejected on resubmission to the backend.
- Grey Market Intelligence: Each validated scan event creates a timestamped record. Patterns in scan location data where available and consented, surface diversion routes.
- Tamper Detection: With tamper-proof NFC integration, physical interference with the closure registers a permanent event in the chip’s state, detectable on the next scan.
- Provenance Record: The scan event log attached to each UID builds a verifiable history useful for fine wine, collector spirits, and resale authentication.
- No App Required: SUN-based authentication works entirely in the browser. The consumer taps, the phone opens a URL, the backend validates with zero friction, zero install.
NFC Security That Holds Up to Technical Scrutiny
Selinko’s platform is built on SUN-capable NFC chips, HSM-backed key management, and real-time backend CMAC and counter validation including our tamper-proof NFC solution for wine and spirits brands where physical interference is the primary threat.
Get in Touch
