How open are Vivokey products?

Support
1

First of all, you’ll have to excuse me if I appear as if I don’t know what I’m talking about: I’m a former computer engineer, 20 years retired from computers, and while I’ve kept up with some things, I’m more familiar with assembly and embedded products from the 90s than with modern web applications.

So, being old-school and also slightly paranoid, I like to control the hardware I use - or at least know that I can do so if I choose to dive into it - from A to Z. That’s partly the reason why I chose to implant a magic Chinese M1k as my first chip, despite the appalling lack of security: I know that no part of it is locked out from me, or dependent on a third party’s whim.

With that in mind, I’m looking with interest at the various Vivokey products - out or about to come out - and the possibilities they offer, and I’m seriously considering getting involved. What holds me back is this:

I understand Vivokey is trying position themselves as a trusted authentication / authorization provider, and they document their web APIs in order to attract companies and developers to their ecosystem. And that’s fine. What I can’t seem to find anywhere is the APIs to the bare metal - the chips themselves.

To be blunt, my concern is this: if Vivokey disappears, or moves on to another activity, or fails to update their apps for a very long time for lack of funding for instance, will I be left with very small paperweights that I will have devoted time developing stuff for for nothing?

So I guess my question is: if I wanted to exploit Vivokey hardware 100% on my own without resorting to reverse engineering, can I do that? Are the chips documented? Do they strictly implement open standards or are their undocumented Vivokey bits that are impossible to make use of without closed source Vivokey apps or APIs?

I got burnt more than once working with hardware and software that became obsolete years later because the companies behind it folded, or unilaterally decided to stop supporting it, and that’s my concern with Vivokey products also. I’m not trying to be rude or undermine what Vivokey is trying to build, far from it. I’m just trying to assess the longevity of what I’m considering investing time in.

7 Likes
2

I think you have some valid points. I’ve been burned with hardware that relies on software/services that disappears making it useless.

The chip’s themselves are all documented by the manufacturer. Though in most cases, those documents are under NDA. So while not freely available, they are attainable through the proper channels.

I can’t speak for Amal so I’ll leave the details to him. But in general I think you can expect a minimum level of closed-ness that is required to maintain security while making an attempt to leave the rest to the user. All of them can still be used for basic identity using their UID. Certain tags are completely open (xNT)…other tags are locked down in certain ways that enables them to be used for stronger security (Spark). It’s a fine line to walk and I know it’s one Amal considers when developing products.

I also think it’s a consideration when choosing which products to implant. You can choose not to install a tag that relies on a service to provide the functionality you want. Of course the alternative might be to create/provide your own service which is expensive and time consuming. But it’s always your choice.

2 Likes
3

Fidesmo and other service providers (like eventually EMV) require that chips being used on their platforms be provisioned with keys and identifiers in secure facilities, and that they remain locked to that platform, uneditable by the user. This makes sense when you consider the normal use case for these devices (a disposable card or secure-element bearing object) but it’s not ideal for an implant.

Amal has posted before that he’s working to make an exodus option available for all the VivoKey implants provisioned in this way. That way, if VivoKey were somehow unable to maintain the partnerships it’s creating, VivoKey customers would be able to elect to remove the provisioning and free up all the memory sectors of their implants, with the caveat that it could never return to the platform. In that case, you would still be able to use all the open source APIs that VivoKey has developed for your own purposes.

VivoKey and Dangerous Things implants have a lifetime warranty, and will continue to be supported as long as possible. Amal would never infringe on that if it was in his power to stop it.

5 Likes
4

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 :slight_smile:

3 Likes
5

Okay

6

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.

1 Like
7

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.

1 Like
8

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.

1 Like
9

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.

5 Likes
10

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.

11

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.

12

They only require vetting if you publish it. You can load arbitrary cap files to your developer account.

13

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 :slight_smile:

2 Likes
14

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.

2 Likes
15

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.

5 Likes
16

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

17

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.

2 Likes
18

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.

19

Maybe I misunderstood something. Am I correct that there will be a payment option through a Applet by time?

20

Payment applets are already loaded on the Apex, they just can’t be activated for now until visa / MasterCard approval, which could be never.