Can my xNT be easily set to read-only?


#1

Hello. Long time listener, first time caller.

I had an xNT implanted a few days ago, and it’s all gone great. In fact I wrote a blog post documenting my experience so far: http://blog.danhett.com/2017/07/dan.html

Anyway, I’ve used the Dangerous Things app to secure the chip, and I can happily read and write to it.

My question is: is it possible to set the user data to be read only? I’m using mine for encryption keys as part of an artwork, and I’d like to ensure (if possible) that it’s only readable and not writeable.

Thanks!


xNT Security Use-Case - Any big attack vectors?
#2

Hi Dan,

Glad you’re happy with your xNT!

So there are a couple ways to go about this…

  1. Lock your tag. This is permanent and irrevocable. Your tag would need to be removed and thrown out if you ever had to change your key.

  2. Protect your xNT’s contents from unsolicited writes with a password. You can still read it (anyone could), but your content would not be updated without first authenticating.

  3. Protect your xNT’s contents from unsolicited reads and writes with a password. You could’t even read your xNT without first authenticating.

  4. Lock your xNT and also implement a password to protect against unsolicited reads.

For option 1, you can lock your tag, simply use TagWriter, go to Protect Tags, and Lock Tag. It’ll lock it. You’re done.

For options 2 and 3, we recommend disabling the locking feature all together. The lock bytes being changeable is simply a liability. Instead I would disable locking and set a password by using Dangerous NFC. Then, if you wanted to set specific password protections for your tag… well that is done by changing the PROT bit of the ACCESS configuration byte in page E4 (0=write protected, 1=read & write protected), and changing the AUTH byte to at least 04 (00 is also ok, but doesn’t actually protect the UID).

How one does this is, at the moment, difficult. No apps (not even ours) is really that good at being granular enough to dig into the details. Take a deep breath… we’re doing digital surgery here…

1) Read the datasheet

… particularly pages 18 and 19. Be really careful with CFGLCK and AUTHLIM … screwing up either of those will really wreck your xNT hard… which is one reason Dangerous NFC protects these configuration pages.

Configuration Pages

ACCESS BYTE (Page E4)

AUTH & PROT

2) Download and install NFC Shell

I’m jealous of this app… I want it’s code inside Dangerous NFC so bad (under an “advanced” section).

3) Send these commands

Type in the following lines in the shell box;

1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 80 05 00 00

The first line starting with 1B is the PWD_AUTH command, and the h1 h2 h3 h4 value needs to be replaced with the HEX value of the password you set for your xNT. So, if your password was 1234 then the HEX values of the ASCII characters 1, 2, 3, and 4 are 31 32 33 34. Check ye’ olde ASCII chart for a reference.

The second line, starting with A2, updates the AUTH0 byte to page 04… protecting the memory contents of your tag with the password you’ve set.

The third line, also starting with A2, changes the PROT bit to 1 to ensure nothing protected with AUTH0 + PWD can be read without first authenticating. If instead you want to write protect the tag but still let anyone read it without authenticating first, then change that line to A2 E4 00 00 00 00

Press the SEND button and then scan your tag. You should receive in the shell window, something like this;

TX: 1Bh1h2h3h4
RX: 4454
TX: A2 E3 04 00 00 04
RX:
TX: A2 E4 80 05 00 00
RX:

That means success… no RX after successful write command means success. If it fails, you’ll get an RX: NAK back.

At this point, once you remove the tag from the field, you will need to authenticate with the password before you can read the contents.

If you have any cheap spare NTAG216s around, I’d test on those first. Good luck!


#3

Hey Amal

Thanks for the prompt and detailed response - really useful.

I’ve already secured my xNT with the DT app, but didn’t realise the process was so involved in terms of putting this thing into read-only mode…

I’m inclined not to screw with it really, my use case is a little strange I think compared to most people who have these implants: I’m an artist who’s using my chip to hold encryption keys, which will in turn be used to encrypt messages which I’ll be painting on enormous canvases to be displayed somewhere really cool (secret for now, but you’ll have heard of the person who opened the place)

