Inquiry Regarding NFC Tag Password Protection for NXP NTAG216

Support
1

I am currently in the process of developing an application that necessitates password protection for NFC tags, specifically working with the NXP NTAG216 tag model. In my research, I have consulted the NXP documentation, particularly focusing on the steps outlined for password protection, which include:

Packing
Setting Password
Setting AUTH0
However, I require further clarification on the transceiving process for each step. For instance, for the setPassword operation, it is my understanding that a byte array needs to be transceived, comprising elements such as the writeCommand, Block Address, and a 4-byte data sequence. I am aware of some hexadecimal commands, such as writeCommand being represented by 0xA2, but I seek detailed guidance on the specific values to be passed for each operation.

Moreover, I would appreciate additional information regarding the NTAG216 tag, such as exemplary code snippets or a more comprehensive explanation of the transceiving process. Despite consulting both the official Android documentation and the NXP documentation provided, as well as the resource available at https://dangerousthings.com/wp-content/uploads/NTAG213_215_216.pdf, I have encountered challenges in locating pertinent details.

To provide context, my development environment is Android Studio, and I am utilizing Java for programming purposes.

I would be grateful for any assistance or guidance you can offer in this matter. Thank you for your attention to this inquiry.

Sample Code:NfcA nfcA = NfcA.get(myTag);
nfcA.connect();
byte pack = new byte { (byte) 0x00, (byte) 0x00 };
byte password = {0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38};

public byte writePack(NfcA nfcA, byte pack) throws IOException {
// Prepare the command to write PACK bytes to page 44
byte command = new byte[6];
command[0] = (byte) 0xA2; // CMD = WRITE
command[1] = (byte) 0xE6; // PAGE = 44
command[2] = (byte) 0x01;
command[3] = (byte) 0x02;
command[4] = (byte) 0x00;
command[5] = (byte) 0xFF;
// command[2] = pack[0]; // First PACK byte
// command[3] = pack[1]; // Second PACK byte
// command[4] = (byte) ~pack[0]; // Inverse of first PACK byte
// command[5] = (byte) ~pack[1]; // Inverse of second PACK byte

    return nfcA.transceive(command);
}
2

Can help but curious… what’s the purpose of the password function? What’s the application? I ask because using the password feature is not actually secure… it can be easily sniffed and emulated. There are other solutions that are actually secure.

That said, it looks like you’re on the right track. Setting the password and pack is done by simply writing to those pages. This is the same process for writing to any other writable page using the A2 command.

Are you familiar with how AUTH0 and PROT work?

1 Like
3

I wanted to extend my gratitude for taking the time to respond to our previous message.

We are currently in the process of developing an application that involves the protection of NFC tags. Our primary objective is to ensure that the messages stored on these tags remain secure and unalterable. To achieve this, we are exploring the implementation of locking mechanisms on the tags. Additionally, we are keen on preventing data duplication onto other NFC tags and are considering the incorporation of a password protection feature to enhance security further. This feature would prohibit unauthorized access, including reading, writing, or copying of the data to other NFC tags.

We would greatly appreciate your insights on the various protection measures available to enhance the security of NFC tags. Furthermore, I have been reviewing documentation related to AUTH0 and PROT. My understanding is that AUTH0 manages password authentication by storing page addresses for verification purposes. Additionally, AUTH0 comprises two key components: CFGLCK, which oversees permanent locks, and AUTHLIM, which determines the threshold for incorrect password attempts before disabling password protection. As for PROT, it facilitates NFC password protection, allowing configuration for both read and write access or write-only access. However, I seek clarification on the specific values required for the transceive method, as it necessitates a byte array input.
Mainly what to pass in those byte array.

Furthermore, we are eager to explore any additional methods or strategies that could bolster the security and integrity of NFC tags.

4

It sounds to me like what you want is not really fully possible using the NTAG216 even with password features. If you want an NFC tag that is fully secured, and unspoofable so that authenticity is guaranteed, you might want to talk about VivoKey (vivokey.com/api).

I will send you a DM with details.

1 Like
5

This is not exactly true… it would prevent the most basic of users from reading data if it were protected with a password, however none of the communication between reader / phone and the NTAG2xx family of transponders is protected. It could easily be sniffed to obtain the password sent to the chip from the phone / reader, and password_ack sent back from the chip to the phone / reader.

This is why VivoKey provides a cryptographic proof that can be used by mobile apps to challenge the chip and get a response that only that chip with proper key can produce, each and every time it’s scanned.

6

Following our previous correspondence, I would like to express my gratitude for your prompt and informative response. Your insights have been immensely helpful in understanding the functionalities of NFC tags.

At this juncture, I have only two queries regarding the security features of NFC tags:

Could you please provide guidance on the process of implementing password protection for NFC tags as per our first query raised? Specifically, I am interested in understanding the steps involved in setting up and managing password protection for these tags.

Additionally, I would appreciate your insights on how to effectively disable the password protection feature of NFC tags. Understanding the procedure for deactivating password protection would be invaluable in scenarios where its application is no longer desired.

Your expertise in this matter would be greatly appreciated, and I eagerly anticipate your guidance on the aforementioned queries.

Thank you once again for your attention to this matter. I look forward to your response.

7

For NTAG216, in short;

  • the password is nothing more than a writable memory page on the chip. You write to the password memory page like any other memory page on the chip. You can never remove the password since you can’t make a memory page disappear… you can only set the password to a well known value like FF FF FF FF or 00 00 00 00.

  • the PROT bit in the CFG data determines the PROTECTION type for password protected memory pages. PROT = 0 means write protection. PROT = 1 means read & write protection.

  • the AUTH0 byte determines the memory page that password protection starts. So if you set AUTH0 to 04 then any time you try to interact with memory pages 04 through E6 (ntag216) the chip will check PROT and the command you send (read or write) and determine if PWD_AUTH needs to be successfully called before completing the command.

To set a password;

  1. Write a 4 byte value to page E5 and optionally set your PWD_ACK (PACK) by writing two bytes followed by 00 00 to page E6.

  2. PROT is 0 by default, which means write-protection. Since you want to try to protect the contents of the chip from reading, you will want to set this bit value to 1.

  3. Set the AUTH0 byte to 00 to protect the entire chip from being read (except for the UID which is part of the ISO14443A selection process, and cannot be blocked from reading).

After changing these settings, to read or write data to the NTAG216 you will need to first perform a PWD_AUTH command with the correct password. This successful authentication lasts only for the NFC session. Once the transponder is removed from the field and loses power, authentication with PWD_AUTH will need to be done again for the next session. When successful, you will be able to read from and write to all memory pages, including pages E5 and E6. Therefore, if you want to change the password at any point, you will need to first PWD_AUTH successfully, then you can write to E5 to change the password.

To “unset” the password protection, you can do this several different ways.

  1. Basic removal of password protection can be done by PWD_AUTH first, then changing the AUTH0 byte to E2. This will open the user memory pages to reading and writing, but still keep the sensitive CFG data and password pages protected.

  2. Complete factory reset will require PWD_AUTH, then writing PROT to 0, updating AUTH0 to FF, writing FF FF FF FF to E5, and writing 00 00 00 00 to E6. This will basically put your chip back to factory.

There are other considerations like protecting the CFG data and setting static and dynamic lock bits which will be important for your application, but bottom line - your application will not be secure. It will only keep untechnical but curious people from doing anything. Anyone with any technical ability will be able to break your application easily.

2 Likes