GnuPG and CCID support

As many of you probably know already, I use GnuPG with OpenPGP cards not only for encryption but also for SSH access. As some or others probably noticed on Twitter, I recently decided to restore to life my old Dell Latitude laptop, but since it’s a fairly old system I decided to try running something else rather than Gentoo on it, for the first time in many years. I settled on Antergos, which is a more user friendly install option for Arch Linux. Since I know a number of current or past Arch Linux developers, it seemed fitting.

Beside the obvious problems of Arch not being Gentoo, the first biggest problem I found was being unable to use the smartcard reader in the Dell laptop. The problem is that the BCM5880 device that this laptop comes from, is not quite the most friendly CCID device out there. Actually, it might have a better firmware available but I need to figure out how to install it, since it requires a Windows install and I don’t have one on this laptop.

But why did this work fine with Gentoo and not fine with Arch? Well the answer is that the default install of GnuPG from pacman enables the GnuPG own CCID driver. In my original drawing on the matter I did not capture the fact that GnuPG has its own CCID driver — although I did capture that in a follow-up diagram. This driver is fairly minimal. The idea is that for simple devices, where they implement the standard pretty closely, the driver works fine, and it reduces the amount of dependencies needed to get a smartcard or token working. Unfortunately the number of devices that appear to implement the CCID standard correctly is fairly low in my experience, and the end result is that you still end up having to use pcsc-lite to get this to work as intended.

Luckily, Arch Linux wiki has the answer and you do not need to rebuild GnuPG for this to work. Yay.

It may be easy to say “fix GnuPG” but the list of devices that are not CCID compliant is big, and Ludovic already has workarounds for most of them in the CCID driver. So why should that list of broken devices be repeated somewhere else? There really is no need. if anything, you may ask why the CCID driver is not an interface-independent library that GnuPG can just access directly, and there are actually a few good reasons why this is not the case. The first of which is that it would be pointless to depend on the small driver but not the pcsclite package that implements the otherwise more widely available interface.

As it turns out, though, the particular Gemalto device I use as my primary card card nowadays is actually pretty much CCID compliant, so it could be used with the GnuPG’s own CCID driver, sparing me the need to install and maintain pcsclite and ccid on my other laptop. Which would also mean I could avoid maintaining the packages in Gentoo even. But here is one of the biggest catches: the devices are not by default accessible to the console user. Indeed even when I made it easier to use pcscd and ccid a whopping six years ago, I only set up the udev rules when the CCID driver was installed.

