​
Overview

The NTAG 424 DNA tag was designed by NXP to be a cost effective solution for product authentication. The 424s have a unique feature called SUN (Secure Unique NDEF). This means that every time you tap your phone to one of these tags, you will get a different URL. This is because on every read, the tag will encrypt new information and add this encrypted information to the URL, along with some other cryptographic data.

​
How authenticity is verified (SUN)

We use 4 parameters in the URL to verify a tag’s authenticity.
  • Tag ID - The ETRNL assigned ID of the tag
  • E-Code - A KDF input parameter used for key decryption on the server
  • Encrypted Message - An encrypted message containing the UID, counter, and nonce
  • CMAC - A mesasge authentication code that is used to verify the integrity of the encrypted data
When this data makes it’s way to the ETRNL servers, we decrypt the data to see how many times the tag has been tapped and the UID of the tag.
963352074FC3F2A3B94880BCA905FEF3
We also verify the CMAC on our servers as an additional security measure.

​
Expiring URLs

As mentioned above, the encrypted counter tells us how many times the tag has been tapped after it was programmed, and cannot be tampered with by the end user. If we store the highest counter on our database, we can compare it with the counter that a user is trying to authenticate with. So if ETRNL knows that a tag has been tapped 5 times, and a user is trying to authenticate with an encrypted counter value of 4, we can see that the user is trying to use an old URL. If we look at the table below, we can see that the visit at 3PM is inauthentic because we know the tag has been tapped 3 times, so a URL that has a counter value of 2 is behind.
TimeCounterAuthentic
1PM2Yes
2PM3Yes
3PM2No
4PM4Yes

​
Offline Storage Attack

The problem with counter based expiration is that ETRNL needs to know how many times the tag has been tapped in order to expire the previously generated URLs. So if an attacker wanted to store a URL generated by one of these tags for use later, they might be able to successfully authenticate if no one else has tapped the tag. For this reason, we don’t allow certain high security applications to be built on ETRNL at this time. If you have any questions on what is/isn’t allowed, please read our rules, or chat with us in our Discord. We are here to help and would be happy to point you in the right direction for your application if the 424 tags don’t offer the best solution.

​
ETRNL’s fraud detection system

This is still a work in progress feature, but We’re currently building a system that uses time-based data points combined with tags specific information to detect fradulent authentication using one of these offline URLs. The API will notify clients when the system has detected unusual traffic or suspicious activity, and you can tell the user that they need to tap the tag again to get a new URL.