Fair enough - provided the exodus can be performed independently by the user, in the absence of, and without the intervention of either Vivokey or Fidesmo, and without needing either’s hardware or services.
I have zero doubts about Amal’s, DT’s or Vivokey’s best intentions. But experience tells me a lifetime warranty refers to a company’s lifetime rather than my own - meaning the sentence is pretty much meaningless 
Okay
This is unlikely to be possible with Fidesmo-enabled Vivokey Flex chips, unfortunately. The reasoning is that fidesmo are the key holders - to remain compliant with EMV, users can’t know the keys. This is Fidesmo’s role, they have the keys. The opt-out is in the contract, but not currently implemented (due to the current status as a closed beta), and will require their intervention to happen (as all applets will need removal - to remain compliant, the chip needs to go to factory state).
@amal may be able to speak more on this topic.
Right, makes total sense. What I fail to understand is why Fidesmo is needed to factory-reset the chip: the user should be able to do that on their own. There is zero security issue with that as far as Fidesmo is concerned.
Unfortunately, this is likely closer to a NXP NDA thing.
There is no factory reset command on the current chip. The main consumers of these chips, banks and national ID schemes, don’t need it. For Fidesmo to unlock it, they’d need to send a command to set the default key on the chip, using their keys as the authentication.
The new chip may have this function - it’s under NDA and NXP actually needs to provide the full command to Fidesmo. As Fidesmo is unable to give the command out under NDA, you can see where I’m going.
To be clear, the devices we’re talking about are not yet publicly available… but they are coming. They will be smart card contactless secure elements, and you will be able to write and deploy your own java card applets to them… so they are “open” to whatever software applet you want to deploy (for the most part)… however if you want total autonomy, then that will rely on a key reset option of some sort.
Everyone has done a pretty bang-up job explaining things so I don’t have much left to say about it… but this is the key issue. Even if Fidesmo goes out of business, the company officers would still be legally liable to make provisions for key reset… either through a reset process or through a simple disclosure of current keys. If VivoKey goes out of business then customers could still go direct to Fidesmo and issue a key request or request some sort of reset option.
However, corporate apocalypse is not the intended trigger here… we do plan to make this option available as soon as possible to every customer.
Now, to be clear, this does not apply to the Spark products because the Spark products have no such key system and are simply locked. You can still use them with UID based applications and 3rd party devices, but the keys are set and locked, as is the content on the Spark 1… the Spark 2 will have an option to unlock the user memory in the future.
I see. Thank you for your very clear explanations @fraggersparks.
So the gist of it is, the Flex is someone else’s locked hardware that Vivokey is making into something implantable, that the user loses control over should Fidesmo tank [EDIT: or not - I posted that before @amal’s explanation above], and that they can’t get the full specs of without signing an NDA with NXP anyway.
That kind of makes repurposing the chip at a later date, or building an open-source community for alternative uses of the Flex rather difficult, as I feared.
Don’t you have to have Fidesmo vet your applet and make it available through their applet store though? I didn’t think you could simply upload your applet on your own on the Flex. It’d be great if you could do that though.
They only require vetting if you publish it. You can load arbitrary cap files to your developer account.
I guess what I meant was, you can’t code something, compile it and upload it to a chip just like that. And you can’t publish your code (or binaries) for other people to upload freely to their chips. You have to use Fidesmo’s infrastructure to develop stuff, and you have to submit your finished work to Fidesmo to give it away - at least if you want to retain the ability to use the chip for payments.
It would be great if the chip had a segregated secure area for critical applets that Fidesmo vets and signs with their key - that they naturally have a say on, and a “free”, unsigned area for tinkerers to upload any old code they wish into without Fidesmo having to get involved.
Maybe 2 Flex implants - one locked and one unlocked - are in order
Sort of… it’s a specific smart card chip we purchase from NXP, then we manufacture the implant using that chip, and then it is provisioned with secure keys by Fidesmo in our facility.
Sort of… it’s all about levels of openness. Unless you want to open source your own universe, ignite your own open source solar fusion furnaces, explode your own open source super novae, coalesce your own open source planets, mine your own open source silicon, open source your own die circuit design, get a chip fab to make it, and make your own open OS and all that all the way up, you are going to always be stuck at some level… ok yes I was being a bit hyperbolic there… but you get what I mean… at some level there is something that is not totally open, especially when it comes to smart card IC chips. So, to break it down let’s play “Is It Open?”;
chip OS - no
chip applets - yes
master keys to deploy those applets - no, unless you opt out
So at this point you can totally write open source java card applets and those applets can be cloned or downloaded and complied by anyone and deployed through Fidesmo by anyone by signing up for a developer account and deploying, all at no cost. In fact, you could put your applet up on Fidesmo’s platform and create a deployment recipe and share that with anyone who trusts your binary and they could deploy the applet to their chip with a manual service order via the Fidesmo mobile app (settings, advanced, enable manual service orders)… so there is definitely, at a certain level, the ability to develop and deploy open source java card applets to the VivoKey Flex One.
We might make this a possibility, but it depends on how we can obtain these chips and what the market would be for an unlocked chip. For example, if it turns out that we would need to purchase an entire wafer of separate chips which would remain unlocked, that’s a hefty chunk of change… so we probably wouldn’t invest in that unless a lot of people called for it. The alternative would be to get the Flex One and wait / demand that we release the opt-out feature and then you could leverage the opt-out option to reset master keys.
Thanks Amal and everybody for taking the time to answer my questions.
I’m still intrigued by all this. When the Flex comes out, I think I’ll start dabbling into it.
That’s kinda what I was thinking. I’m interested in hacking the thing, but I’m probably in the fringe. There’s no sense in Vivokey spending extra time / cash to create two versions of it.
Are VivoKey applets likely to be available on non-VivoKey Fidesmo devices? for example an implanted regular fidesmo chip
I can see the NAK app in the list but there’s no install button
That’s actually a bug… It’s not supposed to be visible. The apps could be made available to other fidesmo devices, however with the changes to their platform and basically the competitive nature of various OEMs providing different hardware form factors that essentially do the same thing… It doesn’t make sense for us to make those applets available to competitors without a proper licensing framework. We actually are working on something like that for the Tesla key card applet, and hopefully others will follow.
You’re definitely not alone and I’m similarly annoyed by the idea of having to go through Fidesmo to “publish” and get a dev account just to have fun coding whatever. So if you go for the two flex “opt-out” option I would be curious to know how it went and I might do the same.
Maybe I misunderstood something. Am I correct that there will be a payment option through a Applet by time?
Payment applets are already loaded on the Apex, they just can’t be activated for now until visa / MasterCard approval, which could be never.
Hopefully Mastercard and visa will move things fast forward.
Otherwise we need a walletmor capability on the apex 
It really sucks if you ask me. We’ll see if things change moving forward. I think fidesmo does this, so we have higher chances of getting 1 chip wich can do payments (or other sensitive things, think insurance) AND user things like OTP and PGP.
Keep in mind, this is the first project of it’s kind. We don’t know what happens in a year or 10, but for now I think a locked down ecosystem like the Apple App Store might be the easiest way to get others (like mastercard/visa) involved.
Agreed, if payment becomes a thing on vivokeys it’s 100% worth putting up with whatever restrictions Fidesmo puts down. Yet I feel like we’re at a pivot point where whatever standard breaks the ice to the general public will later be accepted as the norm and will be hard to go against so let’s make sure we future proof by keeping as many options open as possible. To use your metaphor, we need the Android/Apple balance 