The most common misconception in anti-counterfeit NFC is conflating "the chip has a UID" with "the chip cannot be cloned." In practice, schemes that depend only on a static UID can be copied in under thirty seconds by any consumer NFC writer. What makes NXP's NTAG 424 DNA different is not the UID — it's a mechanism called SUN (Secure Unique NFC) messages.

What a SUN actually is

A SUN is a dynamic URL parameter set generated by the chip itself on every read. It consists of three parts: the UID, a monotonically increasing scan counter (SDMReadCtr), and an 8-byte AES-128 CMAC computed over both. The result is a URL that looks something like this:

https://verify.example.com/?id=04A39B7C&c=000142&m=8B6E0AF2C914A91B

Every single tap increments c and produces a new m. An attacker who captures the URL from one tap and replays it to our verification endpoint will be rejected the moment the counter regresses — the verifier knows the previous value and refuses anything older.

Why the CMAC is unforgeable

The CMAC is computed over the UID and counter using an AES-128 master key that lives in exactly two places: inside the chip's secure element (provisioned by NXP at silicon manufacturing), and inside our HSM-backed key vault. An attacker who physically possesses the tag cannot extract the on-chip key — the NTAG 424 family is specifically designed to make that key unreadable. Forging a fresh, valid CMAC is therefore mathematically equivalent to breaking AES-128.

The verification flow

When a user taps any NFC-capable phone against a VeriTag:

  1. The phone opens the URL programmed into the tag (UID, counter, and CMAC included as parameters).
  2. The VeriScan backend looks up the AES-128 derived key for that UID in the HSM.
  3. It recomputes the expected CMAC over the UID and counter, comparing in constant time.
  4. If the CMAC matches and the counter has advanced, the system emits an authentic event. Otherwise it logs suspect.

"But what if I copy the URL?" — the common misconception

You can. Anyone can copy a URL. But the counter embedded in that URL is recorded the moment it's verified. The next request with the same counter will be rejected. A successful clone would require the attacker to predict the next CMAC — and that demands the AES-128 master key.

Why this matters for supply chain teams

Consider a pharmaceutical example: a high-value oncology lot leaves the factory. The distributor scans it once (counter = 1). The pharmacy scans it (counter = 2). The patient scans at home (counter = 3). Any counterfeiter trying to slip in a clone must use a counter value that has not yet been consumed — which is mathematically infeasible unless they also possess original silicon.

If you're evaluating an NFC anti-counterfeit solution, the first question is not "does it have a polished scan UI?" but "is the cryptographic root SUN, or just a static identifier?"

VeriScan SDK enables SUN verification by default and signs every scan event into the VeriTrace ledger. Full design documentation is available under NDA.