It’s a bit complex to do this, and still defeats the purpose of security. The decision wasn’t just made by me, but I support it.
We’ve got plans for recovery options but if a implant does crap itself, we are here and have access to recovery tools as necessary for reinstating account access.
Edit: Polished Turd makes a point, multiple implants can be tied to your account.
I got a spark2 and have a spark one waiting for install both of which can be linked to my account. It may sound funny but I’m also putting the spark one into either my other arm or maybe leg so in the unfortunate instance I loose my left hand I still have access to my vivokey account.
I can try to edit my pledge.
And yes, Flipper would be best, but flipper is not accessible off the shelf, so I didn’t consider it as a reccomendation for OP.
Wouldn’t that defeat the purpose of in-chip encryption challenge mechanisms?
Does having recovery codes for 2FA, stored in an offline format defeat the purpose of 2FA?
Most websites that use 2FA offer them. They can be used for when the authentication device is unavailible (broken, stolen etc.).
This would even moreso apply for a device like the Vivokey cryptobionic chips, since not every device you would want to use has a NFC interface. Most laptops, for example, do not, and have to rely on external dongles that can also break/get lost/whatever (I know, this has nothing to do with the non-implant Apex, since it would still need a NFC interface).
Of course, a person who would be security conscious enough to use this would probably never use an unfamiliar device.
I don’t think it defeats the purpose, but it does somewhat impact security.
It of course all depends on the threat model.
Of course, @fraggersparks, please don’t think I’m trying to push you in a certain direction, I’m just voicing my opinion. In the end the decision lies with Vivokey.
Yep, it does according to most threat models. It drastically weakens security to give the user control over the location of those.
Mobile apps allow this gap to be bridged quite effectively.
It’s an understandable point you’re making, yes. But the concept of the VivoKey is it’s far more reliable already than a 2FA device. You can lose your phone, drop it down a toilet, etc. Does yubikey let you back up the secret keys from your security token? No, they don’t. They just make the things nigh indestructible. The same concept applies here. You can’t lose it. It won’t break on its own, and if you do somehow manage to damage your implants, I cannot imagine a situation where DT/VivoKey wouldn’t help you however we can to regain access. Considering we’re already involved given implant failure and warranty, and damage we do like to hear about too, this is not too bad an issue. I’m going to take this discussion internal to VivoKey for now, as we do need some procedures so we can tell you with certainty how we will handle this, and I thank you for bringing it up. (I promise I’m not brushing you off I’m literally about to go write up a message to Amal on this topic). I remember there being early stage discussions of allowing multiple trusted associates to sign a restore request with their implants as an example idea.
Question: can you have multiple implants associated with the same identity? Because if you can, I could have just buy a Spark2, eject it from the needle, enroll it and stick it on a piece of cardboard, creating thst would in effect be like having a “recovery key”. Would be a security issue though.
You are right, they don’t; they do allow you to have two devices linked to the same account though.
Thank you for enlightening me 
I like to see manufacturers that care enough about their product to have an open discussion about it.
Yes. But if you eject it, that becomes on you for the security issue.
Yup, as do we.
I’ve had some thoughts on limited access recovery keys, though, and will talk to Amal about it.
I’ve got a couple of Spark 2’s encased in a small oval of resin for testing.
You are right, it probably is best for security not to have something like that. And given DTs excellent customer service, I am sure any potential issues could be resolved.
That would make sense.
When you mentioned “a card”, I assumed you meant an NFC card that can be used like the Apex.
That’s what I meant would defeat the purpose, since now you would need to either:
Now, for the sake of exercising logic, because this is an interesting topid…
Yes. It actually does.
in security aware systems 2FA mechanisms cannot ever allow for recovery codes.
In some of the systems I work with, it’s considered safer to not implement 2FA, if the 2FA platform used would generate recovery codes, even if you never deliver these codes.
Yes. and if the purpose of adding 2FA is to heighten security, then 2FA adding an extra step which weakens security…
Is my definition of rendering it moot. 
We do that, already. And it relies on auth from an already added chip. This is VivoKey ecosystem in particular. PIV, Tesla app, etc are their own things and not covered by that.
Not possible, can’t extract keys. Won’t happen ever.
Yeah, nope. Same thing as above. Apex can be validated in the ecosystem with an asymmetric key.
I do think a NFC (or even NFC+contact ISO7816) card as a backup recovery card is a workable idea, though. It would basically allow, if you only had one enrolled implant, to remove that implant and enroll a new one. If we get damage to implants, DT gets involved to replace under warranty. So you’ll have a new implant, basically, which the recovery card would allow you to enroll. Or we do some fancy purchase validation and stuff that allows, when an implant is replaced under warranty, for us to pre-enroll your new Spark/Apex onto your account.
Not sure how I feel about someone being able to just choose to enroll a new device to my account… maybe if it required some pre-determined imput from the customer. But that’s just me, in reality I have such bad security practices that that’s the least of my concerns if someone wanted to hack me.
Wouldn’t expect any less from you guys! 
That is how to keep it secure, but also wouldn’t serve the purpose @anon7067117 was referring to.
As expected. 
If I can use a card to bypass my implant in order to enroll a new one, then there is room for exploitation.
best case scenario, that’s the same thing as asking someone to write down their passwords. Worst case scenario, someone figures out how to remotely exploit it.
I do agree that there must be a mechanism for replacing damaged chips, though. And that is when it gets tricky…
I would expect that to be way safer than the backup card!
although I agree with @DonFire here:
I mean… I do trust DT.
Yet if it were any other company, I would possibly run away from it.
This isn’t implemented yet, and we’re trying to find a balance because there’s so many valid points. Maybe a multi-factor recovery in that you need the card to sign a recovery approval so we can actually do it?
yeah, I got that.
But you sure do have some tricky challenges ahead on that front! 
curious to see your approach, once it’s done!
Wouldn’t be easier to make the replacement request trigger it?
I mean… my issue with an ecosystem having the possibility of someone remotely manipulating my keys has nothing to do with “how I can trigger it”, but with the mere fact that such a possibility exists.
(which is the reason why I don’t have any password management service/app at the moment)
It’s not so much key manipulation. More basically saying to the data model “this implant is now assigned to x person”.
Something to consider is all our threat models rely on us being trusted. Oauth relies on it especially. To use the VivoKey ecosystem, you need to trust us to only let you in. Recovery comes into that situation. If my Spark got damaged, and I wanted to recover my account, I could log into the user DB itself and just assign a new chip to my user.
My intent is to have a U2F applet ready for Apex launch, so you don’t have to just trust us for secure stuff.
Which a malicious agent can use to add his own implant, associated to my person.
If this is autenthicated with my implant, then it’s all safe.
If this can be done from a server somewhere… that’s worrying.
Yet, and this is where I don’t envy you, you must have such possibility, else during a replacement of a broken implant, there will be no way to add the new implant in.
Only thing I could think of to ease my own overzealous worries, would be something such as… a new chip can only be added without original chip’s auth, if original chip has not been seen by the system in over X days/weeks… (which would be the case if it’s broken. also if I got arrested… etc, but not so much of a worry)
Oh, sure!
I’m just exercising logic here at this point.
See my edit - sorry i edited so close to your post.
I can set up security measures, but it only matters if I can’t connect to the DB itself and directly manipulate the data. Which I can, because at the end of the day, it’s a server we maintain and write.
We’ve never had to do this yet. But the fact is, if we needed to, we could. And that’s true of any company. If I can see a database with argon hashed passwords, sure I can’t see the password, but if i wanted to log in as you i could just change the hash to match a password I wanted, then change it back once i was done transferring all your dogecoins.
I’m just being transparent here. Unfortunately, the VivoKey platform itself is not zero trust.
Probably should’ve run all this by Amal first, but it’s my “area”, so to speak.
yeah, I saw after I posted 
Yes, that’s true.
So if you need to pre-add a new chip during replacement of a defective one, I’m ok. (hence why I said you could just use the work order for the replacement to trigger that)
But if we have a card I could use to do that myself… then you would need to expose an automated way of adding the new chip… which would be a potential new vector of attack.
A valid point. But consider that said card would basically be an asymmetric key that would sign the recovery request. We’d validate that request, the same as we’d validate a “true” Apex. We can add automated systems to say “only if you haven’t seen x implant for a week” or whatever.
Yet, no one can take my Apex from me.
Someone can get their hands on said card.
