Linux sysadmin, I want to use RFID for 2FA on my laptop/phone

[fraggersparks]

@dada

as long as it is fips approved

The FIPS compliance is a feature of NXP chips if I am remembering correctly.

@dada

as long as I control the keys

Complete control over keys is totally possible. Personally I’ve loaded up the OpenPGP a fair bit onto test chips and there will be the same option for the Apex. All apps we provide from Fidesmo for end-user like this are initialised with a default key and are provisionable with OSS tools (PIV is best provisioned by the YubiKey tool anyway, the rest are pretty easy to provision out of OpenSC)

Rosco is referring to the ecosystem control - to put it shortly, we use a partner company called Fidesmo to allow us to have a wider range of applets on the chip (think transit passes and payments). Part of this is locking into their ecosystem as they need to be the “keeper of the keys” and gatekeep what applets are installed (although it is quite simple to push applets you have written yourself to the chip) albeit, we have a clause in the contracts to allow our end-users to opt-out, and basically format their chip back to a default, unmanaged chip that is then fully controllable by the end user.

@dada

but sysadmin and server people, we’re already on board man!

This is my field as a dayjob (currently), and I can’t wait.

[amal]

@anon3825968

When you buy a Vivokey chip, you buy a Vivokey / Fidesmo-locked chip - i.e. what you really buy is secure access to that particular ecosystem and nothing else. They provision the chips with their own key and there’s nothing you can do about it.

I feel like you and I have discussed before elsewhere on the forum. What’s quoted above is simply not accurate. The Spark chip (the only VivoKey chip you can buy right now) is a symmetric crypto chip using AES128 with 3 keys. It has limited capabilities and you cannot load or change any software on the chip, hence Fidesmo has nothing to do with the Spark. Because the chip software is unchangable and the keys are symmetric, to be at all useful for us (VivoKey) we need to set the keys and lock it. The Spark was never promised to be anything but that - an authentication token for VivoKey and any and all integrated services through our standard APIs.

When it comes to Apex (this is where Fidesmo comes into play), what @NiamhAstra says next is pretty close to accurate;

@NiamhAstra

To be clear the apex will let you have your own keys and apps on it, it is just the keys for loading new apps and that sort of stuff Fidesmo controls AFAIK.

However to clarify completely… it’s not just putting your own keys on. You are given a pathway that is absolutely free (no fees involved) which will allow you to develop and deploy your very own javacard applications to the chip… and those applications you created and deployed can generate their own keys or you can push keys into those applications. The only cavet is that you need to deploy your appliations through Fidesmo because they hold the master key needed to manage apps (deploy and remove apps) on the chip. Therefore, your statement made above would be more accurate it it read;

When you buy a Vivokey chip, you buy a Vivokey / Fidesmo managed chip.

The important aspect here is that you can update your chip, deploy your own apps, and do so free of charge… you simply have to deploy them by signing up for a free Fidesmo developer account. I realize this is still not what you want, and that’s fine… but it’s a reality that is very different from the claim “what you really buy is secure access to that particular ecosystem and nothing else” when it comes to Apex chip based products.

@yeka

the other to opt out of fidesmo and deploy your own applets.

As stated above, you do not need to do this in order to deploy your own applets.

@dada

there’s also “business” reasons

yes… let me elaborate.

For a long time now, there have been chips that are “multi-application”. This includes all 3 “evolutions” of DESFire, as well as full blown smartcard “secure element” chips… but you know why you don’t see cards that support more than one application? Why transit cards can’t also be used for the gym or any of your own applications, or why you can’t load your own PGP javacard applet on to your totally capable credit card?

The reason is trust… or lack of it. You see, absolutely nobody trusts anyone else with master keys. The transit company doesn’t want to have anyone else deploying their transit app to cards they don’t totally own and control… and neither does the gym, or the banks, or the enterprise handing out employee badges.

