Direct answer

A technical guide to NTAG 424 DNA Secure Dynamic Messaging, AES-CMAC verification, counters, key management, provisioning and anti-counterfeit design.

Where NTAG 424 DNA fits in the NXP portfolio

NTAG 424 DNA is a secure NFC Forum Type 4 Tag IC intended for interactions that need more than a static identifier. It combines an ISO-DEP interface, an application and file model, AES-based security and dynamic data that an ordinary phone can carry to a verification service.

Product distinction
Unlike NTAG21x labels, the secure workflow is built around files, keys and authenticated configuration rather than a flat public Type 2 memory area.
System requirement
The chip is one component of an authenticity system; secure provisioning, backend verification and incident handling are equally important.

Files, applications and AES keys

The chip exposes an application selected through ISO 7816-4 style commands and contains files whose read, write and change permissions are configured against key numbers. Production design assigns separate duties instead of relying on one shared factory secret.

Least privilege
Separate configuration, SDM read and administrative roles so a service that verifies taps does not automatically gain permission to reconfigure tags.
Key versions
Track key version and batch provenance outside the tag to support controlled rotation, investigation and decommissioning.

Secure Dynamic Messaging and mirrored data

Secure Dynamic Messaging can place dynamic values into an NDEF-facing URL while the physical message template remains on the tag. Depending on configuration, the URL may carry encrypted PICC data, a read counter and a message authentication value.

Per-tap signal
Dynamic output gives the verifier changing evidence instead of the same static URL on every read.
Configuration accuracy
Mirror offsets, file boundaries and encoding format must match the backend parser exactly; a one-byte mistake produces consistent verification failure.

What SUN means in an authenticity flow

SUN is commonly used for the tap-unique secure messaging pattern associated with these tags. The browser or Android app submits the dynamic URL values, and the trusted backend validates them with key material that is never placed in the public page or mobile client.

Not visual proof
A URL that looks like an SDM link is not evidence by itself; only successful cryptographic verification under the correct key establishes the result.
Result context
The verifier should return a reasoned state such as genuine, suspicious replay, unknown tag, malformed request or temporarily unavailable.

AES-CMAC and session-derived verification

CMAC provides message integrity and authenticity under an AES key. NXP's application guidance defines how session material and MAC input are constructed; implementers must follow the specified byte order, truncation and counter representation rather than inventing a similar-looking hash.

Known vectors
Automated tests should include vendor or independently verified vectors and fail when any UID, counter, key, offset or MAC byte changes.
Constant-time comparison
Backends should compare authentication values without data-dependent early exits and must avoid logging secrets or derived session keys.

Counters and replay detection

A read counter helps a backend notice a previously accepted URL being presented again, but real products need policy around normal retries, shared links, clock skew and offline scans. A higher counter is evidence to evaluate, not a complete risk decision by itself.

State model
Store the highest trusted counter and recent verification context per provisioned tag, then distinguish harmless duplicate requests from impossible or high-risk sequences.
Privacy limit
Retain only the event data needed for fraud analysis and explain any location or device signals separately from cryptographic verification.

Provisioning secure tags in a controlled station

Provisioning writes file settings, mirror configuration and diversified keys before the label enters the supply chain. The station needs authenticated operator access, protected key delivery, verify-after-configure checks and a quarantine route for uncertain tags.

Per-tag keys
Derive unique keys from a protected master or approved key service so one compromised tag does not reveal a universal production secret.
Audit record
Record batch, tag reference, configuration version and verification result without exporting plaintext AES keys.

Backend verification architecture

The public endpoint parses a strict allowlisted parameter set, locates the tag record, derives or retrieves verification keys inside a protected boundary, validates the MAC and applies replay and product-status policy. The response exposes a user-safe result rather than cryptographic internals.

Abuse controls
Rate limiting, request-size limits and generic error responses prevent the verification endpoint from becoming a key oracle or logging sink.
Availability
If the backend is unreachable, NFCMagic should show pending or unavailable and queue only authorized retry data, never label the product counterfeit by default.

Originality signatures, SDM and tamper are different signals

An originality signature can support chip-origin checks, SDM authenticates dynamic data, and a TagTamper variant reports a physical seal state. Product UX should explain which signal passed instead of collapsing every capability into one green badge.

Layered verdict
Combine chip, cryptographic message, product registry and optional tamper state into an auditable decision with distinct reason codes.
No absolute guarantee
A genuine tag can be moved to counterfeit packaging, so physical integration and supply-chain controls remain part of the threat model.

Manufacturing and field use cases

Secure NFC labels appear in premium goods, pharmaceutical packaging, parts, collectibles and warranty programs where a consumer phone must reach a verifier. Antenna design, adhesive, tamper construction and production yield determine whether the cryptography remains usable in the field.

Pilot production
Provision and destructively inspect a sample batch across intended materials before committing keys and artwork to full production.
Field response
Define what support, reseller and brand-protection teams do when a valid tag appears on the wrong product or an abnormal counter pattern emerges.

Quick reference

Signal Answers Cannot answer alone
Originality signature Is this consistent with a supported chip origin? Is the whole product genuine?
SDM CMAC Was dynamic data produced under the expected key? Was the tag moved to another item?
Read counter Does scan sequence look plausible? Who performed the scan?
Tamper status Has the configured seal state changed? Why or when it changed

Related NFCMagic app screens

These screenshots connect this NTAG 424 DNA SUN CMAC guide to the related Android workflow in NFCMagic. They document interface states; radio behavior still requires a physical Android device and real tags.

NFCMagic product authenticity result screen for NTAG 424 DNA verification
The app separates genuine, counterfeit, pending and tamper outcomes instead of treating every network or parsing failure as fraud.
NFCMagic NTAG 424 DNA provisioning screen for secure URL mirrors and AES key setup
Provisioning is an operator workflow for real secure tags and must be verified on authorized physical hardware.

Frequently asked questions

Does NTAG 424 DNA work without a backend?

A phone can read its public NDEF URL, but meaningful SDM authenticity verification requires trusted key material and verification logic outside the public client.

Is CMAC encryption?

CMAC authenticates message integrity under a key. Encryption and MAC protection are separate choices in the secure messaging configuration.

Can the same AES key be used for every tag?

A shared key increases blast radius. Production systems should use approved key diversification and protected key management.

Does a valid secure tag prove the package is genuine?

It proves the checked cryptographic signal. Physical attachment, supply-chain state and replay policy are still needed for a product verdict.

Primary technical sources

  1. NXP: NTAG 424 DNA data sheet — Primary product specification for the secure NFC Forum Type 4 Tag IC.
  2. NXP AN12196: NTAG 424 DNA features and hints — Implementation guidance for Secure Dynamic Messaging, keys and session MACs.
  3. Android Developers: Android Keystore — Official key-storage model and hardware-backed protection guidance.