It seems that Vivokey is no longer an approved FIDO2 passkey vendor according to Microsoft and the FIDO alliance page.
This change has essentially rendered both my Apex implants useless for what I bought them for. They quite literally do not work despite nothing changing on my end. I get attestation enforcement errors about forbidden device types.
Is this going to be permanent? What are my options if this is permanent?
If anyone involved could please reach out, I would greatly appreciate it.
It actually never was approved (certified), only listed in the FIDO metabase as uncertified. Something must have changed on the Microsoft side.
You can change attestation requirements in Entra ID settings, and I believe you can even add specific AAGUID exemptions.
To leave “Enforce attestation” enabled, you should be able to add our AAGUID to the Allow list. This screen shot shows a block list, but if you slide the slider over to Allow it should present a whitelist you can add the VivoKey AAGUID to.
The Apex was never certified.. so my guess is that Microsoft was just accepting any token in the metabase, certified or not. Someone at Microsoft must have realized they were accepting any uncertified token as long as it was listed.. so they scrubbed their list.
If that’s the case then I think the only solution would be to achieve certification. That is an expensive and tedious process, and until now we had no reason to prioritize it since basically nothing we had every run into actually required it.. including Microsoft.
I will reprioritize this, but certification takes a long time. Not just the paperwork, but also the process of actually doing the testing. One part requires showing up in person to a big meetup and testing your hardware in person. The meetups are held a couple times a year. It’s crazy.
I legitimately crying right now. I’m in over a thousand dollars between hardware and installs and now I can’t use them for the express purpose I got them for. Going from a usable product to bricked in less than six months is soul crushing.
I understand. On the bright side, they aren’t bricked.. they’re just resting Full operation is possible once again, this is just the first time ever that the lack of certification has been a problem.. like ever. We will spend the $10,000+ and months of time it costs to get certified.
I’m not upset at you guys. Like you said you had no clue. I’ve just been logged out of all my critical work systems and had to request support for a bunch of systems that looks really crappy on me to say I need to have all my passkeys unbound and get a org issued yubikey mailed to me. I’m out for days until it gets here.
Thank you for your understanding, but really it should have been on us to push toward certification.. it was only a matter of time before something like this happened, but because it was “fine for the moment” we kept deprioritizing it. Well now it’s an issue.. the rudder is shifting.. the boat is turning in this direction.
As an aside, I checked the fido metadata blob and we are still listed there, so it’s definitely Microsoft who changed something and blocked us out.
I wonder if they use a Microsoft FIDO technology on the backend. Like I said, nothing changed with our applet, attestation cert, or the metadata listing.. something else has changed. Definitely update this thread if you run into more problems using previously accessible sites / services.
I will be testing them everywhere I’ve enrolled one and will let you know. Thanks again for looking into this for me as quickly as you did. I know it’s not the answer I or you hoped to discover, especially in this manner, but I really do appreciate knowing an answer.
The old CTAP 2.0 (“FIDO 2.0”) implementation (proprietary applet written by me, internal name apex-fido2) uses the AAGUID d7a423ad-3e19-4492-9200-78137dccc136and is listed in the FIDO MDS Database as “VivoKey Apex FIDO2” / NOT_FIDO_CERTIFIED
The new and currently distributed CTAP 2.1 (“FIDO 2.1”) implementation (open source applet written by Bryan, internal name FIDO2Applet , source at GitHub - BryanJacobs/FIDO2Applet: FIDO2 Javacard Applet ) used the AAGUID c8468938-2e9f-4e93-82ca-e59cd24d67d8 and is not listed at all in the FIDO MDS Database. We cannot re-use the other FIDO2 AAGUID as the set of extensions, capabilities, and protocols has changed.
Since Microsoft previously accepted the new FIDO2 applet just as well, I think they never checked the MDS at all. Now, it seems they do check it. However I don’t know if they enforce just a simple entry in the MDS, or actually a full certification. Anyway, as updating a MDS entry is hard and sometimes impossible, we will probably only add the MDS entry once the new applet is certified with at least Level 1. We could think about chaning the AAGUID again for the fully-certified applet and adding an entry for the non-certified applet with a different AAGUID, but I am not sure if that would even solve the problem - since Microsoft is probably checking for certification.
Your authenticator needs to have a FIDO2 certification. This can be at any level. To learn more about the certification, visit the FIDO Alliance Certification Overview website.
Your product metadata needs to be uploaded to the FIDO Alliance MDS, and you need to verify your metadata is in the MDS. The metadata must indicate that your authenticator supports:
FIDO 2.0 or higher.
User verification or client PIN - Microsoft Entra ID requires user verification with biometrics or PIN for all FIDO2 authentication attempts.
Resident keys (or discoverable credentials) - Resident keys are required for using a security key to sign in to Microsoft Entra ID without entering a username.
Hash-Based Message Authenticator Codes (HMAC) secret extension or Pseudo-Random Function (PRF) extension - An HMAC secret extension or PRF extension is required for using a security key to unlock Windows in offline scenarios.
We currently comply with all technical requirements (we support CTAP2.1, client PIN protocol 1 & 2, resident keys, and hmac-secret), however the certification (we aim for Level 1, the easiest and “““cheapest””” one) and MDS entry are still missing.
Another small tip from my side: Never entrust the access to your digital kingdom to only a single piece of hardware. Not a single YubiKey, not a single Implant. I guess this was a painful lesson, but hardware can and will break, so just make sure to have some backups from this point on.
Anyway, FIDO certification is back on the menu but will take time and money, both of which are kind of hard to come by in large quantities
I think two separate things were happening that look related but were handled by two completely different sets of people and processes. As is typical with large companies, especially microsoft, one hand probably didn’t know what the other was doing.
I think the first thing was that there was this list mentioned above. That list was just the MDS listings, which ignored whether or not the token was certified. The list just contained a list of tokens in the MDS regardless of certification status.
The other thing that was going on was the actual allowance of token use. This appeared to have no connection to the actual list or MDS, as is evidenced by our currently unlisted FIDO2 AAGUID being used by many people to access Entra ID instances.
At some point, it appears that someone came to unify these two things and rectify the problems therein. Firstly our uncertified token was removed from the list of allowed tokens. Secondly that list now appears to actually be implemented within the authentication structure and processes of Entra ID.
We will pursue certification of our current applet instance with all its features and bells and whistles. Once we achieve that we will submit the aaguid to the MDS, and all should be well.
Maybe a stupid question… I’m looking into purchasing a flexSecure implant as I’d like the flexibility to write/modify/deploy applets on my own outside of the Vivokey platform. If/when certification is completed, would that cover the applet running on the flexSecure devices as well, or only the Apex/Vivokey devices?
As all the applets and their data are self-managed on the flexSecure, you deploy the FIDO2 applet yourself, and also generate, sign and deploy your own attestation certificate. So no, whatever “official” FIDO certified VivoKey attestation certificate can only be deployed to the Apex at this time, as it requires a secure delivery channel to not leak out (Fidesmo remote secure channel for the Apex). The flexSecure is meant to be more a development platform, or for users which exactly know what they are doing and want to compile and sideload their own stuff and data.
You could of course go though the pain to register and certify your own certificate with FIDO, but I would not recommend doing that. There is a discussion to be had if VivoKey could offer a FOSS FIDO certified attestation certificate free for use with the flexSecure, but I am quite sure that would not fly with the security / non-forgery requirements of FIDO.
However, there are ideas on the far horizon to establish a secure connection to the flexSecure to load official certificates / proprietary applets as well. There is no ETA or concrete plan for that though (yet).
That all being said: Right now Microsoft Entra is the only instance which actually checks the certification level that I know of. So your flexSecure with a DIY certificate shold still be good for pretty much anything else.
I have to use approved hardware.
Full operation is possible once again, this is just the first time ever that the lack of certification has been a problem.. like ever. We will spend the $10,000+ and months of time it costs to get certified.