It's actually easier to support this in Linux than a "conventional" PIN-based FIDO2 token because the Linux system doesn't need to arrange to read a PIN from the user and send that to the token, the token is going to read the user's fingerprint instead.
If you just want a second factor, it'll work like an old FIDO device, which you might be familiar with for U2F - everything is already in place, loads of people are doing this including with Yubico's existing FIDO2 (pin-based) product.
If you want this to be the sole factor (as in the Windows demos or for a site where the convenience of one touch login is good but you don't need MFA security) that ought to work with WebAuthn out of the box, but I actually haven't seen a demo, so I can't say this from personal experience even though I own a FIDO2 token.
Thanks. So that‡ works on my Windows gaming laptop with Chrome, but not (with the same FIDO2 token) with Firefox including on any of my Linux systems (I don't run Chrome on Linux so did not test). Plenty of work to be done there apparently. Good to know.
‡ Referring to "Go usernameless too" which is the mode where a PIN is needed. All the other modes are just plain FIDO and don't need any further verification, and they work just fine on all my systems with any of my tokens.
The flag you're talking about is (as its name hints) about the legacy U2F which can't do this flow at all. As I explained this already works fine and I use it every day.
Using the FIDO2 Yubikey as sole source of truth replacing usernames and passwords is not available in U2F that's a WebAuthn feature only and apparently it doesn't work in Firefox yet which is disappointing.
I /presume/ that no Linux desktop setups today actually support this workflow for user login, which is one of the things touted for Windows.
For Firefox since they advertise support for WebAuthn I /presume/ that the browser will do all the PIN prompts and so on to make this work, but again I have never seen this even _demonstrated_ let alone used in anger. The browser feature doesn't help you if the PC has booted and is at the login screen though, no browser there (yet?).
I own a device (Yubico's own "Security Key 2") which supports this workflow and I've played with it on a demo Windows setup, and though I'd probably never use it to sign into my Linux PCs I'd try it out because I'm a nerd. This device works fine as a FIDO key for my WebAuthn accounts and is enrolled at GitHub etcetera for that purpose but then so does my much cheaper Key-ID FIDO key.
Edited to add: There are a couple of replies now talking about non-FIDO flows like Smartcards or whatever. Some of Yubico's other devices can do these, but we're talking about FIDO2 like this new Yubikey, those flows aren't relevant.
> I /presume/ that no Linux desktop setups today actually support this workflow for user login,
I login to my Linux desktops with a Yubikey and its PIN. I have it configured as a OpenPGP smartcard, and to authenticate (for login, raising privileges with sudo, or unlocking the screen, etc.), I use the poldi[1] PAM module.
One thing that has been frustrating with the OpenPGP setup with the Yubikey has been the inability to re-add the stub key entries after they are deleted from the host. I do edit-card, unlock and fetch but the entry doesn't show, rendering it useless in `gpg`.
"fetch" fetches from the URL you set in the card/Yubikey. If you put the public key on an HTTP server and put the URL in the Yubikey (with the "url" command after enabling "admin" commands), you can fetch it with "fetch".
Getting the public key out from an OpenPGP smartcard otherwise is not supported by the protocol it uses. That is frustrating that it wasn't included in the procotol, but I've gotten over it.
After you've imported the public key, getting the private key stubs is a matter of checking the status of the card with `gpg --card-status`. The stubs are added then.
If you have another machine that has the public key, you can export it with `gpg --export -a $key_identity`, and import it with `gpg --import < $exported_public_key_file`.
Otherwise, if you don't hold another copy of the public key, the only option left might be to make a new keypair and be careful to not lose all copies of the public key again.
Also, if you backup the private key, you can get the public key from it by importing it somewhere.
Regarding your edit the problem here is that you assume that U2F/FIDO is some sort of a new, separate thing when in fact it can be just one 'program' or applet of your device which can support others, that are more suitable for logins. FIDO just wasn't designed for it.
Just because this or some other Yubico devices might not allow it doesn't mean others don't. AFAIK for instance Feitian ePass supports GIDS applet, which you can install on smartcards too. And yes, you can install U2F applet on smartcards also.
I was going to say how associated software is not required to use some features, but I see that what you quoted continues with:
> The key seamlessly integrates with the native biometric enrollment and management features supported in the latest versions of Windows 10 and Azure Active Directory, making it quick and convenient for users to adopt a phishing-resistant passwordless login flow.
So I'm also curious if this indicates that biometric enrollment is not going to be added to yubikey-manager or yubico-pam.
I think they’re talking about Windows Hello in that blurb, not requiring some special Windows software to enable the fingerprint sensor. That would be very much against their philosophy of keeping all the processing on the device.
FWIW, the current YubiKey does everything on the device, not much of a stretch for it to also do the fingerprint sensing there too.
I think the concern is how would you tell the key that you want to enroll a fingerprint with it? On Windows, you'd use Windows software, but Linux has no such biometric management software as far as I know.
This will surely need enough computer help to initiate the process, but the actual biometric data is likely on the dongle itself.
Alternatively, the dongle could produce a wrapped key blob that contains a fingerprint. This would look almost like a normal FIDO enrollment and would allow multiple users to share one dongle with access to different keys.
Hopefully. The concern is if what the article says is indication that they won't, or at least not for some time. Does "does not require associated software because Windows doesn't need it" mean that they didn't see a point in making the associated software for a user minority? That's what I think the concern is.
I believe the device performs it's biometric verification entirely on device. The operating system should see the key no differently that a regular non-biometric key.
The biometric verification, yes, but you need to somehow register/enroll a fingerprint with it. The article says that it's going to depend on Windows' native biometric enrollment and management for that.
Enrollment is a FIDO thing. If you have a FIDO key then you've done enrollment, it was that first time you had to press the button when you'd already signed in and were adding it as a second factor.
For a fingerprint (or like, I dunno, a pinprick blood sample, or maybe they'll make one that requires a freshly plucked hair from your head) that enrollment step just adds a boolean flag saying the Relying Party demands the user's identity be verified by the device during enrollment and any subsequent authorisations.
It's sort of on the honour system, except, if you actually demanded this (maybe in a corporate environment?) FIDO has a mechanism for devices to provide a certificate proving which batch of devices they're from, so you could say OK, I trust Yubico's BioKey 4.1 and BioKey 4.2 and the FooCorp EyeBallSlicer 1000 but any other devices aren't allowed to enroll. If you then found out the BioKey 4.1 can be fooled by breathing on it instead of a fingerprint you'd remove that from your whitelist.
Firefox (and maybe Chrome?) let you blank this out basically, so sites can either accept that you won't tell them what device it is or they can refuse to let you enroll. I can imagine _maybe_ making an exception for my bank or government, but any other site can fuck right off.
Doesn’t that imply that each fingerprint registration becomes per website? So if you want to add a second finger to the device after the fact, you can’t just add it globally to the device but need to do that on a per-credential basis?
I’d be very surprised if anything, including the enrollment, happened off the device. Likely all it involves is sending a “register my fingerprint now” message being sent to the YK, you touch it, then the YK works as expected. They already provide a Linux-native “YK management” program, presumably it just needs to be updated.
It uses a standard protocol (CTAP2 - https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-cl...) that's part of the standards for FIDO2. IIRC as long as your OS lets your application speak to the YubiKey over USB, you should be able to use this in the application. In the browser, you can just use WebAuthn.
Only the static password and one time password modes though. In those modes, the YubiKey acts like a keyboard and literally types out the password when the user presses the button.
The flagship YubiKeys can also act like a smart card. They are PIV compatible and support X.509 certificates. They can also store encryption, authentication and signing OpenPGP keys. GNU Privacy Guard opens the YubiKey as if it was a smart card.
If you wanted the absolutely easiest possible option, you can have yubikey's act as a HID and dump a string of text (password) out. Any machine, without any additional software, that can support a USB keyboard... could then use this.
"In keeping with Yubico’s design philosophy, the YubiKey Bio will not require any batteries, drivers, or associated software."