For some background, I've somewhat recently received an xNT device with the intention for using it as a authentication device for an NFC access controller I'm building. I've used the Dangerous Things android app to "secure" my chip, and have been able to read/write via an Android NFC app. I'm currently using a Mihappy RFID Sensor, since I already had one laying around. It seems to work with regular NFC smartcards, but has not yet been able to read my tag. I'll be testing a ITEAD PN532 NFC Module next. These will be used in tandem with an Arduino or Raspberry Pi, etc.

Now for the real question! As for the actual authentication, my initial idea was to simply hash the UID of the xNT tag once read, and then compare it to a stored value, etc, for authentication. However, since the UID is "publically" readable, I was wondering if there was a more secure way to authenticate the chip. Maybe like a handshake of some sort? (I might be over estimating the capabilities of the Mifare chip. I'm currently reading Amal's own paper on the Mifare S50 security features hoping to find some useful information.

Any help would be amazing, and thanks again for such an amazing product!

Hey there... ok, so for the first problem, it may be an antenna coupling issue. I suggest checking out the xLED - www.dangerousthings.com/shop/xled to try to find out where/how you can best read an xNT with those readers.

To your second point.. with the xNT based on the NTAG216, there are some ways to secure it better than UID alone, but it's all kind of pointless because there is no way to actually secure it. I will explain... the NTAG family has a few features that are interesting;

1) ECC signature - you can issue a special command to the xNT that will report back an ECC signature that you can use with the UID to verify authenticity using NXP's public key. This is pointless though because anyone can issue the command and get back the ECC signature just like they can get the UID.

2) PWD (password) - The NTAG 2xx family of tags support a password feature which is kinda cool. It is designed to protect tag contents. You have the option of setting a 4 byte password, a 2 byte PACK (password ack), then setting both an AUTH byte and a PROT bit in the config pages.

AUTHThe AUTH byte is the memory page at which to start password protection. If you set it to 00 then the password protects the entire tag (except UID because that is reported upon the select command regardless). If you set it to, say, 10, then all memory contents from page 10 down (11, 12, 13, etc.) are protected with a password.

PROTThe PROT bit sets which kind of password protection those memory pages receive. You can set PROT to 0 (default) which offers write protection for protected memory blocks. Anyone can read them, but the session must be authenticated first (using the PWD_AUTH command) before they can be written to. If PROT is set to 1, then the protected memory blocks cannot even be read until the session is authenticated.

PACKThe Password ACK (PACK) is a 2 byte value which is used as part of the authentication process. When issuing the PWD_AUTH command, if the password provided is correct, the PACK is returned to the reader.

Now, the password settings are crap. They protect the tag contents with a minimum attack window... someone with prolonged access to the tag will be able to brute force that 4 byte password... how quickly they can do that depends on their gear, but it's somewhat trivial to leave a machine running 24/7 to work at it. A set of really sensitive gear that can process power side channel attacks, the time required is less. Still, all of this is not important if someone can get access to both the tag and the reader. Assuming the password option is used to protect your tag..

A) segmented attack - the attacker gets the UID and ECC signature from your tag, they approach the reader and emulate the UID, the reader attempts to authenticate and literally hands over the password. The attacker can then tell the reader the attempt was successful, but at this point the attacker doesn't have the correct PACK (password acknowledgement) so here's an opportunity for the reader to notice something is wrong.. even if the attacker simply refuses to send back anything, or sends a failure code, the reader is expected the PACK, so at this point an intelligent systems designer will record the whole event and trigger an alert of some kind to the admin. Woefully, most systems just ignore this type of failure and let the attacker go on undetected. So, now armed with the password, the attacker can go back to the tag and pretend to be the reader, authenticate, get the proper PACK, and get all the data on the tag. Now they can go back to the reader armed with the entire tag's contents. You might raise the bar a slight bit by employ some kind of additional use of the read counter feature and/or updating the data on the protected memory blocks every time the tag is read, but ultimately it's futile.

B) man in the middle / relay attack - An attacker or pair of attackers put an internet connected device at the reader and one at the tag and relay commands between tag and reader, recording everything during the interaction.

C) eavesdrop attack - An attacker installs a listening device at the reader and just watches all clear text data flow between tag and reader and simply replays it.

So, as you can see, there are steps you can take to secure some things with the xNT, but it is intrinsically not securable. If security is a top concern, we suggest you keep an eye on our VivoKey project.

I am curious why you think the password settings are crap. A 4 byte password would take ~4 billion combinations and there is some hardware latency (on the card side) to attempting the password, as in tens or hundreds of milliseconds? Wouldn't that mean it takes years to brute force the key?

Brute forcing is still difficult yes but with power monitoring and field control the time to process a failed AUTH command is significantly reduced. My comment though was primarily about the password being cleartext and symmetric.

Everything with the ntag216 is cleartext. Meaning, an attacker could read your UID and ECC signature, then go to the application reader (access panel), emulate those elements to the reader, and the reader will send the password directly to the attacker. Then the attacker can go back to the tag armed with the password and get at the memory contents.

The only possible saving grace is using a nonstandard PAK (not 00) and having an access control system smart enough to put a halt/examin on that specific UID and get a human involved. But, most systems that leverage simple tags like the ntag are not that concerned with security anyway.

The ntag itself was not designed for security, but for NFC applications that are meant to provide information to people, not secure it. The password feature was primarily meant to be used by content managers who wanted to update third NFC tags on occasion, not for securing facilities.