I absolutely agree, and If I may there’s also “business” reasons, I mean, ssh keys and secure access to servers, biometrics hasn’t really taken off, but the YUBIKEY has, I see it, last time I checked this space, I mean under the skin implants, there was absolutely no way to do proper auth on these, now the hardware is there and it just seems to be a matter of business strategy, don’t get me wrong I understand completely what they are offering to end-users, cool have you bitwarden throught their 0auth service, I have my own auth systems tho and I can manage the crypto, even write the code if required, but most importantly I need to plug these things in RHEL systems, or proper enterprise linux systems, and this means I need to plug them directly into opensource standard system libraries, YUBIKEY is just a crypto device that exposes the crypto functionalities via a device driver, give me something like that and this is ready for proper enterprise adotpion and as I said in another post in this thread I see this sort of a 2,5FA, it’s not a proper “who you are” factor, but proper biometrics comes with it’s own hurdles, an implant is an actual “what you have” factor, like the YUBIKEY, but it’s a lot more secure, and I mean legally speaking, you can’t tell me you lost your key and somebody stole it alongside your password, if this gets stolen somebody had to cut open your skin, it’s a different legal scenario, and this makes a world of difference to me (and a lot of businesses I’d guess)
Java Cards makes kitten cries, but yeah, they seem like an alternative, do you think they will be able to do something better than AES-256?
By the way, I forgot to mention: you did ask if you could use RFID for 2FA on Linux with PAM integration. You didn’t say anything about crypto. SiRFIDaL will do 2FA (or 3FA or whatever) with UUIDs (check out this file for details). So technically, my answer was correct 
I presume so. I suppose you can code your own crypto too if you need to. But I haven’t looked at it, since I’m not interested atm.
@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?
they are an 0auth provider If I understood that correctly, so basically I can build something that uses them as a 0auth provider and I will be able to do the proper auth chain, even if I don’t control the actual keys.
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, and that’s a no-no wherever you need that level of security, using a third party provider is too much of a hassle, if you were instead to be able to control the crypto and just use the hardware functions, then yes, companies that need that level of security would consider this I believe.
your project is really nice, I’m still thinking about getting a spark2 and use their services (and your project as well) just to try out having something under my skin and using that.
I feel there’s a mislabeling in your descriptions, tho, the authentication factors are 1) What you know 2) What you have 3) who you are.
2FA is what you know, user and password, and what you have, the hardware token or the emulated hardware token like google authenticator, which is on you phone and tied to that object. who you are is proper biometric, so even if you need two RFIDs (or any number of them) and even if they are under the skin this is just 2FA, a user/pwd and some object, it doesn’t even requires the object to provide any crypto and challenge/response protocol of any sort with derived temporary keys or whatever technique.
Obviously proper 2FA requires the object to hold a key inside a chip that never leaves it, or that key could be intercepted, and that’s why simple plain UUIDs are not enough to me.
I still consider under the skin implant somewhat different from a plain “what you have” condition, because as I said it’s easy to steal a usb token or a phone, it’s not easy to steal an implant.
That’s accurate, it’s pretty bleh at the moment. The reason these stupid restrictions on the perso keys need to be imposed is because it’s the only way to get EMV onboard. They don’t play nice with personalization and they don’t like hackers. For the implants to be compatible with payments, we have to play by their rules.
As far as I can tell, the biggest reason that there aren’t two versions of the Apex line being offered (one with Fidesmo holding the keys and one with the user having complete control from the start) is because of the minimum order quantities that are required to get economies of scale out of this. Companies like NXP aren’t set up for small demographics like us. You need to order a million chips too make it worth it. There’s not a million people who would want complete control over their chip like you or I do, so there’s no viable market path to VivoKey making that implant.
What has been done is that any contracts signed between VivoKey and payment or service providers include a clause that allows users to completely opt out of the service and regain control of their keys. That way VivoKey can still order shit tons of chips and retain control for that subset of users that want it.
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.
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.
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.
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.
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!