Secure auth with dumb chips, secret outside of NDEF (xSIID?)

Yeah ok, I gotcha.
I believe I said some wrong things and wasn’t clear enough.

All I’m saying is, splitting it in n parts requires n parts. Just with my chips full dump, you wont get into my online accounts.

To be clear, this IS more secure, but only when attackers dont usually have access to the reader (i.e. not locks, but online accounts.)

1 Like

gotcha ok yeah that is definitely squeezing an improvement our of a virtual turnip.

1 Like

The first part of that is not true in theory, there are a lot of ways to do secret sharing wrong. It seems like you know what you’re doing so I’m not saying you’re doing it wrong, just that it’s very possible to do it wrong. You need an information theoretically secure way to do t=n secret sharing. The second part of your statement is likely true. Crypto is a special interest of mine so it’s easy to get really into the weeds but at some point being paranoid about this stuff just isn’t worth it anymore. That said, I definitely recommend either doing the XOR trick in this wikipedia article under t=n or storing an AES key on disk and encrypting the secret with that key and storing the ciphertext on your implant. Either of these would be sufficient and they’re not terribly difficult.

Again I don’t wanna be patronizing but I also want people to be aware of the implications of what information they put where so I’m just putting this out there :slight_smile:

1 Like

I think the simple is that UID and Data be cloned/emulated.

  • Can anyone read your xSIID?
  • Can this people have access to the reader with a cloned/emulated tag?

If both answers are yes, then is no bueno
The system won’t be able to tell the difference.

If the second answer is no, then you can use the KBR1, use the UID and call it a day.

If you really want security,

  • You can try programming an xDF2 with all the fancy APDU commands and setup your own custom secure authentication system.
  • You could use a VivoKey Spark2 with any of already made APIs and libraries.

Oh you just had to trigger me right?
IMO a KBR1 is more secure than a spark, just because I believe that your servers being hacked is way more likely than my hand being scanned.

Hot take, I know, not even entirely true. Still, I really dislike the spark :confused:

The DF2 thing is actually true… I’m really thinking about getting a flexDF2 for security stuff. But there are rumours there might be a DESFire emulation for Apex so… the waiting game continues.

1 Like

^_^” Hahaha sorry didn’t mean to trigger you.
But I can think of several common life situations where you wouldn’t have control of who scans your hand. (Robbery, Accident, Arrest, Betrayal of someone close to you, etc, etc).

I get it if you distrust the insane security measures that the VK servers have.
There is some level of self-preservation on everyone, some take it to paranoia degrees tho.
To be honest, even if a hacker had root access to any computer/server that VK has, they will just get lost, took me months to complete the iOS app, and I had the source code for the Android app and even the programmers answering all my questions about how the system was setup over the more than 26,000 lines of code, it is absolutely unique and nothing like anything out there in my opinion.

But if we are going for “nothing is impossible”, then you have to toss in there in the possibility of someone scanning your xSIID and getting all the information out of it one day or another, being it your fault or without your consent or knowledge.

Back to topic, if you think no one will ever scan your hand, you can make as funky as you want your reader code, but anything from a xSIID can be read->cloned/emulated. So if you are so sure no one will ever scan your hand, then you can just do UID with the KBR1.

And I am with you, is easier to use a RC522 than the PN323. Easier to work with NDEF, and I have thought of many ways to obfuscate an access “something” inside the NDEF.

So here is an idea I had.

Have the reader generate and save the next password and save it on the 2nd record of your chip as pure data so it won’t be automatically read by any normal reader. Since most phones will read just the first record unless they have a specific app (available for free) and manually try to read all the records. The reader will only react to the UID with the correct 2nd record.
Have a button in the reader to “reset” the local password. Add a bluetooth module and pair it with your phone to manually enter a pin-code to generate a new password to put in the chip and memorize a large pin code, that way if you feel you have been abducted by aliens in your sleep and they scanned your chip’s current “next” password, you can reset it exclusively trough your mobile app. You could have a numberpad on the trigger to setup a specific code that will be time-based, so if its 12:37 you could mentally perform an operation with the numbers, lets say just * 2, and enter the code 2474 before scanning your chip, of course you can make it as obfuscated as you want, *2, flipping numbers, adding original numbers, combining it with your DOB or a secret number, or whatever complex mental mathematical process you can do on the fly, but then the real security relies on your capacity to encrypt a piece of data and punch it in manually which… well is kinda going backwards…

Or you can use the AES capabilities of the Spark2 ^^ because the incredible amount of steps needed to not just hack a server that is unreachable from any part of the internet, they will also need to understand the insane labyrinth that is the whole system, then scan your hand to know how to identify your chip, then understand how the server manages and delivers identities among a LOT of data and encryption, then have access to your reader, and finally they would need to have the capability to clone/emulate a Spark2 including its AES capabilities specifically in the order that is configured just to have access to your cat’s pics on your computer. ^^

Sorry, I absolutely can’t agree with the argument that a KBR1 is more secure than a Spark ^^

