Nah, you’re all good.
Seems like some pretty robust and accurate on topic conversation.
Besides, the OP says
And
And for @Will ,Here is some more information around the Vivokey ecosystem
https://www.vivokey.com/spark-info and where the Spark2 fits into it.
This looks superb, is there an SDK on the server side that I can use to authenticate requests from it?
hot off the presses… so hot it’s not even on the site yet…
VivoKey Scan API.pdf (237.4 KB)
VivoKey Key Value Store API.pdf (118.8 KB)
VivoKey Android Demo.pdf (297.7 KB)
Scan api docs WITH IMAGES?!
Key Value Store?!
Thanks for sharing… I gotta go.
I hope you are going to share 
Cheers Amal
I have added those to
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)
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.
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!
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.
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
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.
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:
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).
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.
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.
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.
