Imagine someone stealing your implant…
Actually I have some level of paranoia about attending a cyborg meetup cuz someone could just be there to get some ids.
lol, but also, yeah, that’s why you want proper crypto secure keys exchange, like a 4-way handshake or something of that sort, just a plain UUID which gets read without any check, it’s not much different than a bar code really, actually a bar code it’s easier to cover up and prevent scanning of it.
1 Like
While it looked secure, that did not look convenient.
There’s always a battle between convenience and privacy/safety/security. It doesn’t bother me.
@dada asked about RFID and 2FA for Linux login. This is my current method of doing it, until VivoKey releases an easier method that doesn’t require the smartphone, communicates with the implant directly instead.
1 Like
VivoKey officially has this in the works (by “in the works” I have been up past 3am the last few nights debugging archaic Win32 code - as a PAM is easy compared to the clusterfuck that is the Windows logon environment). And I mean a proper cryptographically secure PAM/Windows Credential Provider with an Apex - I can’t really say when, but I’d be surprised if it wasn’t ready by Apex launch. No UUID auth here, no sir. Spark users won’t be left out, but it’s a little trickier, and launch will be “when it’s ready”. The aim is soon™-er rather than later.
One problem with the Spark 1 is that generic ACR122U (the general reader of choice due to low cost and wide availability) doesn’t handle ISO15693, like, at all.
3 Likes
Genuinely curious on what you consider better than AES-256, because what we can provide on a Javacard is limited by our upstream manufacturer (NXP) and what they build into their crypto processors. There’s full asymmetric support up to a definite ECC 384-bit keys and (probably, as I haven’t tested it yet) 512/521-bit keys.
Ok, I can answer this. We’re doing this. The Apex is supported, much like the YubiKey, by OpenSC. To the OS, it’s just another PKCS#11 token with any one of the number of already available open-source javacard implementations of OpenPGP, GIDS, NIST SP 800-73-4 (PIV), IsoApplet, and more. We’re providing these ready to install on Fidesmo, or you can compile yourself and push. I’ve validated personally OpenPGP/GnuPG as a ssh-agent for one tap (and a PIN if configured) logon to any sshd capable of validating against a signature.
1 Like
Is there anyway to get test cards for the Apex? I think this was asked ages ago, but now you seem to have the hardware locked in? Asking because then some open source projects for the apex could start asap? Or are there emulators for smart card Dev? Admittedly I should probably look into the dev process more before I enquire into getting hardware 
and maybe finish some of my existing projects.
A good question. You’re unfortunately not in Australia, or I’d ship you one of mine.
I had some unofficial ones I was able to get out of China, cost me far too much but I didn’t have any from NXP at the time (and was desperate to get development going).
Development is possible with Eclipse and the JavaCard Devkit from Oracle. It’s unpleasant, but it works. Ant-Javacard works too. The best toolkit for NXP stuff is JCOP Tools, but it’s under NDA (and getting on a NDA with them is difficult). It’s also near impossible to convince them to give you the right version of it for the Apex chips.
Man, if I was a dev I’d take you up on that for sure. Part of me wants on for my box of assorted cards, but I wouldn’t want to take one out of the hands of a dev to sit with someone who wouldn’t be able to put it to use! Getting test cards is hard, man!
AES-512 
seriously tho, AES-256 is fine, even 128 if fips approved.
But a bigger key is always better, I do understand there’s memory issues within limited hardware capabilities like in this case, so that’s a perfectly acceptbale limitation, as long as it is fips approved it’s not a problem to implement that for the space I have in mind.
that is great news, absolutely great news, I’ll be watching out for these then. as long as I control the keys and can easily plug this in with opensource standard libraries it’s fine for me, I can actually use it.
If I may, get in contact with someone at Red Hat, there are tons of people who are probably gonna be interested in this and you’ll find a community there very much interested in these sorts of things, as I said proper biometrics is a mess, a total mess. most of what I see is still handled with SmartCard (and a good amount with hardware keyboards for PIN), the only thing that really started to move that space is the yubikey, recently openssh (8.2) implemented FIDO/U2F mainly because of the pressure coming from users wanting to deploy their yubikey seriously.
that is absolutely wonderful news, you have a customer (and a couple of colleagues already) lined up.
good luck with Windows logon, it’s painful, I know, not really interested in that because I won’t ask users to implant a chip, but sysadmin and server people, we’re already on board man!
The FIPS compliance is a feature of NXP chips if I am remembering correctly.
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.
This is my field as a dayjob (currently), and I can’t wait.
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;
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.
As stated above, you do not need to do this in order to deploy your own applets.
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…
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.
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.
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.
5 Likes
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.
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.
1 Like
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.
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.
1 Like
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).
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!
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).