You could expect systemd to just install by default a rule that allows CCID standard devices to be accessible to the console user, and that would make it possible to use GnuPG and its CCID driver with whichever common standard-compliant devices are available. Which I hope (but I have not tested) include the YubiKey 4 (don’t care aobut the NEO, since then you need to make sure to also have the right firmware, as the older ones have a nasty PIN bypass vulnerability.

But then again, I wonder if there are any security issue I don’t really expect that may be impeding a plan like this. Also, given the much wider compatibility of pcsclite with the devices, not only for CCID but for other non-standard protocols too, I would rather be interested to know if you could run pcscd as a user directly, maybe with proper systemd integration — because if there is one good thing about systemd is the ability to run proper per-user services, in a standardised fashion rather than having to fake it the way KDE and GNOME have done for so many years.

As for maintaining the packages on Gentoo, it is not bad at all. The releases are usually good, and very rarely problems came up during packaging. Ludovic’s handling fo the one security issue with pcsc-lite in the past few years has been a bit so-so, as he did not qualify the importance of the security issue in the changelog of the new release that fixed it, but except for that it was punctual and worked fine. The main problem that I have with those tools is having to deal with Alioth, which has this silly idea of adding an unique numeric ID to each file download, and then providing you with the file with whichever name you provide it when you download. Which effectively means you need to update the ID from the Alioth website every time a new release comes up, which is actually annoying.

Packaging for the Yubikey NEO, a frustrating adventure

I have already posted a howto on how to set up the YubiKey NEO and YubiKey NEO-n for U2F, and I promised I would write a bit more on the adventure to get the software packaged in Gentoo.

You have to realize at first that my relationship with Yubico has not always being straightforward. I have at least once decided against working on the Yubico set of libraries in Gentoo because I could not get a hold of a device as I wanted to use it. But luckily now I was able to place an order with them (for some two thousands euro) and I have my devices.

But Yubico’s code is usually quite well written, and designed to be packaged much more easily than most other device-specific middleware, so I cannot complain too much. Indeed, they split and release separately different libraries with different goals, so that you don’t need to wait for enough magnitude to be pulled for them to make a new release. They also actively maintain their code in GitHub, and then push proper make dist releases on their website. They are in many ways a packager’s dream company.

But let’s get back to the devices themselves. The NEO and NEO-n come with three different interfaces: OTP (old-style YubiKey, just much longer keys), CCID (Smartcard interface) and U2F. By default the devices are configured as OTP only, which I find a bit strange to be honest. It is also the case that at the moment you cannot enable both U2F and OTP modes, I assume because there is a conflict on how the “touch” interaction behaves, indeed there is a touch-based interaction on the CCID mode that gets entirely disabled once enabling either of U2F or OTP, but the two can’t share.

What is not obvious from the website is that to enable U2F (or CCID) modes, you need to use yubikey-neo-manager, an open-source app that can reconfigure the basics of the Yubico device. So I had to package the app for Gentoo of course, together with its dependencies, which turned out to be two libraries (okay actually three, but the third one sys-auth/ykpers was already packaged in Gentoo — and actually originally committed by me with Brant proxy-maintaining it, the world is small, sometimes). It was not too bad but there were a few things that might be worth noting down.

First of all, I had to deal with dev-libs/hidapi that allows programmatic access to raw HID USB devices: the ebuild failed for me, both because it was not depending on udev, and because it was unable to find the libusb headers — turned out to be caused by bashisms in the configure.ac file, which became obvious as I moved to dash. I have now fixed the ebuild and sent a pull request upstream.

This was the only real hard part at first, since the rest of the ebuilds, for app-crypt/libykneomgr and app-crypt/yubikey-neo-manager were mostly straightforward — only I had to figure out how to install a Python package as I never did so before. It’s actually fun how distutils will error out with a violation of install paths if easy_install tries to bring in a non-installed package such as nose, way before the Portage sandbox triggers.

The problems started when trying to use the programs, doubly so because I don’t keep a copy of the Gentoo tree on the laptop, so I wrote the ebuilds on the headless server and then tried to run them on the actual hardware. First of all, you need to have access to the devices to be able to set them up; the libu2f-host package will install udev rules to allow the plugdev group access to the hidraw devices — but it also needed a pull request to fix them. I also added an alternative version of the rules for systemd users that does not rely on the group but rather uses the ACL support (I was surprised, I essentially suggested the same approach to replace pam_console years ago!)

Unfortunately that only works once the device is already set in U2F mode, which does not work when you’re setting up the NEO for the first time, so I originally set it up using kdesu. I have since decided that the better way is to use the udev rules I posted in my howto post.

After this, I switched off OTP, and enabled U2F and CCID interfaces on the device — and I couldn’t make it stick, the manager would keep telling me that the CCID interface was disabled, even though the USB descriptor properly called it “Yubikey NEO U2F+CCID”. It took me a while to figure out that the problem was in the app-crypt/ccid driver, and indeed the change log for the latest version points out support for specifically the U2F+CCID device.

I have updated the ebuilds afterwards, not only to depend on the right version of the CCID driver – the README for libykneomgr does tell you to install pcsc-lite but not about the CCID driver you need – but also to check for the HIDRAW kernel driver, as otherwise you won’t be able to either configure or use the U2F device for non-Google domains.

Now there is one more part of the story that needs to be told, but in a different post: getting GnuPG to work with the OpenPGP applet on the NEO-n. It was not as straightforward as it could have been and it did lead to disappointment. I’ll be a good post for next week.

Setting up Yubikey NEO and U2F on Gentoo (and Linux in general)

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 mean time 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.

Where did I disappear? A collection of random status reports

Before people end up thinking I’ve been hiding, or was eaten by the grues while thoroughly labelling my cables – by the way, a huge thanks goes to kondor6c! By running this cleanup operation I finally understood why Yamato and Raven had problems when power was cut: by mistake the AP bridge connecting me to the rest of the network was not connected behind the UPS – I would just like to quickly point out that the reason why I seem less active than usual is that I’m unfortunately forced to spend a lot of time on a daily job right now, namely writing a final report on LScube which will serve as a basis for the future documentation and, hopefully new website.

Speaking about documentation, I’ve been receiving a number of requests to make Autotools Mythbuster available as a single download — I plan on doing so as soon as I can find enough free time to work on that in a relaxing environment.

You might remember though, that originally intended to work on the guide on something nearing full time under compensation; this was not a matter of simple greed but the fact that, to keep it relevant and up to date, it requires more time than I could afford to give it without something paying my bills. Given that, I plan on adding an offline Flattr barcode on the cover when I’ll make it available in PDF.

If you wish to see this happening sooner rather than later, you can generally resort my priorities by showing your appreciation for the guide — it really doesn’t matter how much your flattr is worth, any bit helps and knowing you do want to see the guide extended and available for download is important to me.

Next up in line on the list of things I have to let you know is that in my Portage overlay you can now find a patched, hacked version of pcsc-lite making the libusb device discovery feign being libhal. The reason is a bit far-fetched, but if you remember my pcsc-lite changes Gentoo is dropping HAL support whenever possible; unfortunately pcsc-lite considers HAL the current discovery and libusb the “legacy” one, with the future moving to libudev as soon as Ludovic has a plan for it. In the interim, libusb should work fine for most situations.. fortunately (or not, depends on the point of view) I hit one of those situations where libhal was the only way to get it working properly.

In particular, after a security device firmware update (which has to happen strictly under Windows, dang!), my laptop – of which I have to review the opinion, the only things not working properly right now are the touchpad, for which work is underway, and the fingerprint reader, that seems to be a lost cause – now exposes the RFID contactless smartcard reader as a CCID device. For those not speaking cryptogeek, this means that the interface is the standard one and pcsc-lite can use it through the usual app-crypt/ccid driver it uses already to access the “usual” chipcards. Unfortunately, since the device is compound and exposes the two CCID interfaces on a single address, it has been working correctly only with libhal, as that was the only way to tell the CCID driver to look for a given interface. My patch works this around, and compound devices are seen correctly; I’m waiting to hear from Ludovic whether it would be safe to apply it in Gentoo for all the other users.

So I’m not gone, just very very very busy. But I’m around by mail mostly.

pcsc-lite and the Gentoo diversion

You probably all know that I’m not really keen on diverging Gentoo from other distributions as long as it’s feasible, although I’m also always considering the idea of giving an extra edge to our distribution. Today, though, is one of the days when I have to implement something differently in Gentoo to have it working internally.

Today, Ludovic Rousseau released a new pcsc-lite version that is designed to improve autostart and increase safety and security by replacing a setuid-root with a setgit-pcscd. Together with that, a new ccid wrapper that sets the permission on USB devices via UDEV was released.

Now, while this looks all good stuff that improves user experience, this is mostly designed to solve issues with binary distributions — most likely, Ubuntu and derived. Autostart is mostly designed to avoid using a pcscd system service; in Gentoo that’s not much of a problem because it’s the user’s choice to start or not a init script, but on other distributions as soon as you install the package, the init script is scheduled to start. Once again, that’s not much of a problem when you install a server package, as that’s the whole point of it, but the pcscd service has to be bundled with the client library — and the client library is decided at build-time, so likely enabled for many packages, in those distributions. Again these aren’t enough of a concern for us, thanks to our customisable design.

On the other hand, the new design is troublesome for us: the daemons are started with the privileges of the current user, but access to the pcscd group; that would be okay if it wasn’t that it needs to create files in the /var/run/pcscd directory, which we cannot simply create in the ebuild – as /var/run could be on a tmpfs instance – and cannot simply be re-created by pcscd; it worked before because as setuid root it had all the privileges to do so. Ludovic suggested to create a reduced init script whose only task is to create the directory at startup, but at that point, why reducing to simply creating the directory?

The end result is as follows: the init script is updated, it creates the directory, alright, but now it executes the pcscd process under privileges of nobody/pcscd, rather than root, tightening security a little bit. More importantly, thanks to the fact that USB decices (and other hotpluggable devices) are handled through udev permissions, I’ve also created an extra rules file that hotplugs the service if a new device is added to the pcscd group, which gives a slightly better usability to Gentoo than before.

Unfortunately, this complicates the matter further, as versions of ccid and pcsc-lite need to go hand in hand, stabling them is a PITA; the fact that ifd-gempc is also not fixed yet really don’t make it any nicer. On the other hand, the presence of this now Gentoo-specific hotplug path through UDEV also mean that we could finally drop the HAL support in this ebuild, as that was supposed to provide the generic hotplug mean before.

I hope this situation will turn out good for everybody; if anything seems to be amiss, don’t hesitate to open a bug or tell me directly, and I’ll look into it.