I hope you are going to share 
1 Like
Cheers Amal
I have added those to
1 Like
Not exactly hidden. But we had that conversation elsewhere already.
That explains why I got surprised that SUN would work securely without an app pairing. 
Number of Scan times on chips are dicey for implants.
Some of them work that out well, but most of the tags out there do have a max number of scans, then that feature becomes useless when the counter reaches max.
(not sure if this apply to your tag)
Yes.
Iām always up for questioning/deconstructing stuff! 
Which brings me back to the use-case question.
As inā¦ Not counting āIām doing this to learn/exploreāā¦
What would be the use case to display openly an access key at the same time that youāre concerned about such keyās security?
Not saying that there arenāt use cases, but most often than not we can find a better approach.
I mean, it looks like āI just upgraded my doorās security system to impenetrable! now, let me throw keys out of a parade car!ā 
Nicely done!!! 
It can, the spark 2 dose this also. The feature is called SUN. DESFIRE 3 can also do it. It adds it to the url so yes phone support it, itās simply a get parameter thatās added.
(Sorry if this has already been said, the thread is long and I didnāt have time to comb through it)
2 Likes
to be clear, the SUN is not really, actually secure. it is a cmac signature on the UID + counter value, but anyone can read the chip multiple times to collect a bunch of SUNs and just feed those to the target system or applicationā¦ as long as they do so before the legitimate user scans and bumps the counter value on the target above their extracted SUNs, this attack works flawlessly and easy to pull off.
The VivoKey API documented above uses extended protocols and direct commands to ensure authenticity of the chip. The SUN on the Spark 2 was enabled just for anti-caching and some simple feature fun.
3 Likes
My point was not about the chip appending something. It was about me doubting that any secure mechanism would do that.
But @amal already replied to that.
Ok, now my world is back to making sense! 
The way Spark 2 uses sun makes sense. Because the really secure stuff does not revolve around SUN.
I think most of the confusion comes from the point where most places where I read about that tag, inclusive of some NXP docs, it gives you the impression/illusion that SUN (Secure Unique NFC) is a feature used by secure applications. (I wonder where that misconcept comes fromā¦ 
)
@amal cleared it out greatly!
Thanks!
2 Likes
I would guess is is because the uniqueness is secure, thatās why its called Secure Unique NFC not Secure NFC. You can securely tie a URL to a scan, examples would be the NFC tags that security guards like those at I think @anon3825968ās workplace use, it could be used to prevent the guard from cloning the NDEF record and just scaning there copy wherever they are. Just because itās not secure in a way that you find useful doesnāt mean itās not secure in other ways.
1 Like
Unfortunately, no. Youāll need to read the docs to configure the 424 correctly. We use a similar tag in our Spark 2.
Incorrect. The 424 can indeed do this.
Itās a SUN. CMAC if I remember correctly. So, yes, backend server. Needs AES keys of the chips.
Didnāt you see those?
Pretty sure tbh from function names on the 424 that theyāre a desfire-lite tbh
1 Like
Where pls? The scan api docs didnāt load images for me. I just now figured out theyāre supposed to be accessible through /docs/v1, there they have images and Iāve never heard about KVS no.
Oh, odd. Thereās images yeah. Weāre going to remove those API docs, anyway, and keep PDFs on the developer site.
Edit: Kinda glad I can finally show this off. Itās been a lot of work the past month and further.
2 Likes
Correct. Still itās a misleading name. You can see so by looking at peopleās questions in forums.
Agrree. Yetā¦
āThis is secureā is an absolute statement, therefore implying absolute security.
āThis is more secureā, or āthis is cloning-safeā or etcā¦ are statements more in line with your affirmation.
Harsh statement there.
A quick look over the very own NXP forums and github will show you that far more people failed to grasp what to do than there are people able to effectively guide them.
That is, for me, a statement that the documentation is utter garbage.
When I read it, I got to agree with @Will: It is really poorly documented.
Just because you are technical, smart and experienced enough to understand that documentation easily, it doesnāt make it a good documentation.
Yep. technically it can append stuff to the URL, for the NDEF read.
Still I stand with my statement:
- the tag cannot add something to the payload of a message in a secure way. This is what āin the way you mentionedā is there in my statement, as I understood it.
This is kinda typical of NXP.
It could be that people who arenāt well-versed in this sub-industry of smart tags and devices have trouble understanding it. We only see the public failures, not the private successes, of which i can tell you are many. Those may be people who donāt frequent Github and their forums. The thing is, if you need help with this stuff, you just ask your NXP contact. Theyāll either answer you directly or get the internal engineers to help. The whole NDA required thing is good because then everyone with documentation access should have a contact to get help from. NXP doesnāt make chips for small scale. They make and sell millions of these things.
By this, I meant thereās no ālaymans termsā. Itās not a great documentation, but the 424 one is a world better than the 413 (to the point where I use the 424 doco to implement 413 features) and the earlier ICODE DNA, by far. If you want to use the NXP range, you need to be prepared to learn.
The SUN is a counter-based CMAC. It signs theā¦ tag UID and the counter if I remember correctly.
Itās not great security, but they do say that explicitly in the documentation, that you must protect against read-and-store using the counters. Itās up to your threat model, and why the new API of ours doesnāt use it. The old one does due to its architecture.
Then nobody can say āthis is secureā for anything. Given enough time/money, nothing is secure. Like I said above; the security environment is outlined.
The 424ās primary use case for SUN is end user validation of an item, not end user authentication. Itās for a situation where you donāt want an end user to install an app to their phone. Itās so you can buy fancy wine and tap your phone to confirm that yes, it is indeed xyz corps instead of abc corp counterfeiting it. XYZ corp has a server that validates the SUN, which even if ABC captured valid reads from XYZ, those are likely to be marked invalid due to bad counter values. It even has TagTamper, which means once the closure is opened you can have a wire thatās severed. The tag, once scanned, will know forever it was severed even if itās then reconnected.
The wine thing is kinda big in China, so I hear. They (used to) pass cheap domestic wine off as imported Australian stuff.
For a āproperā authentication; MAM1 is the actual āsecureā option. Iād highly recommend @Will use this if possible. Set your AES keys, enable mutual tag auth for the key you want to use, and use authenticateev2 (in the 424 doco).
1 Like
Many private successes can be indirectly measured by number of satisfying answers on forums and github, for instance.
I find it really to believe a really significant number of people have successes while none of them contribute back to the community.
We were only questioning how good was the documentation.
It has nothing to do with how good is the chip. A product can be amazing, and still have a shitty documentation.
It is this mentality which keeps holding us back.
If a product wants people to learn, then they should have better documentation, least they get wrapped in a self contained loop.
The more people can get into tags easily, the more tags become used by everyone, the more the general population gets access to chips, the less āmind control chipā theories grow out thereā¦ the better for all of us.
Just because I can understand complexity doesnāt mean I approve of complexity barrier keeping people away. I donāt need that snobness in my life, but I do want more people to gain access to tech I want to see developed more and more!
Completely agree. Hence why I go against such marketing statements constantly.
Before I sound too harsh, @fraggersparks, my critique is aimed at NXP, not you.
While I canāt go too into detail, NXP can be frustrating due to the mentioned size. How I said āprivate successesā? The companies NXP supply are massive. Just so far out of our league weāre protozoa. The hobby developer and us are a side effect. We make literally no difference to their bottom line. It means thereās little incentive to improve the doco, to have these things be usable for us. The companies using them have entire R&D teams who will sniff out how it works and write a spec to be implemented. Remember, NXP is the semiconductor spinoff of Phillips. Theyāre big fish.
2 Likes
It really sounds like your jumping at fraggersparksā throat, man 
We get your frustration, weāre all on the same team here. No matter how much we want NXP and other big name chip manufacturers to respect the hobbyist market, thatās literally never going to happen. We have to work around their existing structures.
Also, assuming fragger had the bandwidth and desire to āsimplifyā the documentation (which may not even be possible) he cannot because heās bound by the NDA with NXP regarding this information. Even if everyone here got an NDA and downloaded the docs and started picking through the minutia, NXP could easily revoke all of our doc access privileges, and we canāt have that happen because we need to develop products in the future.
2 Likes
To me, it just appears to be an example of survivorship bias
Another important aspect here is that we canāt talk about itā¦ NXP puts all their āgoodā non-public docs under NDA. There simply cannot be a community around it, by design.
Edit: ah @Satur9 already hit on thisā¦
2 Likes
How simple should it be? How much background should the average person need, and do they need access to the technical side of it?
Ignoring the NDA issue, as you get more secure / more powerful chips, thereās more difficulty making it work / understanding it. Take proper key based security of DesFire EV2 vs the simple password of the NTAG216 vs Crypto1 of Mifare Classic - itās inherently harder, and despite making something āsimpleā / āwell-documentedā, it doesnāt make it easy to do / understand.
I find the whole NDA thing insane. I mean, who does that?