This lack of trust is why you end up with 20 cards in your wallet… each one capable of doing so much, but limited to just one thing only per card. This is why Fidesmo was identified as a critical partner for VivoKey, even well before we actually had a secure element chip. Fidesmo’s roll is to play key master, and convince 3rd parties like transit companies (Fidesmo Go) and payment networks (Fidesmo Pay) and access control companies (HID SEOS) to trust Fidesmo to securely deploy each of their applications to the chip, safely inside their own security domain on the chip, where other applications deployed to the chip from other sources can’t see or mess with their sensitive apps or associated data. Without this critical role being played by Fidesmo, we would not have a chance in hell of actually using our chip implants out in the real world with real world services and applications deployed on a wide scale.

Que ironic quote time…

@anon3825968

For instance, I tried to get my local transport authorities to program an implantable version of their DESfire-based pass card not too long ago. That’s an incentive: I could’ve taken the bus or the train and pay for fares with my hand. I would have sprung for that.

This is exactly what I’m talking about. You will never get a 3rd party company to provision their application to your implant. The only exception you might get would require they provision your DESFire chip and RESET your chip’s master keys to their key derivation algo… i.e. you would lose your own master keys… and you’d be stuck in the exact situation you don’t want… actually it would be worse because not only would you not have your own master keys, but you would not have any way at all to provision any other applications… your chip would do one thing and one thing only, and you would have no way to reset it or do anything else with it ever. At least with the Apex and Fidesmo, you totally have the option to deploy your own apps.

@NiamhAstra

@amal got any unprovisioned ICODE DNA implants (I am guessing that is what the spark 1 was) lying around? If not what are the chances of you making a run of them or even NTAG413s?

I did have one unprovisioned chip… sold it to someone here on this forum I might consider another run of NTAG413s but for right now all energy is focused on Apex.

@dada

The problem I see with that is that If I were to offer that to a company to do secure authentication they wouldn’t be able to host their own 0auth

I’m not sure what you mean here… OAuth 2.0, specifically with the OpenID Connect extension, is an IdP solution that tons of websites and services use. Like SSO / SAML, it delegates authentication and identity validation to a 3rd party. The idea than an enterprise might accept it as a form of internal authentication mechanism is not really the goal of these particular IdP implementations… however we do have other ideas in this regard, as @fraggersparks has already attested to.

[dada]

very interesting post, thanks for all the info. You seem to be carrying out a difficult endeavour, good job!
I fully understand your issues with upstream producers and their legal issues and strategies, it’s not easy to be a small guy in that particular space.

@amal

I’m not sure what you mean here… OAuth 2.0, specifically with the OpenID Connect extension, is an IdP solution that tons of websites and services use. Like SSO / SAML, it delegates authentication and identity validation to a 3rd party. The idea than an enterprise might accept it as a form of internal authentication mechanism is not really the goal of these particular IdP implementations… however we do have other ideas in this regard, as @fraggersparks has already attested to.

Both Windows and Red Hat offer IdM solutions with IdP, they support quite a number of ways to do it, including 0auth, in a “self hosted” manner.
I’m not well versed in the Windows side of things but I am in the RedHat ecosystem, this is the software at the core of it
https://www.keycloak.org/

for the moment though I personally wouldn’t be looking at using a 2FA with that, there’s already quite a lot of work to be done implementing that with our pre-existing services, but I would definitely jump in at using that, and I mean in proper production environment, with ssh, just for the sysadmin and developers, using the implant as a hardware token exactly as we do with the yubikey.
As I said in order to do that I absolutely need to manage the keys and rely upon opensource standard libraries supported by the major enterprise linux OS (RHEL mainly), bonus points if this will eventually get standardized and accepted withing STIGs like FIPS.

Enterprises do use these solutions quite a lot, including in very secure environments, what they don’t do is, for example, use third party 0auth identity providers, even if you were to parner with RedHat on that we wouldn’t rely on your servers and APIs to do it, that’s the no-no on the enterprise side of things.