For this reason, the chip is really largely symbolic - the encryption key could of course be kept on my machine or whatever, but this is a personal work around personal encryption, and so keeping it in my hand felt like a logical move.

I think I’ll leave it as-is for now. I have additional security in terms of the xNT only actually holding half the encryption key, and a few other elements that i’m not revealing. in terms of people writing to it, that’s a risk I’ll take and isn’t the end of the world (and I think in realistic terms isn’t a likely scenario at all)

Once the project is announced and/or finished, I’ll let you know - my implant is now at the center of the artwork, and hopefully series of artworks!

Dan


#4

Awesome! Looking forward to hearing about it!


#11

I came across this post when looking for a way to possibly read-protect my nXT. However, I wanted to clarify a couple of things:

First, are the writes in “Send these commands” section correct? I’m referring to:

1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 00 01 00 00

It seems that in a later response, Amal may have provided the wrong command and that using these could inevitably lock a config bit. Amal gives an alternate command of A2 E3 08 00 00 04. It appears that this command should replace the second command in the original (for protecting memory contents), but I’m not positive. If so, and the original instructions are wrong, then the original post should be edited or deleted.

Second, it appears that the Android NFC Shell app is no longer available. Are there any Android or PC alternatives? NFC Tools has an advanced section that can send individual commands and receive responses, but I’m hesitant to use it for more than some basic commands.

I used Dangerous NFC to protect my xNT implant with a password. My understanding is that this means that I should be able to send a PWD_AUTH command to the chip and receive a response. I read that DNFC changed the PACK response to 44:54. And when using NFC Tools to send a 1B:00:00:00:00, the response I receive is Error: I/O Failurer, but when I send a 1B:WW:XX:YY:ZZ where w, x, y, z are hex codes for the ascii characters of the password I set with Dangerous NFC, I receive a 44:54 result, which aligns with the original post. Is it safe then to perform the rest of the commands to read or write lock the tag?

In a previous post, Aman said:

The password (PWD) and acknowledgment (ACK) bytes default to FF FF FF FF and 00 00, respectively. Dangerous NFC changes the password to whatever you specify, and also sets the ACK to 44 54 (“DT”)… well this makes just about every other app out there shit the bed when it tries to perform an AUTH to first unlock the password page so it can write an update

This seems accurate as neither the NFC tools app or NXP Tag writer are able to successfully change the password set by DNFC. What is the reasoning for sending a non-default PACK response to a successful password? Is there a danger to having the PACK respond with 00:00, or to having another tool be able to change the password? Once the lock bits are protected and assuming that the user doesn’t forget the password, it seems safe to allow other tools access.


#12

Ok. Holy shit. @MiniAardvark… apologies… @GrimEcho’s post had me re-read through all this… I mean… have you ever worked on something really hard… put in a ton of hours… really feel like you are living and breathing that thing you’ve worked on so hard… then suddenly you come across some of your previous work and you’re like “who’s the moron that did this? what kind of jackass would do such a thing?” only to realize it was you?

That’s just happened to me with this post.

I don’t even want to explain all the errors in what I said above… and there are many… I can’t even fathom why I made these errors… but I did. First off, the base counting thing mentioned above… then I was also getting the bit order wrong when talking about the first byte value… 04 and 08 are both wrong… the correct value to set the prot bit to 1 is 80 no 08… converted to binary, 0x80 is 1000 0000 which matches the LSB notation I gave above for the access byte schema. This is why you were able to still change the page value even after I thought the CFGLCK bit was set… but it wasn’t, because you weren’t changing that page at all… the correct page to set the PROT bit is E4 not E3… I honestly have no idea what the hell I was doing about a year ago… but it’s so embarrassing I want to just kill this whole thread… but I won’t… I will go back and fix it…

So, the proper commands for @MiniAardvark are:

1B h1 h2 h3 h4
A2 E3 04 00 00 04
A2 E4 80 05 00 00

