2016-11-09
Getting a Yubikey 4 working on Ubuntu 14.04 LTS and other older Linuxes (in PIV mode)
Suppose, not entirely hypothetically, that you have some brand new
Yubikeys that you're going to use in PIV mode for SSH keys.
Everything initially goes well in current Linux distributions like,
say, Fedora 24 (with a hiccup or two) and
Ubuntu 16.04, but then you plug one into an Ubuntu 14.04 machine
and all of a sudden nothing works. Not only does yubico-piv-tool
fail to be able to talk to the Yubikey to do things like let people
set their own PINs, but even basic SSH usage fails with 'ssh -I
...' and 'ssh-keygen -D ...' and so on. Nothing sees the Yubikey
as there at all.
Here is what's going on. All of these programs talk to the Yubikey
through the pcscd daemon, which for USB
based devices like the Yubikey uses an underlying 'CCID' library to talk to the actual
devices. This CCID library only started supporting the Yubikey 4
in version 1.4.20 (per here), which
was released in August of 2015. This is too recent for it to be
included in older distributions like Ubuntu 14.04, which has 1.4.15
(in the libccid package).
(This probably includes RHEL/CentOS 7, but RHEL might have updated
card support by hand without pulling in the new release as a whole.
The RHEL package is pcsc-lite-ccid.)
One possible solution is to (re)build yourself an updated version
of the libccid package; you can probably take the Ubuntu source
package from 16.04 and just drop it in. Fortunately there turns out
to be an easier way; you can just update a file to tell the CCID
library about the Yubikey 4's device IDs, after which things seem
to just work on Ubuntu 14.04. On Ubuntu, this file is found as
/etc/libccid_Info.plist; on Fedora, it is
/usr/lib64/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist.
So the quick approach is to get a copy of this file from a more
up-to-date system and drop it onto your 14.04 machine in place
of the stock libccid version of the file. Once you do this,
you probably also need to restart the pcscd daemon.
(It's possible that supporting new cards sometimes needs code
changes, especially for a sufficiently old libccid package.
However, I've verified that the git commits that introduced support
for the Yubikey 4 only update data files that are used to build the
.plist file; they contain no code changes. An example is this one.
You can also see the master file for this.
The two hex fields appear to be a vendor ID and then a product ID.)
We only care about PIV mode for SSH keys at the moment, so I haven't tested what else is required to get U2F or Yubikey OTP personalization working on Ubuntu 14.04 (or even 16.04, for that matter; I've only tried it on my own Fedora 24 desktop). U2F apparently might require some udev changes to get the Yubikey recognized properly.
(On the other hand, on Ubuntu 14.04 you need to install some Yubikey related packages from Yubico's PPA and that may install the necessary udev rules if you pull in the right packages.)
I assume that it's always possible to compromise our security somehow
It can be very easy to get into a stark, binary mindset when you think about security and security issues, one where anything that introduces a potential insecurity must be resisted with full force. This mindset is a mistake, because real security almost always involves tradeoffs and a balance of risks, but it can be easy to find yourself in it. One of my tools for resisting it is to always assume that we can be compromised by a determined attacker who is specifically targeting us.
This sounds silly and obvious and surely everyone does it, but for me its power is in turning a binary situation into one with shades of gray. Instead of the introduction of a potential security issue taking us from 'totally secure' to 'potentially vulnerable', the question becomes whether this will introduce a bigger or worse vulnerability than we already have, or whether the exposure it adds is probably mostly theoretical because real attackers will just pick on a more easily accessible weak point.
(You can flip this around when considering security measures to add to your environment. Are you reinforcing something that an attacker is already not going to bother with, or are you shoring up a current weak point?)
Or in other words, the question is not 'could we be attacked through this' (because the answer is very often 'yes, in theory'), the question is 'will we be attacked through this' or the closely related one of 'how much easier have we just made the life of an attacker?'
(Of course, there are reasons to not add even low-likelihood weak points. A target rich environment with a bunch of weak points helps attackers, since they don't have to work very hard to find something to attack. But you are presumably getting something from any potential new security exposure, so you can balance the gain against the extra security risk.)
At the same time, I want to throw cold water on myself here. That something is a security tradeoff and the security exposure it introduces is low and attackers will target something else can be a convenient excuse for ignoring potential security issues in something I want to do. Security inevitably involves not doing things, and when I want to do something it's tempting to find a way to justify it (and I may not realize that that's what I'm doing).