We need to manage it all, protocols like 0auth allow us to manage users across very varied and different services with a solution which is both simple for the user, safe and allows us to get granular control of access and identities without going crazy, in this space the role I can see for implants is, as I said before, kinda like a 2,5FA, it’s not really biometrics (which is invasive and expensive) but it solves some of the problems that hardware tokens come with, they are hard to manage as physical inventories and are easily lost/damaged/stolen.

[fraggersparks]

Amal was aiming mostly at Rosco. Key-wise, you get to manage the keys you do cryptographic operations with and the provisioning of those keys. The only things you don’t get are card keys. They are purely for installing/uninstalling apps once in the field.

Yubikey doesn’t let you have the keys to install apps - it’s no different here. (I know some of their stuff runs javacard of some sort, one was a Fidesmo device actually). You get the apps you’re given - we at least offer you whatever apps you’d like.

I know for a fact most commercial (read: enterprise) smartcard systems also don’t give you the keys to your smartcards for app install etc. You get control over their installed app, that’s it.

[anon3825968]

Yeah I mean that’s fine. I perfectly understand the rationale behind the secret master key. There are no other ways to interact securely with third-party service providers really. I’m cool with that… when it’s a credit card or a USB crypto key, or something that’s not under my skin. When it is, it doesn’t sit so well with me.

I know Amal will argue that removing or replacing a chip is barely harder than changing credit card, but he’s a scalpel enthusiast. I ain’t

Anyway, if Fidesmo provides a way out in the form of a reset request, I reckon that’s a pretty good compromise, even for me. Still, I’ll wait till the offering is more appealing.

[fraggersparks]

Pretty much. It’s not simple, this game. Too many big companies to keep happy, and this is the best way forward. I will see how we can make the Fidesmo opt-out happen, though, as there’s clearly (some) interest and it’s something we need to offer. (This isn’t an official statement, but Amal has officially said this will be a thing - we’re just busy on other things and an opt-out for a chip we don’t even have released yet isn’t exactly on the list, although it will be).

I’m scalpel-averse, too, but the needle insertion is pretty good. I was one of the first to have it done in the Flex beta and apart from the tearing to expand the hole by a piercer not used to these insertions, it was an unpleasant, but not excruciating, experience (although I could imagine it being far better with some of the magic lido cream I’ve got).

[dada]

@fraggersparks

Yubikey doesn’t let you have the keys to install apps - it’s no different here. (I know some of their stuff runs javacard of some sort, one was a Fidesmo device actually). You get the apps you’re given - we at least offer you whatever apps you’d like.

correct, with a smartcard you have no control over the code that’s on there that actually execute the instructions to do crypto, neither you do with the Yubikey, that’s not a requirement for what I’m looking at, but I do need to provision the keys, control the auth server and access the chip with a standard opensource library, so spark2 comes pretty close to that but not fully. Rosco wants to play with the actual hardware on the device, which I understand, I wouldn’t let him use that to access a secure server tho, writing crypto software is hard and prone to errors, I’m ok with companies like fidesmo selling me that (and taking the responsability for it, which is all that matters in enterprise).
As I said years ago there was not crypto in chip options available at all, now there is, and this makes it interesting for me now, it’s just a matter of companies working out how exactly to deliver that, I hope you guys will be able to do it and make good money doing it!

[fraggersparks]

Yeah, a Spark isn’t what you’re after. The Apex will fulfill what you’re after, though. I can’t provide anything official on the responsibility of things, but all the code an enterprise would use is auditable (which is more than some smartcard providers could say) by interested parties.

Crypto software, yeah, it’s difficult especially on embedded gear. I wrote our internal identity solution to provide the spark style auth following applicable standards and best practice, but we have cloned high quality OSS repositories for all the standards-based stuff (which you can inspect and build yourself if you don’t trust us, which is fair. The only changes i’ve made, and I’ll be 100% transparent here, is we changed how PIN lockouts work on OpenPGP - instead, it will unlock the PIN after it wastes a couple hundred milliseconds - this makes bruteforcing far harder in a limited time of having access to someone surreptitiously but also you aren’t able to maliciously lock someone out of the PGP app, basically).