Total newb to the forum, wanting to make a secure tag that i can glue to my head to make sure it works before looking at dermal implants, 10 years of development experience first time messing with tags. Thank you for having me here!
I just got the NTAG424DNA tags delivered, I’ve installed NXP tag writer and NFC TagInfo apps on my iPhone. With the tag writer I chose Link where I put in a description and link to my api and left URI Data blank and wrote the data to the tag. I then read the tag and sure enough the exact link and description are there. All good at this point.
From some youtube videos and real newb sniffing around I was expecting some URL parameters to be generated by the tag and added onto the URL that my API can some how authenticate? What are these parameters called and how do i get the tag to generate them?
I also expected to be able to tap the tag with the iPhone X without needing some extra software was i wrong here or do i need to change some phone settings? Or scan a QR code?
Ive tried reading the NTAG documentation but its utter garbage and makes no sense to me, Im hoping a can get a layman’s version here.
Nothing will be done “by the tag”, in the way you mentioned.
You do have multiple tag types, capable of different things.
Most of NFC tags do have a thing called NDEF.
That is just a “open/exposed data storage”, in a nutshell, which uses certain standards to let multiple applications deal with it.
The process you describe makes me believe you wrote a link there.
If that’s the case, then the tag will not do anything to it. when you scan the tag with a phone, it will attempt to open the link.
You are correct here, but Make sure “NFC” is enabled on your phone. It’s like Bluetooth or Wifi: first you need to toggle it on (usually on the same menu as those two options).
It is off by default to save your battery.
(also, apple is kinda fiddly with NFC. Although the X should work.)
Try enabling it on, and let us know if you got a read.
Now, about…
You have basically 3 ways of achieving this. (there are more, but I’ll focus on the most common 3)
NDEF: You write your url with a query string containing your autenthication already there. Pro: should work easily from any NFC-enabled phone reading it, no need for apps. Con: anyone scanning your tag will easily see your autenthication key.
DesFire: These chips have some secret encryption keys, so you can scan the chip -> System identifies over UID and uses a key stored in their database to request a challenge from the chip -> the chip replies with the encrypted challenge -> you have your autenthication. Pro: considerably secure and “out of the box”. Con: you need a dedicated client to perform this. So you cannot use “any phone tapping into it” to perform this level of autenthication, since phones “tapping into tags” will only passively read the first entry on NDEF.
JavaCard: Some chips, such as the fabled Apex, allow you to write JavaCard applets inside the chip! Pro: you can basically go crazy and build whatever you want there! Con: you also need a dedicated app to read your tag, since it’ll need to request the app specifically.
I hope those are comprehensive enough options. (I tried to keep it kinda “in a nutshell”, so there are more details to it).
So… If you don’t mind explaining what exactly are you trying to achieve, we might give you a better steer.
@ Eyeux Are you familiar with the NTAG424? It has more options than the standard NTAG216. The 424 can do AES 128 encryption and can use that in conjunction with NDEF to provide a method of authenticaiton.
Using AES-128 cryptography, the tag generates a Secure Unique NFC (SUN) message
for the authentication each time it is being tapped. An NFC mobile device reads this
tap-unique URL with the SUN authentication message, sends it to the host where tag
and message authentication take place, and returns the verification result. The SUN
authentication mechanism is guaranteed to work on Android (without a dedicated app)
and iOS11 (with an app). This way, NTAG 424 DNA offers tag authentication, as well as
data assurances on authenticity, integrity and even confidentiality, while also securing
physical tag presence, see also Section 9.3.
Hello and welcome. The ntag424 can do some cool stuff like url signing but it won’t do it by default attached is a pdf (if you have already seen it i appoligise) but it seems to give a description of the “advanced capabilities” including url signing.
Only from reading docs and watching loads of unreplied threads about people failing to use it.
Sort of…
If it is, then it’s definitely not working out of the box, based on how many people have been asking about this, or not fully supported by phones yet.
Although I honestly doubt it would work just by “appending a secure token” to an URL within NDEF when handing it over to the scanning phone, because this would be literally the same level of security as you writing your auth token on the URL yourself.
As I mentioned earlier, I gave an overview of the topic, without getting into much detail. but if we want to be a tiny bit more granular (still trying to use quite broad strokes here):
NTAG424 has these capabilities, amongst many other:
Standards-based AES-128 encryption for authentication/secure messaging
This case must still be approached exactly as I described on the “DesFire approach” on my last message
Secure Unique NFC (SUN) message authentication for advanced tag and data protection, useable with Android and iOS mobile devices.
This is what’s really shiny and new.
Taking from your pdf:
This means:
you need to have the most up to date version of Android/IOS and a device which is compatible.
this does not specify the authentication is just a token added to the URL. Quite the opposite, it is mentioned there is a server-side authentication mechanism behind it.
What I am still unclear is if they are expecting those tags to work out-of-the-box somehow (which I doubt would be through NDEF, since NDEF is not meant to be secure), or if they are adding embedded tools on Android/IOS to make devs lives easier when building their own application.
By that I mean… making it so that as a dev I will be able to just use NFC’s own cloud services to authenticate a tag instead of having to build my own.
This last bit makes more sense since it’ll allow companies to use their tags at a much larger scale “out of the box”, but doesn’t mean we could authenticate via NDEF in a secure manner. (I mean, we could, but that would incur in a hit to the performance of NDEF reading on every other case)
I might be wrong here, though. they might surprise me with some very clever trick which I haven’t yet found in their documentation, nor on any of the forums I’ve found loads of people asking the same thing, no one with an answer which satisfied me yet.
Assuming we’re still talking about “appending something to the end of an URL within NDEF”:
Then the url would not be encrypted. so even if you use OTPs, that would require a backend server ready to handle those. How then the backend server would know what to expect?
If it’s an arithmethic progression method, then I can just capture enough of those OTPs and calculate what to send.
I mean… could be that, and I’m expecting too much from them…
Another issue with something just appended to the NDEF is that I can write anything to react maliciously to your tag on-scan.
If you build it within an app on the phone, the app can make sure external processes don’t gain access to the NFC process while it’s using it.
As I said, I might be wrong.
I’m just basing myself on what would be actually secure and what can be easily messed with.
Then betting that NFC will build something really secure.
It’s your server, you configured that. I mean the goal is that YOU can verify it’s YOUR chip who authed this http request.
I dont get this sentence. Writing on my chip? I guess you can disable that.
Okay I’m now sure about the concept of the chip! I was doubting my theory, and thought they maybe need a special app to initiate the process, but no. This chip produces an URL that allows you to verify it’s this chip (now?) that created the link.
you might very well be correct.
But I also haven’t seen anyone successfully implementing it that way either. If it was just that simple, then it would have to be really simple to implement.
I just need to make it “fail to read”. you would try again. and again. People do try like crazy to get a tag scanned.
Easier to brute force than a WAP2 passwords. And we know those are broken fairly routinely
I’m not saying it isn’t a secure approach. Just that putting that on NDEF makes it less secure.
That looks like it’s just pre-encrypting the access token (in this case the taag’s UID) and appending it to the NDEF.
Got curious enough to throw “messing with those tags” in my ever growing backlog, though!!
As I said earlier, if OP tells us what he hopes to achieve, we can give him a better steer.
All I wrote on my original post were the 3 “most common” ways of dealing with encryption and tag scans. Keeping things very simple since he claimed to not understand much.
Now, for clarity:
No. not writing on your chip.
Intercepting your scans.
I can easily write a tappy bird game that is a facade for an app that reacts to “any NDEF read”, intercepts it and does malicious stuff to it.
It is much harder to react to when another app is using the NFC antenna to read a tag.
No, the format in which it is transferred isn’t a problem.
What you said could be applied to the Apex.
Yeah, I see your point.
For secure applications you want that the app that scans the chip also verifies it’s the one who asked.
Or that it’s really you, by requesting a password to access e.g. the PGP applet.
@Pilgrimsmaster just do your thing when we’re offline, thanks <3
I’m surprised I sparked off such a great conversation, my basic understanding is that there is a unique ID on the tag that gets encrypted along with a payload up to a certain size and the number of times its been scanned, this all gets encrypted with one of the private keys and added to the end of the URL, So the URL is never the same twice.The tag can be locked so this cant be tampered with. This URL can then be decrypted by an API that yes i’ll be writing, I guess the API will need to know the key used on the tag.
My next step is to get a tag reader and get the NXP TagExplorer software to run, which needs me to upgrade the java runtime
<3
