SOON ™
2 Likes
Even Apex doesn’t help there. AFAIK most applets do not require the reader to verify it’s identity.
Or can I implement such checks for the whole chip?
If that’s true that’s one situation where an xDF2 might be advantageous because I think its challenge response tech is a shared-key scheme where both parties prove they know the key without giving it up. But yeah I’ve been thinking a lot about the implications of having what amounts to a yubikey in my body. That’s essentially how I’d treat an apex. It doesn’t seem perfect. I’d still want to pin-protect any keys on it and ensure I trust any device I enter the pin into, because it would be trivial for a malicious device to decrypt or sign something extremely sensitive instead of decrypting the email I’m trying to read. Commercial solutions use smartcard readers with built-in PIN pads so you don’t have to trust any computer with your PIN but I don’t think implanting a PIN pad would go particularly well.
And sorry I think I missed that you planned to encrypt the secret before it went into your implant.
1 Like
If you store your keys on a smart card (e.g. yubikey) then the private key is only stored on the smart card and the encryption is done there. It is not normally possible to pull the key back from the smart card so if someone steals your pin they also need your smart card before they can use it.
Given the Northstar implant I am sure there are some people who would implant a pin pad. 
Of course, yeah the key is never extracted, but when even allowing an adversary to use a key once can be disastrous like for example a certificate authority’s root cert, it’s important to prevent that by either pin-protecting the usage of the key like you can do with yubikeys or some sort of k-of-n scheme, or both. PIN-protecting the key usage isn’t very useful though if an adversary compromises the computer that is used to enter the PIN, which is why some solutions do PIN entry purely in hardware. I looked around and found the Thales IDBridge CT700 as an example. So by commercial systems I mean extremely high security stuff.
2 Likes
@Yeka,
I think your topic and the replies are too good and valuable info to loose in the anti-derailment thread.
I have moved it here, to its own thread.
the title is just a place holder.
feel free to change it (if you can, or let me know if you can’t and I can change it for you)
I was wondering the same/similar thing the other day when I saw Amals xSIID red white and blue sale…
2 Likes
This has me thinking now. I wonder how hard it would be to do secure PIN entry with one of those multipole radial magnets that are normally used for magnetic encoders. If you had coils placed correctly in an implant you could harvest energy from a magnet’s rotation (outside your body) and simultaneously sense how many poles have gone by, which could theoretically let you build a combination lock implant. It would probably be really difficult to harvest enough energy from the rotation to keep the PIN data in SRAM long enough for the implant to be subsequently read by a device though. I bet you’d have to be really quick about it unless you stuck a giant capacitor under your skin to feed the SRAM chip. This would be well beyond “security” and into tinfoil hat territory, but it sounds cool as hell.
I’m not 100% clear on what “device uses it as part of a challenge response authentication” means, so you might be right… but in general, simply storing encrypted data for use as part of an authentication process does not work to secure anything. Let’s say someone was able to read your xNT (NTAG216) tag and the stored encrypted data… sure they cannot decrypt it, but they don’t need to… they can program a flexMN magic NTAG with the same UID, signature, and encrypted data… the reader and applications beyond it cannot tell the difference and will happily read the encrypted data off the fraudulent tag and assume it is legit. This is why chips must actually perform encryption internally, not just store it.
Maybe I’m making a moot point above … I am low on time today and just skimmed the thread… sorry if this is inane.
It depends entirely on how the applets are programmed to function. For example, the OTP applet can be set up to require a simple password to be sent to the chip in order to perform code generation. It’s a very simple password mechanism that could be sniffed to get the password (not the TOTP code sources) … but it doesn’t have to be simple… it could be complex as shit and use public key enrollment etc if you wanted to get crazy with it… and you can easily make these solutions and deploy to your Apex through a Fidesmo’s developer account… or we can merge your pull requests into our open source applets and deploy a hardened upgraded version. That’s the true beauty of Apex.
yes this can be done, but honestly a public key enrollment process from each authorized reader is enough… use a sufficiently long static “PIN” (password) to enable enrollment in a relatively secure environment… then “daily use” is a public key challenge affair… no unauthorized reads in the wild.
1 Like
Sorry…
Essentially one device issues a challenge and the other responds with the right answer. The mechanism can vary wildly but in this case the secret is not actually passed back and forth.
Oh sure I know what a challenge response is but I guess my point is that if the encrypted data is simply being stored and read off an implant then there is no active cryptography going on there and the encrypted data could simply be copied to another chip or simply emulated and pass as a valid chip… hence no protection at all really.
That was, I think, my point. If you are actively doing something then it can be secure, otherwise it is no more secure than any other authentication mechanism…
Equivalent to storing your passwords in a book and then using OCR to read them in rather than typing them yourself.
1 Like
Ah yeah so I was being redundant hah… boo
1 Like
Nope, I disagree.
Compare it to the KBR1, my setup requries the chip the reader and possibly a pin.
The KBR1 just relies on the chip.
There’s a big difference, or am I not explaining it correctly?
No wtf, that’s the KBR1.
If your OCR tool decrypts the text, so only your OCR can read it, then yes…
I think you people didn’t get my idea.
Okay, know what? If I have time today I’ll make my DT account use such a password and leak 1 of the secrets… 
Basically what I’m reading is that you want to include the chip in some sort of authentication process. You will be reading some static data off the chip and using that as part of this authentication process. Regardless of encryption or anything fancy going on, the problem is centered around the “reading static data” bit. Whether that’s the UID, some plaintext, or a bit of encrypted data… it is still simply being read off the chip as static data. Therefore we are simply saying that anyone could still just copy/emulate that static data and impersonate the chip contingent of your security mechanism, however complex that might be outside the act of reading static data off the chip.
I will say that the complexity of splitting encrypted data to unlock a password manager is “more secure” in that, without that static data, an attacker is pretty much hosed… but… once they have a read or a sniff of that static data it’s game over. That’s all I’m saying.
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 
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,
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 
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