Page E4 contains only one working byte… the ACCESS byte, which is where the PROT bit lives at bit position 7 which is the MSB, not the LSB.

Now, to address @GrimEcho’s remaining questions…

Well that sucks… it’s probably because of the new requirements for app listings. I had to go into the Play console and flip a couple settings on my apps to indicate they were not targeting children. I had 3 apps removed from the Play Store because I failed to mark those config changes before the deadline, so maybe that’s the issue and the author may or may not get around to it. In the mean time, here’s an exported APK of the app you can sideload.

NFC Shell 1.0.apk (15.6 KB)

Yes, the PACK returned is correct and you are authenticated… however you cannot remove the tag from the field… the authenticated session only lasts as long as the chip remains in the field and does not reach the HALT state. Typically it’s best to stack your commands to execute all at once so you don’t have to fiddle with manually inputting commands after you’ve authenticated your session.

The utility of changing the PACK is explained in detail elsewhere in the forum, but it’s a security measure. Basically if someone were to spoof your tag ID to a reader that is armed with a password check, the reader would just hand over the password with an AUTH command. If the PACK is standard, the spoofer could send 00 00 back and the reader would not know anything was wrong… but since the spoofer can’t get the PACK from your chip without the correct password, they would have to attack the reader first… and if the PACK is not sent back or the wrong, standard PACK is sent back, the reader is given that one chance to know something is wrong and possibly take action, like notifying security or disabling the permissions given to that UID/chip (like not opening a door for example). Make sense? The real infuriating thing here is that those app devs are lazy and they do not properly handle several things including lock bits and PACK… back when we first released DNFC, none of the tools properly handled lock bits and every single one of them, including NXP’s TagWriter app, declared that the chip was locked read only when it was not… they simply did no parsing and instead looked at the bits for any non-zero values… if any bits were flipped they just threw up their hands and said “well it’s all fucked, your chip is locked, sorry” and gave up. After much badgering and embarrassment thrown at them, many of them updated their code… but not to properly parse lock bits… they simply removed the lock bit check completely and then just dealt with write errors for truly locked chips instead. At this point, nobody has bothered with properly handling the PWD or PACK stuff. I regret even putting it into DNFC since we didn’t include a way for it to be changed… it’s still on our to-do list but so many other things keep popping up that it keeps getting pushed back. One day it will be updated… one day.

If you want to hear my rantings on other ways developers are lazy… you can read this; https://forum.dangerousthings.com/t/the-xnt-and-the-mysterious-46-48-byte-problem


#13

Hey Amal,

Thanks for the detailed response. The security reasoning on the custom PACK makes sense. I was thinking of it as just guarding the implant/card, but they way you describe, the custom PACK gives some measure of protection to the reader itself revealing the password to an adversary.

Thanks too for updating the code/commands and not nuking the thread, as this seems to be the best resource for those wanting to tinker with the protection settings. I think I’ll play around with it on a few non-implantable chips first. I haven’t had to count bits since a 2000 level CS course in college. Might need to dig out my notes… :slight_smile:


#15

Hey, is option 3 reversible? I.e. After encryption/password protection I could wipe tag and write/read the tag without a password again?


#16

Well, not really protection against the reader handing out free passwords… it will definitely do that regardless, because the PACK is sent by the tag back to the reader AFTER the reader has attempted authentication with the password… so basically, at best, it’s a bandaid after the wound has already been inflicted… but in short, it’s no protection really.

I’m not sure what you’re asking, but 1) there is no encryption going on here… the password option is a simple 4 byte security check (and a bad one at that)… so don’t think a featured called “password” is really going to do a decent job of protecting the data on an NTAG216 chip… 2) depending on how the chip is configured, you cannot “wipe” it… if you have set a non-default password and set your AUTH0 byte to anything lower than E5, then you will need to authenticate before you can change your password. If you have set AUTH0 to protect user-writable memory, then you will need to authenticate before you can write any changes to those protected user memory pages.