Part 1 described what happens during the NFC handshake: the RF exchange, the challenge-response, the key-never-transmitted design. This part is about what the successful completion of that handshake proves — and, equally importantly, what it does not prove. Both parts of that question matter for a correct security analysis.

A CMAC verification succeeds when the responding device correctly computes the CMAC over the challenge using the correct key. This proves one thing: the responding device holds the key. It proves nothing about the identity of that device beyond its possession of the key. This is not a failure of the protocol — it is a statement of scope. The authentication scheme is designed to prove key possession. It should be evaluated as such, not as something it was not designed to do.

What replay protection actually prevents

The counter on an NTAG 424 DNA tag increments with each successful authentication. The reader checks that the counter presented by the tag is greater than the last value it recorded for that tag identifier. A tag that presents a previously seen counter value fails authentication.

This prevents replay attacks: recording a valid authentication exchange and replaying it later. The replayed message carries the counter value from the original exchange. That value is lower than the current counter. Authentication fails.

What counter replay protection does not prevent: an attack where the adversary interrupts the original exchange before the counter increments, captures the challenge-response pair, and presents it before the legitimate tag uses it. Whether this attack is practically possible depends on the implementation's handling of incomplete transactions — whether the counter increments on authentication attempt or on successful transaction completion — and on the timing of the capture.

What cloning means for NTAG 424

Cloning a tag that uses AES-128 authentication requires cloning the key. The key is stored in the tag's secure memory and is not transmitted during any operation the tag is designed to perform. Extracting the key would require either a successful cryptanalytic attack on AES-128 (which is not a realistic near-term threat) or a hardware-level attack on the tag itself — decapping, probing, fault injection.

What this means in practice: the cloning attack model for NTAG 424 is categorically different from the cloning attack model for tags that use only UID-based authentication. A UID can be observed by anyone with a reader and replicated by any tag that allows UID reprogramming. An AES key cannot. This is not an absolute barrier — physical attacks on hardware are a real category — but it is a meaningful change in the required capability.

Honest limitations

The design is strong for what it does. It is worth being precise about what it does not do. It does not prevent an attacker who has already obtained the key — through a compromised reader, through a supply-chain attack on the personalisation process, through any means other than directly attacking the tag — from producing a device that will authenticate successfully. Key management is outside the scope of the tag's authentication scheme. The tag proves that whoever has it holds the key. The system's security depends on who holds the key being who you think it is.

This is not a criticism. It is the correct scope for this layer of the system. Every cryptographic protocol has a security model that specifies what it protects and what it assumes. Reading the NTAG 424 authentication scheme as a component of a larger system requires understanding both what the component proves and what the system outside the component is responsible for ensuring.

The NFC handshake sends a PING and waits for the right answer. When the answer arrives correctly, it proves that the right key is present. Everything else — whether the key was obtained legitimately, whether the counter is being managed correctly, whether the system around this exchange is sound — the handshake cannot tell you. That is what the rest of the architecture is for.