But if it’s more about a close system, yeah, the xDF2 sounds like the option you are looking for, and yeah, you are free to keep waiting for the Apex, and then for the DESFire “emulation”.
I would argue that we are all users of a technology that is not yet commonly available, and we use to the maximum what we have now, so you could move forward now or keep waiting for the products and services to be released "SOON"™️.

1 Like

That’s not my take (EDIT: it kinda is, yeah), but I think I have a decent idea how serious VK took security until now…(looking at the bugs I reported already some of which haven’t been fixed yet.)

That’s my point tho, you dont need my chip or reader if you are inside the VK system.
Just take my password out the KVS or login to my password manager account. Ofc it highly depends on how I do it… and what. That’s why I said it’s not completely true.

I don’t want to bash VK or the Spark here*, just sayin’ that in my threat model it’s much more likely that you guys made a small programming error than that someone reads my chip.

* It might sound like I do, but no I love VK and everything you do

It’s just the idea that you have the secrets on some server.

Whatever… I’m sorry I didn’t answer to everything of your post. We just disagree. I like the rolling code thing tho, have thought about something similar.

really though a hacked VivoKey server would not necessarily or automatically result in your computer login being compromised. Enrollment would still be done client side and is a client side function. The API simply offers a member ID, so at best a hacked server would offer a member ID for any chip valid or not, but which member ID to offer? The attack would have to be extremely directed and personalized to your specific chip and computer and even then there are mitigating factors that would require local access to your unlocked computer first (like enrollment).

We are working on a solution for VivoKey that will let you perform enrollment online and then get Spark validation confirmation offline, without access to the API or internet… but more on that later.


Yah I know.

I’d repeat myself if I’d answer the rest.
Yes, it’s only true in some cases.
Imma ignore these discussions until we get 4096 bit PGP :wink:

That sounds very sweet, I wonder how that would work… are you finally releasing the third key to the users? Even then I dont know how it would work :smiley: Stoked!

1 Like

If I end up succeeding at building an auth system with the xDF2, I’ll probably build the server component such that it can run in a trusted execution environment/secure enclave/whatever they’re called. It should be remotely attestable, so as long as you trust the CPU vendor not to backdoor the CPU’s TEE and the server owner not to side-channel the CPU which is extremely disruptive to service and pretty difficult, you don’t even have to trust the person operating your auth server. That’s the plan at least. We’ll see if I can get the EV2 to talk to me without the NDA docs.

1 Like

I actually completed a project for my own door lock using VivoKey’s new API.

It gets the challenge from the server, performs the encryption on the chip and gets the memberID back from the server.

128 character long string and it only works on a local network.

Amal is right, an attacker would actually need to already have access to the developer keys that are in charge to generate a custom MemberID for that developer specifically.

We all know the Spark2 chips have 3 keys, and some users have requested access to one of this keys, and its being considered and looked into to do this in the most secure way possible, users will probably won’t have direct access to any key as in, the server will just give the keys to anyone who asks for it, so we might be talking about a special module that can store a certain authentication for a specific chip, almost how like “pairing” works on Bluetooth. Options are being explored and many things are still to be tested and decided, but VivoKey is meant to be the one solution for many problems, specially on large integrated systems.

I believe if you are that advanced to run your own APDU commands and configure chips, you are best off with the xDF2, specially if you are just looking to do something locally and for you only.

1 Like

I haven’t got the xDF2’s data sheet, does it include how to setup the keys and lock the chips, and run authentication and encryption commands?

I did the door lock project and I had to manually run the APDU command on the Spark2 to tell it to encrypt data received from the VivoKey server. And it was a fuuuuun trip of several days…

The data short doesn’t, but I understand there’s a longer datasheet you can get if you promise not to share it. There are some similar chips that do have that information available in some NXP application notes though. I think it’s the NTAG 424 DNA that has some info that’s more publicly shared. There’s also this:

Wish me luck. I’ll need it!!!

1 Like

Hmm that seems like a lot of setup of code someone else made.
Nothing beats having the data sheet. I don’t think the xDF2s are locked in anyway so you should be able to get the full data sheet since whatever credentials you will use will be your own anyways. But not sure if you do need to sign the NDA with NXP first for that.

Maybe @amal can shine some light here.

We all know is “possible” but until someone sits down and writes the code is just on the air for everyone else.

What’s your setup for the reader?

You could check out the

I’m not willing to sign an NDA since I open source code all the code I write, at least whenever my employer allows me to (gotta love IP law).

Yup. I’m alright at software though, I’ll be fine. We’ll see how far I take this project but I’m pretty sure I’ll be able to get auth working. So far so good. I managed to pull the originality certs with no issues. Currently setting up PDKDF2 in my react native project so I can authenticate with the default key and change the master key on my first test card. That’s probably a good goal for tonight!

Oh I totally forgot to answer this oops. The reader is just going to be an android device for now but hopefully most of the code will be portable to iOS since I’m doing it in react-native. I’m hoping to use android’s hardware backed keystore for some stuff though and I’ll need to keep keys on disk for iOS since I iOS can store symmetric keys in the keychain :frowning: