When the Google Online Security blog announced earlier this week the general availability of Security Key, everybody at the office was thrilled, as we’ve been waiting for the day for a while. I’ve been using this for a while already, and my hope is for it to be easy enough for my mother and my sister, as well as my friends, to start using it.
While the promise is for a hassle-free second factor authenticator, it turns out it might not be as simple as originally intended, at least on Linux, at least right now.
Let’s start with the hardware, as there are four different options of hardware that you can choose from:
- Yubico FIDO U2F which is a simple option only supporting the U2F protocol, no configuration needed;
- Plug-up FIDO U2F which is a cheaper alternative for the same features — I have not witnessed whether it is as sturdy as the Yubico one, so I can’t vouch for it;
- Yubikey NEO which provides multiple interface, including OTP (not usable together with U2F), OpenPGP and NFC;
- Yubikey NEO-n the same as above, without NFC, and in a very tiny form factor designed to be left semi-permanently in a computer or laptop.
I got the NEO, but mostly to be used with LastPass – the NFC support allows you to have 2FA on the phone without having to type it back from a computer – and a NEO-n to leave installed on one of my computers. I already had a NEO from work to use as well. The NEO requires configuration, so I’ll get back at it in a moment.
The U2F devices are accessible via hidraw, a driverless access protocol for USB devices, originally intended for devices such as keyboards and mice but also leveraged by UPSes. What happen though is that you need access to the device, that the Linux kernel will make by default accessible only by root, for good reasons.
To make the device accessible to you, the user actually at the keyboard of the computer, you have to use udev rules, and those are, as always, not straightforward. My personal hacky choice is to make all the Yubico devices accessible — the main reason being that I don’t know all of the compatible USB Product IDs, as some of them are not really available to buy but come from instance from developer mode devices that I may or may not end up using.
If you’re using systemd with device ACLs (in Gentoo, that would be sys-apps/systemd with acl USE flag enabled), you can do it with a file as follows:
# /etc/udev/rules.d/90-u2f-securitykey.rules
ATTRS{idVendor}=="1050", TAG+="uaccess"
ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", TAG+="uaccess"If you’re not using systemd or ACLs, you can use the plugdev group and instead do it this way:
# /etc/udev/rules.d/90-u2f-securitykey.rules
ATTRS{idVendor}=="1050", GROUP="plugdev", MODE="0660"
ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", GROUP="plugdev", MODE="0660"These rules do not include support for the Plug-up because I have no idea what their VID/PID pairs are, I asked Janne who got one so I can amend this later. Edit: added the rules for the Plug-up device. Cute their use of f1d0 as device id.
Also note that there are properly less hacky solutions to get the ownership of the devices right, but I’ll leave it to the systemd devs to figure out how to include in the default ruleset.
These rules will not only allow your user to access /dev/hidraw0 but also to the /dev/bus/usb/* devices. This is intentional: Chrome (and Chromium, the open-source version works as well) use the U2F devices in two different modes: one is through a built-in extension that works with Google assets, and it accesses the low-level device as /dev/bus/usb/*, the other is through a Chrome extension which uses /dev/hidraw* and is meant to be used by all websites. The latter is the actually standardized specification and how you’re supposed to use it right now. I don’t know if the former workflow is going to be deprecated at some point, but I wouldn’t be surprised.
For those like me who bought the NEO devices, you’ll have to enable the U2F mode — while Yubico provides the linked step-by-step guide, it was not really completely correct for me on Gentoo, but it should be less complicated now: I packaged the app-crypt/yubikey-neo-manager app, which already brings in all the necessary software, including the latest version of app-crypt/ccid required to use the CCID interface on U2F-enabled NEOs. And if you already created the udev rules file as I noted above, it’ll work without you using root privileges. Just remember that if you are interested in the OpenPGP support you’ll need the pcscd service (it should auto-start with both OpenRC and systemd anyway).
I’ll recount separately the issues with packaging the software. In the meantime make sure you keep your accounts safe, and let’s all hope that more sites will start protecting your accounts with U2F — I’ll also write a separate opinion piece on why U2F is important and why it is better than OTP, this is just meant as documentation, howto set up the U2F devices on your Linux systems.
The Plug-up Fido U2F key has 2581:f1d0 as vendor/product id pair.I wouldn’t vouch for the durability on a key chain but I guess it would survive at least a couple of months. The plastic is approximately 50% thicker than a standard credit card.
Do I get it correctly that switching form OTP to U2F still let’s me access my lastpass as before?
One difference between the Yubico and Plug-up Fido U2F keys. The Plug-up has no key so it has to be removed and inserted for each authentication.
Justin, no if you enable U2F it disables OTP and LastPass only supports OTP as of right now. I’m waiting on them supporting U2F, I’m sure it’s going to happen anytime soon.
Thank you.
Can the Yubikey NEO store or emit a static passphrase? I currently store a passphrase on a USB stick that is used to automatically unlock a LUKS encrypted storage drive during boot. I would like to use the Yubikey for this purpose in addition to U2F authentication.
No, beside the fact that U2F disables OTP output altogether, there is no way to configure it with a pre-defined passphrase.
It appears that the Yubikey (NEO?) can be configured to store a pre-defined passphrase. The configuration instructions[1] apply to TrueCrypt but I believe it should also work for any application. Unless this functionality is disabled with U2F?[1] https://www.yubico.com/appl…
AFAICT that only applies to the YubiKey standard, rather than the NEO. Or maybe it works on the NEO if in OTP mode as well, not sure.The main problem is that OTP will be disabled the moment you enable U2F as the two are mutually exclusive right now.
There is a post[1] on the Yubico forum that explains why you can’t have both OTP and U2F modes enabled at the same time. Interestingly it also explains how to force the Yubikey NEO into OTP+U2F mode.[1] http://forum.yubico.com/vie…
I bought a Fido U2F to test, not sure how it will hold up but it worked fine after I activated hidraw (not sure why I had that disabled in my kernel config).Proper out-of-the-box permissions would be nice though 🙂
If you had installed libu2f-host it would have had the right permissions (and warned you about the missing HIDRAW). But yes, I agree it should be accessible by default udev rules.
I wrote a udev patch to do this The Right Way ™:http://lists.freedesktop.or…No comments yet…
Has anybody actually been brave enough to configure their NEO into the OTP+U2F+CCID mode via the linux tool workaround “ykpersonalize -m6” mentioned in the yubikey forum?It can be a bit unsettling to find out that the yubikey Linux tools currently do not even properly detect NEOs configured for U2F+CCID. I did this using ykpersonalize as well as with the windows tool: foo@bar:~$ ykneomgr -m 82 foo@bar:~$ ykinfo -v version: 3.3.0 foo@bar:~$ ykpersonalize -m5 ## then unplug / replug foo@bar:~$ ykneomgr -m 05 foo@bar:~$ ykneomgr -l 0: Yubico Yubikey NEO U2F+CCID 00 00 foo@bar:~$ ykinfo -v Yubikey core error: no yubikey present foo@bar:~$ ykpersonalize -m82 Yubikey core error: no yubikey presentOops..I found out that it’s possible to set the mode back to OTP+CCID using either the windows version of the yubkey personalization tool or by running foo@bar:~$ ykneomgr -M82 ## then unplug / replug foo@bar:~$ ykneomgr -m 82 foo@bar:~$ ykneomgr -l 0: Yubico Yubikey NEO OTP+CCID 00 00 foo@bar:~$ ykinfo -v version: 3.3.0This was under Debian jessie with the latest yk packages. I compiled them again from source and debugged a little to find that the function “yk_open_first_key” in https://github.com/Yubico/y… is not checking for the USB product ID “NEO_U2F_CCID_PID”. After adding it, the device is recognized but apparently that’s not enough to make the tools work properly as I get timeout errors when using ykpersonalize to change the mode back to OTP+CCID.The function checks for NEO_OTP_U2F_CCID_PID though, so maybe in that case the Linux tools could cope..Btw: The windows tool sets mode 5 when selecting U2F+CCID, not 85. Not sure if it also could set the eject flag.One last comment about PAM: It’s probably pretty obvious from what I said above, but none the less: pam_yubikey in challenge+response mode works for me when the key is in OTP+CCID mode but the key is not detected in U2F+CCID. I’ll report once I’ve tried with OTF+U2F+CCID, I’ll stay away from it for now to avoid soft-bricking 🙂 I guess we need to provide some patches for the Linux tools.
Sorry for the editing mess, don’t know what happened to that… but you get the idea.. 🙂
Note that under archlinux 90-* is too late for uaccess.Calling the file:# /etc/udev/rules.d/60-u2f-securitykey.rulesworks.
I got “error code 1” when testing U2F on OpenSuse 42.3 with Yubikey (neo). After reading this article I found that it’s the same permission problem of /dev/hidraw* devices. They are all by default root:root. So the test page errors immediately when the USB key is plugged in, even before pressing the button.I’m not sure if I’m doing it right. I’m giving “users” group rw permission to the Yubikey U2F devices:“`# /etc/udev/rules.d/90-u2f-securitykey.rulesATTRS{idVendor}==”1050″, GROUP=”users”, MODE=”0660″ATTRS{idVendor}==”2581″, ATTRS{idProduct}==”f1d0″, GROUP=”users”, MODE=”0660″“`So I guess that a few other non-Yubico U2F keys that didn’t work with Ubuntu had the same issue, but they probably need config files with different idVendor/idProduct numbers.
It looks like the libu2f-host [1] version in OpenSUSE is a bit out of date.The last release was this August, after I pinged the Yubico folks to make a new release — Google was giving out Feitian U2F keys that were not supported by the latest release, right next to the Yubico stand, so it was easy to report :D[1] https://software.opensuse.o…